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

[Lou Berger <[e-mail]>]

> 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