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

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

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