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

[Lou Berger <[e-mail]>]

So you're basically arguing that SC shouldn't be used to indicate
different levels of hierarchy, i.e., usage (b) in my earlier message,
and that the definition of PSC-1 -> n was flawed.  Right?

Which then reduces the meaning of SC to simply and indicator of label
type and ISCD format indicator.

Is this your position?

Lou

On 11/30/2011 4:37 PM, John E Drake wrote:
> Comments inline.  I still think this is a terrible idea and I would like to see what the rest of the WG thinks.
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Wednesday, November 30, 2011 1:09 PM
>> To: John E Drake
>> Cc: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>
>>
>> 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.
> 
> [JD]  You are simply asserting that this is a good idea and further asserting that there is "ambiguity related to bandwidth', without providing any evidence.  
> 
> To the best of my knowledge no one ever implemented or deployed the PSC-1 -> PSC-4 hierarchy, simply because no one could figure out what it meant.  To quote from you, below, "Well hopefully we have a better understanding of the technologies involved than we had in the past.".  I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea (tm) and move on.   
> 
>>
>>> 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.
> 
> [JD] I think we had a very good understanding of SDH/SONET then and we have a very good understanding of OTN now, and in both cases the authors saw no requirement to overload switching capability in the manner you are suggesting.
> 
>>
>>>
>>> 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...
> 
> [JD]  I think it clarifies that switching capabilities is meant to describe how a given interface switches the information with which it is provided.  This has nothing to do with the interface's bandwidth.
> 
>>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>