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

[Julien Meuric <[e-mail]>]

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