Subject: [CCAMP] OSPF OTN considerations post IETF 82

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 23 Nov 2011 19:18:31 +0100

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 +390106002512
Mobile +393346725750
[email-masked]
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>

---

From: John E Drake <[email-masked]>
Date: Mon, 28 Nov 2011 08:45:03 -0800

Daniele,

A single switching capability value and  advertise both Unreserved and Max LSP bandwidth.

Thanks,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 23, 2011 10:19 AM
To: CCAMP
Subject: [CCAMP] OSPF OTN considerations post IETF 82

Hi CCAMP,

Thanks,
Daniele

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 28 Nov 2011 13:04:45 -0500

I support this also.

Cheers,

Lyndon

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Monday, November 28, 2011 8:45 AM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82

Daniele,

Thanks,

John

Hi CCAMP,

Thanks,
Daniele

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Nov 2011 10:22:26 -0500

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 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
> 
>  
> 
> 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.
> 
>  
> 
> *DANIELE CECCARELLI *
> *System & Technology - DU IP & Broadband*
> 
> 
> Via L.Calda, 5
> Genova, Italy
> Phone +390106002512
> Mobile +393346725750
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Nov 2011 08:14:17 -0800

I completely disagree.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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,
> a
> > 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 *

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Nov 2011 11:43:25 -0500

Great.  Care to substantiate your point?

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Nov 2011 11:59:49 -0800

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.  It also is inconsistent with the usage of Switching Capability in SDH/SONET.

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

> From: Lou Berger [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2011 8:43 AM
> To: John E Drake
> Cc: Daniele Ceccarelli; CCAMP
> >> nodes that support a smaller set of ODUks than are advertised within
> an
> >> IGP.
> >>
> >>> During the OTN OSPF draft presentation at the IETF meeting in
> Taipei
> >> two
> >>> - Issue 2: Type 2 (unres bandwidth for variable containers) and
> Type
> >> 3
> >>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3)
> as
> >> a
> >>> mandatory piece of information and the Unreserved bandiwdth TLV
> (Type
> >> 2)
> >>> interworking issues and the counter proposal was to have both
> pieces
> >> of

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Nov 2011 16:09:17 -0500

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.

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

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

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Nov 2011 13:37:17 -0800

Comments inline.  I still think this is a terrible idea and I would like to see what the rest of the WG thinks.

> Sent: Wednesday, November 30, 2011 1:09 PM
> To: John E Drake

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

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

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

> >>>> Capability Types.  So we have a few definitions: 3471 says "the
> type
> >> of
> >>>> 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
> >>>> To me, the first question to ask relates to (a), and is should
> each
> >>>> ODUk
> >>>> I think the second question to ask relates to (b), and is does
> each
> >>>> ODUk
> >>>> 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
> >>>>> quick talk with the other authors of the ID, the idea was to
> reject
> >>>> the
> >>>>> WRT issue 2: it is analyzed in section 5.3 of the draft (version
> -
> >>>> 00).
> >>>>>    In this example the advertisement of an ODUflex->ODU3
> hierarchy
> >> is
> >>>>>
> >>>>>    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
> >>>>>
> >>>>> information as mandatory and, as a consequence, merge the two
> TLVs
> >>>> into
> >>>>> a single one.
> >>>>>
> >>>>>
> >>>>>
> >>>>> This Communication is Confidential. We only send and receive
> email
> >> on

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Nov 2011 16:51:17 -0500

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

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Nov 2011 14:23:15 -0800

Yes, I think that's fair.

> Sent: Wednesday, November 30, 2011 1:51 PM
> To: John E Drake
> > Comments inline.  I still think this is a terrible idea and I would
> like to see what the rest of the WG thinks.
> >
> > [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
> > [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.
> >
> >>
> >>>
> > [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
> >>>
> >>>>>> 	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
> >>>>>>> the proposal as it would lead to an overloading of the meaning
> of
> >>>> the
> >>>>>> switching/technology layers and (b) different levels of
> hierarchy
> >> --
> >>>>>> I know this has been a much debated point, and it seems to me
> that
> >>>> they
> >>>>>> 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
> >>>>>> There's also a minor processing efficiency gained by this
> approach
> >>>> for
> >>>>>> To keep thinks generic, we probably should use TDM-1 through
> TDM-n
> >>>> as
> >>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk
> of
> >>>> the
> >>>>>>>    shown.  In case of ODUflex advertisement the MAX LSP
> bandwidth
> >>>>>> needs
> >>>>>>>
> >>>>>>>    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.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>    example.  Supposing there are two TE-links (A and B) with
> MAX
> >>>> LSP
> >>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Nov 2011 17:53:51 -0500

Okay, it's good to understand each other.

Referring back to my earlier mail:
> ... Switching Capability Types  represent (a) different
> 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.

And you're proposing invalidating usage (b).

My proposal is based on (b) being valid. (I was, of course, operating on
the premise of today's current RFCs ;-) I agree that if usage (b) is
invalidated, my proposal makes no sense.

I'm a bit ambivalent on invalidating usage (b).  On one hand, I like the
simplicity implied by the change (and of saying the SC is just is an
indicator of label type and ISCD format).  On the other hand, I've
always found some, albeit not significant, processing value in
constructing SC/layer specific topologies (and even policies.)  -- I
also need some time to digest this proposal in the context of MLN/MRN.

Clearly invalidating (b) and deprecating PSC-2->n, is a notable change
to GMPLS and one that we will need to be discussed agreed to in both
CCAMP and PCE.  Although, if your assertion on how most use PSC and SC
holds, it shouldn't be too contentious a discussion.  Are you willing to
put together a draft with your proposed changes to Switching Capability
Types so that we can codify consensus on the topic?

Lou