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

[Julien Meuric <[e-mail]>]

Hi John, hi Lou.

On the one hand, SONET/SDH and OTN are close: it is highly tempting to 
prolong control of the former to the latter. Nevertheless, the GMPLS 
deployments on SONET/SDH I am aware of only control high order 
containers (i.e. SDH VC-4/VC-4-nc or SONET STS-1/STS-1-nc). In that 
context, I do not think we can easily generalized protocol extensions 
from an almost single-stage control to a highly multi-stage control.

On the other hand, it seems that PSC-1 to PSC-4 have not been 
implemented much. Reasons behind are only guesses. Mine is that 
upgrading implementations and deployments of MPLS-TE was not worth the 
pain with respect to the added value of moving to the GMPLS flavor of 
IGPs and RSVP-TE (especially for packet-only operations). Whatever the 
actual reason for having so few implementations, PSC-n are part of the 
original GMPLS specification.

Let me quote the section about PSC in RFC 4202: "The various levels of 
PSC establish a hierarchy of LSPs tunneled within LSPs." This really 
looks like what we are doing in OTN. Yes, the discrete nature of the 
technology will introduce one more information into the SC field, but 
doing otherwise would depreciate existing GMPLS specification.

Furthermore, RFC 4203 says: "When the Switching Capability field is TDM, 
the Switching Capability specific information field includes Minimum LSP 
Bandwidth..." In other words, even if not included in the SC field so 
far, one cannot really say that a value per ODUk layer would overload 
the ISCD definition.

Thus, we have legacy vs. depreciation: my understanding of IETF work is 
to put emphasis on consistency and avoid defining new solutions when 
they already exist, even if not absolutely optimized (we are not 
building G.709 control from scratch).

My 2 cents,

Julien


Le 30/11/2011 22:37, John E Drake a écrit :
>  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]]
> >
> > 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
>