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

[Lou Berger <[e-mail]>]

John,
	Thanks for the humor.  I'm sure it's nice to vent.

Lou

On 12/20/2011 1:43 PM, John E Drake wrote:
> If you are saying that we are free to ignore you, them I am fine and I think we are done with the OTN discussion.
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Tuesday, December 20, 2011 9:12 AM
>> To: John E Drake
>> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP; ccamp-
>> [e-mail]
>> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>> (Issue 1/2)
>>
>>> 2)  I think both Lou and Julien are close to abusing their positions
>> as WG chairs
>>
>> John,
>>       So this is an interesting statement.  It implies a WG chair is
>> not
>> allowed to take an technical positions within a WG that they chair.
>> This is, of course, pure nonsense.
>>
>> If you really believe that I (or the PCE WG chair for that matter) have
>> acted in a manner inconsistent with RFC 2026 or RFC 2418, I strongly
>> encourage you to follow standard IETF process in this regard.
>>
>> Lou
>>
>> On 12/20/2011 11:50 AM, John E Drake wrote:
>>> Hi,
>>>
>>> I have several observations:
>>>
>>> 1)  We are just repeating ourselves
>>>
>>> 2)  I think both Lou and Julien are close to abusing their positions
>> as WG chairs
>>>
>>> 3)  There seems to be a preponderance of opinion to go with the
>> current design
>>>
>>> Therefore, I would like to call the question and have Deborah decide
>> what our design direction is to be.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]]
>>>> Sent: Tuesday, December 20, 2011 8:28 AM
>>>> To: Sadler, Jonathan B.
>>>> Cc: John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP
>>>> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>>>> (Issue 1/2)
>>>>
>>>> Jonathan,
>>>>       This point is precisely (one of) the key reasons I put forward
>>>> the
>>>> proposal on multiple SC types.
>>>>
>>>> Lou
>>>>
>>>> On 12/20/2011 11:12 AM, Sadler, Jonathan B. wrote:
>>>>> John,
>>>>>
>>>>>
>>>>>
>>>>> While each ODU layer is a single layer network, how the ODUs
>> interact
>>>>> with each other (e.g. placing an ODU0 into an ODU1) generates a
>>>>> multi-layer network.
>>>>>
>>>>>
>>>>>
>>>>> This detail is especially important when dealing with multi-stage
>>>>> multiplexing (eg ODU0 over ODU1 over ODU2) AND dealing with
>> different
>>>>> adaptation styles (e.g. 2.5G TS vs 1.2G TS)
>>>>>
>>>>>
>>>>>
>>>>> CCAMP did get a liaison from ITU-T last year pointing these details
>>>> out
>>>>> (LS221).
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Sadler
>>>>>
>>>>>
>>>>>
>>>>> *From:* [e-mail] [mailto:[e-mail]] *On
>>>>> Behalf Of *John E Drake
>>>>> *Sent:* Tuesday, December 20, 2011 10:02 AM
>>>>> *To:* BELOTTI, SERGIO (SERGIO)
>>>>> *Cc:* CCAMP
>>>>> *Subject:* Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF
>> 82
>>>>> (Issue 1/2)
>>>>>
>>>>>
>>>>>
>>>>> Sergio,
>>>>>
>>>>>
>>>>>
>>>>> Excellent.  Jonathan, check this out.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> *From:* BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
>>>> lucent.com]
>>>>> *Sent:* Tuesday, December 20, 2011 7:59 AM
>>>>> *To:* John E Drake
>>>>> *Cc:* CCAMP; Zhangfatai; Julien Meuric
>>>>> *Subject:* R: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>>>>> (Issue 1/2)
>>>>>
>>>>>
>>>>>
>>>>> John,
>>>>>
>>>>> Just to emphasize what you've already well mentioned about multi-
>>>> layer
>>>>> in OTN.
>>>>>
>>>>>
>>>>>
>>>>> This is what reports the Recommendation representing Optical
>>>> Transport
>>>>> Network architecture , G.872.
>>>>>
>>>>> .....
>>>>>
>>>>> "Since the resources that support these topological components
>>>> support a
>>>>> heterogeneous assembly of ODUs, the ODU layer is modelled as a
>> single
>>>>> layer network that is independent of bit-rate.  The ODU bit-rate is
>> a
>>>>> parameter that allows the number of Tributary Slots (TS) for the
>> ODU
>>>>> link connection to be determined."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> Sergio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Messaggio originale-----
>>>>> Da: [e-mail] [mailto:[e-mail]] Per
>> conto
>>>> di
>>>>> John E Drake
>>>>> Inviato: martedì 20 dicembre 2011 16.14
>>>>> A: Julien Meuric; Zhangfatai
>>>>> Cc: CCAMP
>>>>> Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>>>>> (Issue 1/2)
>>>>>
>>>>>
>>>>>
>>>>> Julien,
>>>>>
>>>>>
>>>>>
>>>>> I don't know how many times we want to go over this.
>>>>>
>>>>>
>>>>>
>>>>> As you might expect, Switching Capability enables path computation
>> to
>>>> be
>>>>> aware of regions in which there are different switching
>> capabilities.
>>>>> It was never intended to delineate sub-regions (layers) within
>> those
>>>>> regions.  In particular, nowhere in the entire body of the
>>>>> Multi-Layer/Multi-Region work is this capability mentioned.
>>>>>
>>>>>
>>>>>
>>>>> Further, it is not used in this manner in SDH/SONET which, along
>> with
>>>>> OTN, is the best example of a multi-layer network with which we
>> have
>>>> to
>>>>> deal and the last time we had this discussion, prior to Maastricht,
>>>> it
>>>>> was stated that the ITU has deprecated the use of the concept of
>>>>> multi-layer in its modeling of OTN networks.
>>>>>
>>>>>
>>>>>
>>>>> Could we please agree that PSC 1-4 was an aberration that can be
>>>>> attributed to inexperience and just erase it from our collective
>>>> memory?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>>>
>>>>>> Of Julien Meuric
>>>>>
>>>>>> Sent: Tuesday, December 20, 2011 6:54 AM
>>>>>
>>>>>> To: Zhangfatai
>>>>>
>>>>>> Cc: CCAMP
>>>>>
>>>>>> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>>>>>
>>>>>> (Issue 1/2)
>>>>>
>>>>>>
>>>>>
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> CCAMP mailing list
>>>>>
>>>>> [e-mail]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>> ============================================================
>>>>> The information contained in this message may be privileged
>>>>> and confidential and protected from disclosure. If the reader
>>>>> of this message is not the intended recipient, or an employee
>>>>> or agent responsible for delivering this message to the
>>>>> intended recipient, you are hereby notified that any reproduction,
>>>>> dissemination or distribution of this communication is strictly
>>>>> prohibited. If you have received this communication in error,
>>>>> please notify us immediately by replying to the message and
>>>>> deleting it from your computer. Thank you. Tellabs
>>>>> ============================================================
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp