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

[Lou Berger <[e-mail]>]

Okay, it's good to understand each other.

Referring back to my earlier mail:
> ... Switching Capability Types  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.

And you're proposing invalidating usage (b).

My proposal is based on (b) being valid. (I was, of course, operating on
the premise of today's current RFCs ;-) I agree that if usage (b) is
invalidated, my proposal makes no sense.

I'm a bit ambivalent on invalidating usage (b).  On one hand, I like the
simplicity implied by the change (and of saying the SC is just is an
indicator of label type and ISCD format).  On the other hand, I've
always found some, albeit not significant, processing value in
constructing SC/layer specific topologies (and even policies.)  -- I
also need some time to digest this proposal in the context of MLN/MRN.

Clearly invalidating (b) and deprecating PSC-2->n, is a notable change
to GMPLS and one that we will need to be discussed agreed to in both
CCAMP and PCE.  Although, if your assertion on how most use PSC and SC
holds, it shouldn't be too contentious a discussion.  Are you willing to
put together a draft with your proposed changes to Switching Capability
Types so that we can codify consensus on the topic?

Lou

On 11/30/2011 5:23 PM, John E Drake wrote:
> Yes, I think that's fair.
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Wednesday, November 30, 2011 1:51 PM
>> To: John E Drake
>> Cc: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>