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

[John E Drake <[e-mail]>]

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Tuesday, December 20, 2011 9:45 AM
> To: John E Drake
> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
>
> My proposal in Taipei was motivated by intra-technology hierarchy
> representation in a generic method, ala PSC-2->N.

[JD] There is no requirement to do this and in general it is of no use in path computation.  More specifically, for both SDH/SONET and OTN, it is of absolutely no use in path computation.

>
>  The fact that in OTN
> level of hierarchy also implies a bandwidth is really
> orthogonal&incidental from this perspective.
>
> You have made your position clear, i.e., that you think that the
> original definition of PSC-2->N (and use of SC as a generic
> intra-technology hierarchy indicator) is flawed.  Others have made the
> point that it is not. As I've stated on the list, I personally think
> it's an interesting proposal that should be considered.
>
> So how do we close on this discussion?
>
> In an earlier message I asked if you were interested in putting a draft
> together to document your proposed change to the base GMPLS specs.
[
[JD]  There are no changes to the base GMPLS specs.  We are not changing the base definition of PSC 1-4 and what we are defining is completely consistent with SDH/SONET.

> Since you haven't expressed any interest in this, I'll bite and commit
> to putting forward a draft (in January) that captures both/all sides of
> the base GMPLS implications of this debate.  Hopefully this will help
> move the non-technology specific GMPLS portions of this debate to
> closure; any needed OTN changes/implications can then follow.

By your definition, above, this draft is going to contain no new information, so what is the purpose of the exercise?

>
> Anyone interested in contributing, in a constructive manner, to this
> individual draft is welcome.  Just send me mail.
>
> Lou
>
> On 12/20/2011 11:46 AM, John E Drake wrote:
> > The snippet from Jonathan's email "how the ODUs interact with each
> other (e.g. placing an ODU0 into an ODU1)" is a useful short
> description of the problem we are solving.
> >
> > I.e., the types of ODUj a given ODUk interface supports.  This is
> much more relevant in path computation than that interface's bandwidth,
> especially given that multiple bandwidths of ODUk support a given ODUj,
> and we advertise an interface's bandwidth separately.
> >
> >
> >> -----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