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

[Zhangfatai <[e-mail]>]

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)
Sent: 2011年12月2日 16:29
To: John E Drake
Cc: CCAMP
Subject: [CCAMP] R: OSPF OTN considerations post IETF 82 (Issue 1/2)

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>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>