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

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

Yes, I think that's fair.

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, November 30, 2011 1:51 PM
> To: John E Drake
> Cc: Daniele Ceccarelli; CCAMP
> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
> 
> So you're basically arguing that SC shouldn't be used to indicate
> different levels of hierarchy, i.e., usage (b) in my earlier message,
> and that the definition of PSC-1 -> n was flawed.  Right?
> 
> Which then reduces the meaning of SC to simply and indicator of label
> type and ISCD format indicator.
> 
> Is this your position?
> 
> Lou
> 
> On 11/30/2011 4:37 PM, John E Drake wrote:
> > 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >