Subject: Re: MRN ext. doc

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Nov 2008 17:23:23 -0000

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 2 Nov 2008 19:24:05 +0100

Hi adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Sunday, November 02, 2008 6:23 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Subject: Re: MRN ext. doc
> 
> Hi Dimitri,
> 
> >>>> ===

this is what i meant.

> advertised equates to the ITU's Multiplexed Server model.

ok, i think i barely understood where you are heading at. now what is
the issue with the doc. ? honnestly, i do not catch the point you are
trying to make: section 4 addresses purely signaling procedure issue
(complements existing FA triggering/selection rules) and section 5 a
well-known TE problem that is how to attract traffic when no bearer is
setup (it is a particular case of the generic unknown adjcacency
problem).

> So he is more relaxed about this changing to 0bbbbbbb

are call attributes mandatorily associated to calls (and which case one
could simply mandate support of the related attribute) and their
messaging/processing a must have feature of the protocol ? ... just to
be clear 0bbbbbbb does not solve the former.

> type, and the resulting LSP can be associated to the TE link.

per 4974, the LINK_CAPABILITY object can be used for this purpose with
subobject Type 65. 

i did not mention it for two reasons a) it is implicit in the context (a
Virtual Link by definition addresses the lowest SC value) and b) part of
the procedure referenced by this doc.

> of information and I am asking how it is resolved.

there is no overlap of information too. the IACD is a mean to advertize
adjustment capacity between two SC (so, by def. internal) that would
otherwise be unknown and thus result in LSP blocking when crossing that
LSR. i can give certain base rules of thumb for setting up values of
IACD and its accounting (that is similar per nature to current Max LSP
Bw) as part of the next revision but this is not going to prevent
mis-configuration and/or misuse.

-d.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Nov 2008 19:03:41 -0000

Hello again,

>>>> Hmm. I'm using ITU terminology.

[SNIP]

>> OK. Well, I did try to explain in my previous response.

[SNIP]

> setup (it is a particular case of the generic unknown adjcacency

I didn't actually say there was anything wrong with the document :-)
I just asked what I hoped was a simple question.

>From our discussion it looks like the answer to my question was "yes". Let's 
move on.

>>>> It doesn't make sense to use 11bbbbbb.

[SNIP]

>>> 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.
> are call attributes mandatorily associated to calls (and which case
> one could simply mandate support of the related attribute) and their

No, the Call_Attributes object is not mandatory on a Call request message 
(as currently defined). And yes, you are right, using 0bbbbbbb would not 
make it mandatory anyway.

I am *only* concerned by how the call recipient will process the Notify, how 
(if?) they will respond, and whether this will waste processing in the 
network, especially at the call recipient.

>>>>>> region the soon-to-be-set-up LSP will be required to

[SNIP]

>>> 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
>> 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.
>
> per 4974, the LINK_CAPABILITY object can be used for
> this purpose with subobject Type 65.
>
> i did not mention it for two reasons a) it is implicit in the
> context (a Virtual Link by definition addresses the lowest SC
> value) and b) part of the procedure referenced by this doc.

Weeeeell...

That use of Link Capability is not particularly clear in RFC 4974.

According to section 4.3.3. of RFC 4974 this function allows the call 
initiator to list a set of switching capablities for links that connect it 
"to the network", and for the responder to reduce the list to those 
switching capablities that it supports.

That is only half the function required.

We also need to let the call responder know that we intend using the LSP to 
support a connection in a particular client layer/region. In other words, we 
have to specify what adaptation function we want the responder to support.

It would be enough to add to the information already carried in the 
Link_Capablity object the link capability we intend to create. This could go 
in either the Link_Capablity object or in the Call_Attributes object.

Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb

A