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

[Julien Meuric <[e-mail]>]

Hi John.

I hear your argument and agree that it is not inconsistent with 
SONET/SDH. My point is that deployments of GMPLS-controlled SONET/SDH 
cover a single granularity of containers (and relevant concatenations), 
thus GMPLS-controlled SONET/SDH is not enough as a starting point to be 
mechanically generalized into OTN (otherwise we would not be arguing).

Regards,

Julien


Le 20/12/2011 16:53, John E Drake a écrit :
> Julien,
>
> I would also like to observe that what we are doing in OTN is exactly the same as we did in SDH/SONET, viz, advertising the types of client LSPs a given interface supports.
>
> Thanks,
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Julien Meuric
>>
>> Hi Fatai.
>>
>> About the IGP, I believe we agree on several things:
>> - we are dealing with the ODUk layers within the OTN
>> technology/regions;
>> - the ISCD is an appropriate place to put the information on ODUk
>> capabilities of nodes.
>>
>> What we disagree on:
>> - using the term "extension" to refer to encoding the hierarchy level
>> in
>> the SC field: the _fact_ is that PSC-[1~4] are part of existing RFCs
>> (e.g. 4203);
>> - selecting the SC field as an information on the hierarchy level.
>>
>> This leaves us with an open discussion on the latter. We already have 2
>> options on the table for the ISCD in IGPs:
>> a) multiple SC values,
>> b)"Switching Cap&  Signal Type (&  Encoding Type as well)".
>>
>> First of all, I do not believe the original intend of SC alone was to
>> reflect the notion of region: xSC acronyms may map to "regions", but
>> from a codepoint perspective we can have several values behind a single
>> xSC (e.g. x=P).
>>
>> Then you propose to use the "[OTN] Signal Type": as opposed to a)
>> above,
>> this is a new extension, created in
>> draft-ietf-ccamp-gmpls-ospf-g709v3-00. As emphasized by Kireeti, the SC
>> field should allow to constrain path computation into a range or a
>> sub-part of the hierarchy (without necessarily specifying a full list).
>> The I-D uses a single SC (OTN-TDM) for the whole OTN, which means the
>> SC
>> field is useless to prune the network graph when routing an ODUk: even
>> for pruning, a CSFP implementation needs to parse some OTN-specific
>> sub-TLVs. Hence I prefer the "old-fashion" approach which represent the
>> hierarchy information at a higher level in the IGP, like it was done
>> for
>> PBB-TE (RFC 6060).
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 06/12/2011 20:21, Zhangfatai a écrit :
>>>   Hi Julien,
>>>
>>>   I agree the requirement that you mentioned, but it can be resovled
>>>   without extending Switching Cap.
>>>
>>>   It is known that there are two cases described in RFC5212 and
>>>   RFC5339, one is MRN, another one is MLN. In RFC5212, it says:
>>>
>> =======================================================================
>> ========
>>>
>> Thus, a control plane region, identified by its switching type value
>> (e.g., TDM), can be sub-divided into smaller-granularity component
>> networks based on "data plane switching layers".  The  Interface
>> Switching Capability Descriptor (ISCD) [RFC4202],  identifying the
>> interface switching capability (ISC), the encoding type, and the
>> switching bandwidth granularity, enables the characterization of the
>> associated layers.
>>>   In this document, we define a multi-layer network (MLN) to be a
>>>   Traffic Engineering (TE) domain comprising multiple data plane
>>>   switching layers either of the same ISC (e.g., TDM) or different ISC
>>>   (e.g., TDM and PSC) and controlled by a single GMPLS control plane
>>>   instance. We further define a particular case of MLNs. A multi-
>>>   region network (MRN) is defined as a TE domain supporting at least
>>>   two different switching types (e.g., PSC and TDM), either hosted on
>>>   the same device or on different ones, and under the control of a
>>>   single GMPLS control plane instance.
>>>
>> =======================================================================
>> ==============
>>>
>> Therefore, for MRN case, we can use Switching Cap to differentiate the
>> different "layers"; for MLN case (same ISC with different granularity),
>> we can use Switching Cap&  Signal Type (&  Encoding Type as well) to
>> differentiate the different granularity.
>>>   So, come back to your question, it can be achived by using Switching
>>>   Cap&Encoding Type&Signal Type to identify the granularity requested
>>>   in OTN networks(e.g., this information can be carried in
>>>   SERVER_LAYER_INFO sub-object) .
>>>
>>>   Lastly, in my opinion, if there is no issue based on the existing
>>>   mechnism or definition without extending Switching Cap, I don't
>> think
>>>   we need to extend Switching Cap.
>>>
>>>
>>>   Thanks
>>>
>>>   Fatai
>>>
>>>
>>>
>>>   ________________________________________ 发件人: Julien Meuric
>>>   [[e-mail]] 发送时间: 2011年12月7日 0:08 到: Zhangfatai
>> Cc:
>>>   CCAMP; [e-mail] 主题: Re: [CCAMP] R: OSPF OTN considerations
>> post
>>>   IETF 82 (Issue 1/2)
>>>
>>>   Hi Fatai.
>>>
>>>   As co-author of draft-ietf-pce-inter-layer-ext, I believe you will
>>>   agree on the fact that having a Switching Capability per ODUk layer
>>>   would make the use of objects including a Switching Cap field rather
>>>   straightforward and enables a fine-grained resource description,
>> e.g.
>>>   in: - REQ-ADAP-CAP object, to precisely identify the type of
>>>   adaptation requested by a higher layer, or to get a clear feedback
>> on
>>>   the missing adaptation for unsuccessful path computations; -
>>>   SERVER_LAYER_INFO sub-object, to precisely identify the type of
>>>   server layer within the ERO.
>>>
>>>   Do not you think that summarizing G.709 by a single Switching Cap
>>>   value would take some capabilities away? What would you suggest so
>> as
>>>   to achieve the same level of details in that scenario?
>>>
>>>   Regards,
>>>
>>>   Julien
>>>
>>>
>>>   Le 02/12/2011 09:51, Zhangfatai a écrit :
>>>> Hi all,
>>>>
>>>> I agree that there is no need to overload Switching Cap.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Fatai
>>>>
>>>>
>>>> -----Original Message----- From: [e-mail]
>>>> [mailto:[e-mail]] On Behalf Of BELOTTI, SERGIO
>>>> (SERGIO)
>>>>
>>>> John, as co-authors, we shared completely your thoughts.
>>>>
>>>> Thanks Sergio and Pietro
>>>>
>>>> SERGIO BELOTTI
>>>>
>>>> ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio
>>>> Evolution
>>>>
>>>> via Trento 30 , Vimercate(MI) Italy T: [phone]
>>>> [e-mail]
>>>>
>>>>
>>>>
>>>> -----Messaggio originale----- Da: [e-mail]
>>>> [mailto:[e-mail]] Per conto di John E Drake Inviato:
>>>> mercoledì 30 novembre 2011 22.37 A: Lou Berger Cc: CCAMP Oggetto:
>>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>>>
>>>> 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