[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MRN ext. doc

Hi Dimitri,


===
We will definitely (well, very probably) be asked if we can show
traceability back to the requirements. In fact, RFC 5339
includes section
4.1 that gives traceability from the evaluation back to the
requirements.
Section 2 of this document does not quite give the same level of
traceability such that it is necessary to read most of 5339
to ensure that all requirements have been met.


the current doc. covers the "delta" in terms of mechanism.
so, do you mean that mechanisms not requiring any extensions
shall also be included/described in this document ?


Nope.
Simply that the I-D should explicitly call out the lacunae
identified in RFC 5339.
For example, you could say...
The following features are identified in [RFC5339] as
requiring protocol extensions:
1. Feature to do something. See Section 1.2.3 of [RFC5339]
2. ...


ok - you would like a ref. to 5339.
Yes. But not just a simple ref to the doc, but a ref to each of the unanswered requirements in 5339 


===
Section 4 appears to consider only the mapped server model
(allowing a many to one mapping), but not the multiplexed
server model. Is it the intention to defer this to Section 5?


i don't understand the question.


Hmm. I'm using ITU terminology.

Mapped server has a connection set up in the server layer "on
demand" with only the bandwidth required by the client layer
connection.

Many-to-one mapped server allows that the server connection
set up for a previous client layer connection may have "spare"
bandwidth that can be allocated ("on demand") to support a
further client layer connection.

Multiplexed server model causes the "spare" bandwidth to be
advertised in the client layer as a link.

My question was trying to understand how the required
function was split between the two sections 4 and 5.


can u please use the ietf terminology at least to make the point
understandable to me (excuse my ignorance). what is a mapped
server ?


OK. Well, I did try to explain in my previous response.
In the mapped server model, a connection in used in the server layer/region in response to a specific demand for end-to-end connectivity in the client layer/region. In most cases, the server connection is created on-demand when the client connection request reaches the layer boundary. The client connection is "mapped" to the server connection using the adaptation function at the boundary node to provide continuous end-to-end connectivity. The server connection is not made into a link in the client layer/region because its purpose is only to server the current client connection. When the client connection is torn down, the server connection will normally be torn down as well.
The many-to-one mapped server case is initiated in the same way, but it may be that it is actually possible to map more than one client connection to the server connection (effectively there is multiplexing in the adaptation function). However, since the server connection is not advertised as a link in the client layer/region, the second client connection to be requested behaves exactly the same except that the border node can (before setting up a new on-demand server connection) note that there is available capacity on an existing server connection and use that.
I suppose that the mapped server cases equate to the creation of a data link that is not advertised (i.e. remains as a local client layer/region link across the server layer/region). The case where a TE link is created and advertised equates to the ITU's Multiplexed Server model. 


The Call-Attributes object C-Num is picked from the 11bbbbbb
class. Why?
Surely if any node that processes the Notify message does not
understand the object, you want the Call to fail.


this what has been agreed from last meeting. see Lou's preso.


Well, it's wrong!  :-)

It doesn't make sense to use 11bbbbbb.
Consider that you are using a Notify message that is
targetted. Therefore, the first node to process the
Notify message is the intended end point of
the call, or a deliberate transit call controller. That
means that we require the recipient to be able to
process the object.
Furthermore, there is nowhere for the message to be
forwarded if the object is not understood.


not sure. at the end the question is an attribute object class a
criteria for which rejection is expected. going one step further one can
mandate support of the class but it is the support of the associated
capability that matters.. one would be still blocking on the latter
anyway if that capability would not be supported independently of the
object class. so it is the "mandatory or optional" nature of the
attribute that induce support of the object not the other way around.


I spoke to Lou.
He had suggested 11bbbbbb because he thought the object might end up on a Path message. However, we don't think this would actually be the case because the call request message is a Notify. 
So he is more relaxed about this changing to 0bbbbbbb


The special case of a Notify that is forwarded hop-by-hop
does not require that the Call-Attributes object is processed
since transit nodes "just forward the Notify message to the
target node" without looking at the contents.

We should use 0bbbbbbb



===
I'm puzzled that the Call described in section 5.1 does not
indicate to the intended LSP egress in which layer or
region the soon-to-be-set-up LSP will be required to
operate.


because

- it is the FA setup that indicates to which bearer the virtual
link will be associated not the other way around

- the virtual association is used by upper-region LSP so the
virtual link itself is an abstraction of the bearer/network (in
other terms - and by definition - one does not create Virtual
TE links over Virtual TE links)

the only condition which can be verified from the TEDB is that both
ends of the bearer belongs to the same LSP region (symmetry).


I meant...
Suppose the head and tail of the planned virtual TE link are
present in three regions (or layers, don't forget layers). One
is the client, and two are potential servers.
Shouldn't the call indicate which server the caller
wishes/intends to use?


assume a base virtual TE link [PSC,PSC] and the two link sequence that
can be followed by the FA-LSP are either [PSC,LSC]..[LSC,LSC]..[LSC,PSC]
or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association between the TE
link and LSP that determines to which FA that TE link is now related to


I agree completely.
And that was my point.
The call is a negotiation between end points about what connection will be set up, what adaptions will be applied, and what TE link will be created. This effectively requires the call request to state the set of potential adaptations, and the call response to identify the subset of acceptable adaptations. The connection can then be signaled in the correct switching type, and the resulting LSP can be associated to the TE link. 


===
I don't find section 3.2.1 clear on the co-existence within
the Link TLV of the IACD sub-TLV and the ISCD sub-
TLV [RFC4203].


i will add a statement IACD does not modify format/messaging and
processing associated to the ISCD.


Thanks.

Now since there is an aggregate duplication of information


where do you see the "duplication" of information b/w IACD and ISCD ?


Well, in the ISCD I see a list of bandwidths available per priority.
In the IACD I see a list of bandwidths available per priority.
Clearly there is some relationship between these numbers because they refer to the same advertised link.
I don't suppose that the sum of the priority 1 bandwidths for all IACDs is supposed to equal the advertised priority 1 bandwidth from the ISCD. But if the priority 1 bandwidths for one IACD was larger than that for the ISCD it would be strange (meaningless?).
There is not a direct duplication of information, but there is some overlap of information and I am asking how it is resolved.
A