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

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

Lou and Julien,

Upon reflection I think point 2) in my email, below, is unduly harsh and I would like to apologize to you for making it.

Thanks,

John

> -----Original Message-----
> From: John E Drake
> Sent: Tuesday, December 20, 2011 8:50 AM
> To: 'Lou Berger'; Sadler, Jonathan B.
> Cc: BELOTTI, SERGIO (SERGIO); CCAMP
> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
>
> 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