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

From: Julien Meuric <[email-masked]>
Date: Tue, 06 Dec 2011 17:08:57 +0100

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: [email-masked]
>  [mailto:[email-masked]] 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: +39 0396863033
>  [email-masked]
>
>
>
>  -----Messaggio originale----- Da: [email-masked]
>  [mailto:[email-masked]] 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:[email-masked]] 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:[email-masked]] 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: [email-masked]
> >>>>> [mailto:[email-masked]] 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 +390106002512 Mobile
> >>>>>> +393346725750 [email-masked]
> >>>>>> 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
>  [email-masked] https://www.ietf.org/mailman/listinfo/ccamp

---

From: Zhangfatai <[email-masked]>
Date: Tue, 06 Dec 2011 19:21:12 +0000

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 [[email-masked]]
发送时间: 2011年12月7日 0:08
到: Zhangfatai
Cc: CCAMP; [email-masked]
主题: Re: [CCAMP] R:  OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi Fatai.

Regards,

Julien