Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

[Lou Berger <[e-mail]>]

John,

see below


On 11/30/2011 2:59 PM, John E Drake wrote:
> Using Switching Capability to indicate link bandwidth seems
> ill-considered at best, especially since this information is carried
> in other fields, and as Daniele noted, it significantly overloads to
> intended meaning of Switching Capability.  

I agree with the point on BW, but my point was related to the
layer&hierarchy implications of the different ODUk values.  I'd think
that using values that are TDM-1 -> TDM-n should make this clear and
remove any ambiguity related to bandwidth.  It is also completely
consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n.

> It also is inconsistent
> with the usage of Switching Capability in SDH/SONET.

Well hopefully we have a better understanding of the technologies
involved than we had in the past.

> 
> A more extensive quote from RFC4202 is the following, which seems
> clear enough to me:
> 
> "In the context of this document we say that a link is connected to a
> node by an interface.  In the context of GMPLS interfaces may have
> different switching capabilities.  For example an interface that
> connects a given link to a node may not be able to switch individual
> packets, but it may be able to switch channels within an SDH payload.
> Interfaces at each end of a link need not have the same switching
> capabilities.  Interfaces on the same node need not have the same
> switching capabilities."

Not sure how this helps clarify anything...

Lou
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Wednesday, November 30, 2011 8:43 AM
>> To: John E Drake
>> Cc: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>
>> Great.  Care to substantiate your point?
>>
>> On 11/30/2011 11:14 AM, John E Drake wrote:
>>> I completely disagree.
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>>>> Of Lou Berger
>>>> Sent: Wednesday, November 30, 2011 7:22 AM
>>>> To: Daniele Ceccarelli
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>> 1/2)
>>>>
>>>> Hi Daniele,
>>>> 	Since I raised the point, I guess I need to champion it!  (With
>>>> chair
>>>> hat off.)
>>>>
>>>> All,
>>>>
>>>> Daniele said:
>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of
>> the
>>>>> muxing hiearachy in the Switching Capability field of the ISCD.
>> After
>>>>> a quick talk with the other authors of the ID, the idea was to
>> reject
>>>>> the proposal as it would lead to an overloading of the meaning of
>> the
>>>>> Switching Capability field. (even if the definition of PSC1-2-3-4
>>>>> already overloads the meaning of the switching capability field)
>>>>
>>>> This really goes to the interpretation of the intent of Switching
>>>> Capability Types.  So we have a few definitions: 3471 says "the type
>> of
>>>> switching that should be performed", 4202 says  "describes switching
>>>> capability of an interface." 3945 doesn't really define the term (it
>>>> just references 4202), but does equate it with a "layer". While it
>>>> allows for hierarchy within a "layer" it also says hierarchy occurs
>>>> "between interface types".
>>>>
>>>> So I interpret Switching Capability Types to represent (a) different
>>>> switching/technology layers and (b) different levels of hierarchy --
>>>> even within a layer.  I think (a) is identifiable in the definition
>> of
>>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC,
>>>> and
>>>> FSC), and (b) is identifiable in the original types plus the
>> definition
>>>> of PSC-1 through PSC-4.
>>>>
>>>> So how does this apply to our current OTN work?
>>>>
>>>> To me, the first question to ask relates to (a), and is should each
>>>> ODUk
>>>> be modeled as a separate layer?
>>>>
>>>> I know this has been a much debated point, and it seems to me that
>> they
>>>> are, but more for the perspective of switching layers than
>> technology
>>>> layers (i.e., they are clearly the same technology but are different
>>>> granularity of swicthing.) So this is a yes for me.
>>>>
>>>> I think the second question to ask relates to (b), and is does each
>>>> ODUk
>>>> represent a different level of hierarchy?
>>>>
>>>> I see this as simply yes, and no different than what has been done
>> more
>>>> recently with Ethernet or, even if we do continue to model OTN as a
>>>> single layer, no different than PSC-1 -> PSC-4.
>>>>
>>>> There's also a minor processing efficiency gained by this approach
>> for
>>>> nodes that support a smaller set of ODUks than are advertised within
>> an
>>>> IGP.
>>>>
>>>> Based on all this, I believe different ODUk's should use different
>>>> Switching Types.  In particular, I'm proposing:
>>>> (1) that either the framework or info documents identify that
>>>>     a per-OTUk Switching Capability Types will be used to support
>>>>     G.709v3.
>>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different
>>>>     Switching Cap field value for each ODUk, and that it state
>>>>     that the value corresponding to the signal type identified in
>>>>     the #stages=0 of the ISCP be set.  (Without any other changes
>>>>     to the current definition of ISCD.)
>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to
>>>>     match above.
>>>>
>>>> To keep thinks generic, we probably should use TDM-1 through TDM-n
>> as
>>>> the new Switching Capability Types, but this is a secondary
>> discussion.
>>>>
>>>> Comments?
>>>>
>>>> Lou
>>>>
>>>> PS While the above is an important change, it doesn't significantly
>>>> impact encoding and won't take much text to make the actual change,
>> so
>>>> this is a discussion that can continue until Paris if we really need
>> a
>>>> face to face to resolve the discussion.
>>>>
>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote:
>>>>> Hi CCAMP,
>>>>>
>>>>>
>>>>>
>>>>> During the OTN OSPF draft presentation at the IETF meeting in
>> Taipei
>>>> two
>>>>> comments were raised with respect to the following issues:
>>>>>
>>>>>
>>>>>
>>>>> - Issue 1: Using different switching caps for each ODU type
>>>>>
>>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and
>> Type
>>>> 3
>>>>> (MAX LSP bandwidth foe variable containers always used in tandem?
>>>>>
>>>>>
>>>>>
>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of
>> the
>>>>> muxing hiearachy in the Switching Capability field of the ISCD.
>> After
>>>> a
>>>>> quick talk with the other authors of the ID, the idea was to reject
>>>> the
>>>>> proposal as it would lead to an overloading of the meaning of the
>>>>> Switching Capability field. (even if the definition of PSC1-2-3-4
>>>>> already overloads the meaning of the switching capability field)
>>>>>
>>>>>
>>>>>
>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft (version -
>>>> 00).
>>>>> I'm copying it below for your convenience
>>>>>
>>>>>
>>>>>
>>>>>    In this example the advertisement of an ODUflex->ODU3 hierarchy
>> is
>>>>>
>>>>>    shown.  In case of ODUflex advertisement the MAX LSP bandwidth
>>>> needs
>>>>>
>>>>>    to be advertised but in some cases also information about the
>>>>>
>>>>>    Unreserved bandwidth could be useful.  The amount of Unreserved
>>>>>
>>>>>    bandwidth does not give a clear indication of how many ODUflex
>> LSP
>>>>>
>>>>>    can be set up either at the MAX LSP Bandwidth or at different
>>>> rates,
>>>>>
>>>>>    as it gives no information about the spatial allocation of the
>>>> free
>>>>>
>>>>>    TSs.
>>>>>
>>>>>
>>>>>
>>>>>    An indication of the amount of Unreserved bandwidth could be
>>>> useful
>>>>>
>>>>>    during the path computation process, as shown in the following
>>>>>
>>>>>    example.  Supposing there are two TE-links (A and B) with MAX
>> LSP
>>>>>
>>>>>    Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unreserved
>>>>>
>>>>>    Bandwidth are available on Link A, 10Gbps on Link B and 3
>> ODUflex
>>>>>
>>>>>    LSPs of 10 GBps each, have to be restored, for sure only one can
>>>> be
>>>>>
>>>>>    restored along Link B and it is probable (but not sure) that two
>>>> of
>>>>>
>>>>>    them can be restored along Link A.
>>>>>
>>>>>
>>>>>
>>>>> Early proposal was to have, in the case of variable containers
>>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3)
>> as
>>>> a
>>>>> mandatory piece of information and the Unreserved bandiwdth TLV
>> (Type
>>>> 2)
>>>>> as an optional piece of information.
>>>>>
>>>>> The comment received is that optional information can lead to
>>>>> interworking issues and the counter proposal was to have both
>> pieces
>>>> of
>>>>> information as mandatory and, as a consequence, merge the two TLVs
>>>> into
>>>>> a single one.
>>>>>
>>>>>
>>>>>
>>>>> We'd like to hear the opinion of the WG on both issues before
>>>> proceeding
>>>>> with any modification to the document.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Daniele
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *DANIELE CECCARELLI *
>>>>> *System & Technology - DU IP & Broadband*
>>>>>
>>>>>
>>>>> Via L.Calda, 5
>>>>> Genova, Italy
>>>>> Phone [phone]
>>>>> Mobile [phone]
>>>>> [e-mail]
>>>>> www.ericsson.com
>>>>>
>>>>>
>>>>>
>>>>> <http://www.ericsson.com/>
>>>>>
>>>>>
>>>>> This Communication is Confidential. We only send and receive email
>> on
>>>>> the basis of the term set out at www.ericsson.com/email_disclaimer
>>>>> <http://www.ericsson.com/email_disclaimer>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
> 
> 
> 
>