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

[Lou Berger <[e-mail]>]

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
> 
> 
> 
>