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

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 2 Dec 2011 09:29:07 +0100

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: +39 0396863033
[email-masked]

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] 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:[email-masked]]
> 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:[email-masked]]
> >> 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: [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,
> >>>> 	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 +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>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> CCAMP mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Zhangfatai <[email-masked]>
Date: Fri, 02 Dec 2011 08:51:46 +0000

Hi all,

I agree that there is no need to overload Switching Cap.

Thanks
 
Fatai

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

Thanks
Sergio and Pietro

SERGIO BELOTTI

ALCATEL-LUCENT

---

From: Julien Meuric <[email-masked]>
Date: Tue, 06 Dec 2011 16:31:27 +0100

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:[email-masked]]
> >
> > John,
> >
> > see below
> >
> >
> >> 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.
> >
> > 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.
> >
>  [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."
> >
>  [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:[email-masked]] 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)
> >>>
> >>>>> -----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, Since I raised the point, I guess I need to
> >>>>> champion it! (With chair hat off.)
> >>>>>
> >>>>> All,
> >>>>>
> >>>>> Daniele said:
> >>>>>> 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
> >>>>> just references 4202), but does equate it with a "layer".
> >>>>> While it allows for hierarchy within a "layer" it also says
> >>>>> hierarchy
> > occurs
> >>>>> and FSC), and (b) is identifiable in the original types
> >>>>> plus the
> >>> definition
> >>>>> of PSC-1 through PSC-4.
> >>>>>
> >>>>> ODUk be modeled as a separate layer?
> >>>>>
> >>>>> ODUk represent a different level of hierarchy?
> >>>>>
> >>>>> 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
> >>>>> 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.
> >>>>>
> >>>>>> 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)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Early proposal was to have, in the case of variable
> >>>>>> containers advertisements (i.e. ODUflex), the MAX LSP
> >>>>>> bandwidth TLV (Type 3)
> >>> as
> >>>>> a
> >>>>>> The comment received is that optional information can
> >>>>>> lead to interworking issues and the counter proposal was
> >>>>>> to have both
> >>> pieces
> >>>>> of
> >>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP &
> >>>>>> Broadband*
> >>>>>>
> >>>>>>
> >>>>>> Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile
> >>>>>> +393346725750 [email-masked]
> >>>>>> www.ericsson.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________ CCAMP
> >>>>>> mailing list [email-masked]
> >>>>> _______________________________________________ CCAMP
> >>>>> mailing list [email-masked]
>  _______________________________________________ CCAMP mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Julien Meuric <[email-masked]>
Date: Tue, 06 Dec 2011 17:08:57 +0100

Hi Fatai.

As co-author of draft-ietf-pce-inter-layer-ext, I believe you will agree 
on the fact that having a Switching Capability per ODUk layer would make 
the use of objects including a Switching Cap field rather 
straightforward and enables a fine-grained resource description, e.g. in:
- REQ-ADAP-CAP object, to precisely identify the type of adaptation 
requested by a higher layer, or to get a clear feedback on the missing 
adaptation for unsuccessful path computations;
- SERVER_LAYER_INFO sub-object, to precisely identify the type of server 
layer within the ERO.

Do not you think that summarizing G.709 by a single Switching Cap value 
would take some capabilities away? What would you suggest so as to 
achieve the same level of details in that scenario?

Regards,

Julien

Le 02/12/2011 09:51, Zhangfatai a écrit :
>  [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO
>  (SERGIO)
>
>  Thanks Sergio and Pietro
>  ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio
>  Evolution
>
>  via Trento 30 , Vimercate(MI) Italy T: +39 0396863033
>  -----Messaggio originale----- Da: [email-masked]
>  [mailto:[email-masked]] 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)
>
> > [mailto:[email-masked]] 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
> >
> >
>  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.
> >
> >> 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."
> >
>  describe how a given interface switches the information with which
>  it is provided. This has nothing to do with the interface's
>  bandwidth.
>
> >
> > Lou
> >>
> >>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP
> >>>>>> PSC1-2-3-4 already overloads the meaning of the
> >>>>>> switching capability field)
> >>>>>
> >>>>> While it allows for hierarchy within a "layer" it also
> >>>>> says hierarchy
> > occurs
> >>>>> 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.
> >>>>>
> >>>>>> definition of PSC1-2-3-4 already overloads the meaning
> >>>>>> of the switching capability field)
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Zhangfatai <[email-masked]>
Date: Tue, 06 Dec 2011 19:21:12 +0000

Hi Julien,

I agree the requirement that you mentioned, but it can be resovled without extending Switching Cap.

It is known that there are two cases described in RFC5212 and RFC5339, one is MRN, another one is MLN. In RFC5212, it says:
===============================================================================
Thus, a control plane region, identified by its switching type value (e.g., TDM), can be sub-divided into smaller-granularity component networks based on "data plane switching layers".  The  Interface Switching Capability Descriptor (ISCD) [RFC4202],  identifying the interface switching capability (ISC), the encoding type, and the switching bandwidth granularity, enables the characterization of the associated layers.

 In this document, we define a multi-layer network (MLN) to be a Traffic Engineering (TE) domain comprising multiple data plane switching layers either of the same ISC (e.g., TDM) or different ISC (e.g., TDM and PSC) and controlled by a single GMPLS control plane  instance.  We further define a particular case of MLNs.  A multi- region network (MRN) is defined as a TE domain supporting at least two different switching types (e.g., PSC and TDM), either hosted on the same device or on different ones, and under the control of a single GMPLS control plane instance.
=====================================================================================
Therefore, for MRN case, we can use Switching Cap to differentiate the different "layers"; for MLN case (same ISC with different granularity), we can use Switching Cap & Signal Type (& Encoding Type as well) to differentiate the different granularity.

So, come back to your question, it can be achived by using Switching Cap&Encoding Type&Signal Type to identify the granularity requested in OTN networks(e.g., this information can be carried in SERVER_LAYER_INFO sub-object) .

Lastly, in my opinion,  if there is no issue based on the existing mechnism or definition without extending Switching Cap, I don't think we need to extend Switching Cap.

Thanks

Fatai

________________________________________
发件人: Julien Meuric [[email-masked]]
发送时间: 2011年12月7日 0:08
到: Zhangfatai
Cc: CCAMP; [email-masked]
主题: Re: [CCAMP] R:  OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi Fatai.

Regards,

Julien

---

From: Zhangfatai <[email-masked]>
Date: Tue, 06 Dec 2011 19:34:37 +0000

Hi Julien,

For TDM networks, Signal Type has beed introduced in RFC4606 or RFC4328 or G.709V3 drafts to address what you need.

Anything is missed in routing or signaling? 

Thanks

Fatai

_______________________________________
发件人: [email-masked] [[email-masked]] 代表 Julien Meuric [[email-masked]]
发送时间: 2011年12月6日 23:31
到: John E Drake; Lou Berger
Cc: CCAMP
主题: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi John, hi Lou.

My 2 cents,

Julien

---

From: Lou Berger <[email-masked]>
Date: Tue, 06 Dec 2011 15:28:52 -0500

I think Julien has it right (and as I've said on this list), it's a
question of leveraging or deprecating the use of SC as an indicator of
hierarchy.  Deprecating this use means that we need to move into a
technology specific hierarchy indicator, which is what you're saying ST
provides.

The move from generic to technology-specific mechanisms, really runs
counter to the basic principals of GMPLS and is likely to have some
nasty ripple effects.  (For example do we just obsolete 6001, or do a
bis which allows for / requires carrying the technology-specific layer
identifier?)

Lou

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 6 Dec 2011 16:47:39 -0500

Hi Lou, Julien,

For clarification, you're specifically concerned with the hierarchical use of OTN signals, right?  Because these are not always used in a hierarchy, an OTN link can carry LSPs with different ODU rates at the same level of hierarchy - for example an OTU3 link could be carrying ODU0, ODU1 and ODU2 connections at the same time and at the same hierarchical level.  In that case you would use Signal Type to characterize the LSP being signaled, as has been done before.

Thanks,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, December 06, 2011 12:29 PM
To: Zhangfatai
Cc: CCAMP
Subject: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 7 Dec 2011 05:21:08 -0800

Hi,

I am unaware of any requirement to indicate layers in a multi-layer scenario - I went back and looked at both RFC5339 and RFC6001 and didn't see anything.  And just to be clear, layers are technology specific.

Since you mention RFC6001, I think it should be pointed out that that RFC does not address multi-layer networking, but only multi-region networking.

Thanks,

John

> Cc: Julien Meuric; John E Drake; CCAMP
> Subject: Re: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
> 1/2)
>
>
> > For TDM networks, Signal Type has beed introduced in RFC4606 or
> RFC4328 or G.709V3 drafts to address what you need.
> >
> what
> it

---

From: Lou Berger <[email-masked]>
Date: Thu, 08 Dec 2011 10:15:46 -0500

John,
	As I'm sure you are aware, hierarchy within the same technology layer
has been around for a while.  When we defined GMPLS, there was a desire
to represent level of hierarchy within a switching technology.  (This
requirement came in the context of PSC).  At the time we choose to
represent both switching switching technology and level of hierarchy
(within the technology) in the SC field.

On one hand one can argue (as was our thinking at the time) that there
was only a need to represent a few per-technology hierarchies and that
it simplified GMPLS routing to operate on a minimum number of generic
fields.   On the other hand, one could argue that the SC field should
not be overloaded and there should be a separate per-technology
hierarchy indicator field.  Hindsight leaves me feeling that the latter
choice may have been the better one.  I don't recall exactly how we came
to this conclusion, but there were lots or related discussions among the
authors/editors (which includes you too!).  My bet is that it came from
Yakov, myself or Peter... Perhaps your memory is better than mine, but
either way please feel free to blame me ;-)

No matter what, you now raise a good question.  Where do we go from here?
a. Keep SC as it is, with it's overloaded semantics as both a
   common (across technologies) label/ISCD type indicator and
   intra-type hierarchy indicator.
b. Deprecate use of SC as an intra-type hierarchy indicator, and
   add such indication to technology-specific ISCDs.
c. Something else.

I (and I believe Julien) are proposing (a), I believe you and the OTN
co-authors are proposing/implying (b).

Lou

On 12/7/2011 8:21 AM, John E Drake wrote:
> Hi,
> 
> I am unaware of any requirement to indicate layers in a multi-layer
> scenario - I went back and looked at both RFC5339 and RFC6001 and
> didn't see anything.  And just to be clear, layers are technology
> specific.
> 
> Since you mention RFC6001, I think it should be pointed out that that
> RFC does not address multi-layer networking, but only multi-region
> networking.
> 
> Thanks,
> 
> John
>

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Dec 2011 02:04:48 -0800

Lou,

I think I would argue with your characterization of a.  Other than PSC 1-4, which as I have previously stated was an abject failure, switching capability was never used to indicate layers within the same switching technology.  So, I would argue that what we are doing in OTN is really a.  I.e., keep switching capability as it is, an indicator of the switching technology.

Thanks,

John

> Sent: Thursday, December 08, 2011 7:16 AM
> To: John E Drake
> Cc: Zhangfatai; Julien Meuric; CCAMP
> >>> the Switching Capability specific information field includes
> Minimum
> >> LSP
> >>> Thus, we have legacy vs. depreciation: my understanding of IETF
> work
> >> is
> in
> to

---

From: Zhangfatai <[email-masked]>
Date: Fri, 09 Dec 2011 16:01:47 +0000

Hi all,

I personally agree with what John said, because we can find the evidence from the existing RFCs such as RFC4606, RFC4328, RFC5212 and RFC6001 which don't extend SC.

I think it is also consistent with what Julien said ("IETF work is to put emphasis on consistency and avoid defining new solutions").

Thanks

Fatai

________________________________________
发件人: John E Drake [[email-masked]]
发送时间: 2011年12月9日 18:04
到: Lou Berger
Cc: Zhangfatai; Julien Meuric; CCAMP
主题: RE: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou,

Thanks,

John

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 12 Dec 2011 11:30:46 +0100

Hi all,

I think whatever we do we are not consisted with what have been done up to now. If we define multiple values of switching capability we're no longer consistent with the SDH switching capability case, while on the other hand if we use a single value we're no longer consistent with the PSC case, so from this point of view I think the issue can't be solved.

Hence I'd prefer to keep a single OTN value for the same reasons already expressed by John.

Thanks
Daniele

>Sent: giovedì 8 dicembre 2011 16.16
>To: John E Drake
>Cc: CCAMP
>       As I'm sure you are aware, hierarchy within the same
>technology layer has been around for a while.  When we defined
>GMPLS, there was a desire to represent level of hierarchy
>within a switching technology.  (This requirement came in the
>context of PSC).  At the time we choose to represent both
>switching switching technology and level of hierarchy (within
>the technology) in the SC field.
>
>On one hand one can argue (as was our thinking at the time)
>that there was only a need to represent a few per-technology
>hierarchies and that it simplified GMPLS routing to operate on
>a minimum number of generic
>not be overloaded and there should be a separate
>per-technology hierarchy indicator field.  Hindsight leaves me
>feeling that the latter choice may have been the better one.
>I don't recall exactly how we came to this conclusion, but
>there were lots or related discussions among the
>authors/editors (which includes you too!).  My bet is that it
>came from Yakov, myself or Peter... Perhaps your memory is
>better than mine, but either way please feel free to blame me ;-)
>
>I (and I believe Julien) are proposing (a), I believe you and
>the OTN co-authors are proposing/implying (b).
>
>Lou
>
>>> question of leveraging or deprecating the use of SC as an indicator
>>> of hierarchy.  Deprecating this use means that we need to
>move into a
>>> technology specific hierarchy indicator, which is what
>you're saying
>>> ST provides.
>>>
>>>> context, I do not think we can easily generalized protocol
>>>> extensions from an almost single-stage control to a highly
>multi-stage control.
>>>>
>>>> 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
>>>> technology will introduce one more information into the SC field,
>>>> but doing otherwise would depreciate existing GMPLS specification.
>>>>
>>>> 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
>>>>>  [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.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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."
>>>>>>
>>>>>>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re:
>[CCAMP] OSPF OTN
>>>>>>>>>> considerations post IETF 82 (Issue
>>>>>>>> 1/2)
>>>>>>>>>>
>>>>>>>>>> and FSC), and (b) is identifiable in the original types plus
>>>>>>>>>> the
>>>>>>>> definition
>>>>>>>>>> of PSC-1 through PSC-4.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> G.709v3. (2) that
>identified in
>>>>>>>>>> to the current definition of ISCD.) (3) that
>mailing list

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 12 Dec 2011 11:59:50 +0100

Hi all,

we agree with John's consideration on keeping switching capability as indicator of the switching technology and not overloading the meaning with layers within the same technology.

Thanks

Sergio and Pietro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 9 dicembre 2011 11.05
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou,

Thanks,

John

> extensions
> but

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 12 Dec 2011 10:01:51 -0500

+1

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Monday, December 12, 2011 3:00 AM
To: John E Drake; Lou Berger
Cc: CCAMP
Subject: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi all,

Thanks

Sergio and Pietro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 9 dicembre 2011 11.05
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou,

Thanks,

John

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Mon, 12 Dec 2011 09:52:45 -0600

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ong, Lyndon
Sent: Monday, December 12, 2011 10:02 AM
To: BELOTTI, SERGIO (SERGIO); John E Drake; Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

+1

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Monday, December 12, 2011 3:00 AM
To: John E Drake; Lou Berger
Cc: CCAMP
Subject: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi all,

Thanks

Sergio and Pietro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 9 dicembre 2011 11.05
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou,

Thanks,

John

---

From: Lou Berger <[email-masked]>
Date: Mon, 12 Dec 2011 12:07:34 -0500

John,
	You're redefining 'a' (i.e., dropping "intra-type hierarchy
indicator").  We've already agreed that your position is that this
capability (and PSC 2-N) should be deprecated, i.e., 'b'.

I think this is a good to general discussion to have/continue, but IMO,
it goes beyond just OTN.

BTW We had lost of discussion on use of SC in the context of the
relatively recent ethernet/PBB RFCs.  At the time, there was general
agreement to use different SC values to identify hierarchy level  Given
that different label formats were involved as well, this
point/discussion may been obscured.

Lou

On 12/9/2011 5:04 AM, John E Drake wrote:
> Lou,
> 
> I think I would argue with your characterization of a.  Other than
> PSC 1-4, which as I have previously stated was an abject failure,
> switching capability was never used to indicate layers within the
> same switching technology.  So, I would argue that what we are doing
> in OTN is really a.  I.e., keep switching capability as it is, an
> indicator of the switching technology.
> 
> Thanks,
> 
> John
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 12 Dec 2011 12:10:57 -0500

Fatai,
	Unfortunately we have some competing precedents.  As I just mentioned
in my mail to John, the consensus was to introduce 3 new types.
(Albeit, consensus on this specific point is obscured by the use of
different label formats.)

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 12 Dec 2011 12:19:07 -0500

Daniele,
	I agree we have conflicting precedent.  I also agree we should try to
quickly make a decision on this.  I think we should make a 'generalized'
and 'common control' consensus call and not a (OTN) technology specific
call, so we don't have to revisit this for the next technology.

Lou

On 12/12/2011 5:30 AM, Daniele Ceccarelli wrote:
> Hi all,
> 
> I think whatever we do we are not consisted with what have been done
> up to now. If we define multiple values of switching capability we're
> no longer consistent with the SDH switching capability case, while on
> the other hand if we use a single value we're no longer consistent
> with the PSC case, so from this point of view I think the issue can't
> be solved.
>

---

From: Rajan Rao <[email-masked]>
Date: Mon, 12 Dec 2011 18:48:49 +0000

Lou,

I am not seeing a big gain by encoding bottom most ODUk in  SC field for the following reasons:

1) it doesn't give full hierarchy picture supported on the link.  Meaning,  sub-ODUj services over this link still requires more than SC field.
2) the only case it simplifies is service creation at ODUk layer.
3) once a sub-ODUj service is created,  the link is no longer capable of service at ODUk layer. So,  you still have to look at available-ODU advertisement  even for  ODUk services.

My preference is like rest of the authors.

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ong, Lyndon
Sent: Monday, December 12, 2011 7:02 AM
To: BELOTTI, SERGIO (SERGIO); John E Drake; Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

+1

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Monday, December 12, 2011 3:00 AM
To: John E Drake; Lou Berger
Cc: CCAMP
Subject: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Hi all,

Thanks

Sergio and Pietro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 9 dicembre 2011 11.05
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou,

Thanks,

John

>       As I'm sure you are aware, hierarchy within the same technology 
> layer has been around for a while.  When we defined GMPLS, there was a 
> desire to represent level of hierarchy within a switching technology.  
> (This requirement came in the context of PSC).  At the time we choose 
> to represent both switching switching technology and level of 
> hierarchy (within the technology) in the SC field.
>
> hierarchy indicator field.  Hindsight leaves me feeling that the 
> latter choice may have been the better one.  I don't recall exactly 
> how we came to this conclusion, but there were lots or related 
> discussions among the authors/editors (which includes you too!).  My 
> bet is that it came from Yakov, myself or Peter... Perhaps your memory 
> is better than mine, but either way please feel free to blame me ;-)
>
> > Since you mention RFC6001, I think it should be pointed out that 
> > that RFC does not address multi-layer networking, but only 
> > multi-region networking.
> >
> > Thanks,
> >
> > John
> >
> >> technology specific hierarchy indicator, which is what you're 
> >> saying
> ST
> >> provides.
> >>
> >> The move from generic to technology-specific mechanisms, really 
> >> runs counter to the basic principals of GMPLS and is likely to have 
> >> some nasty ripple effects.  (For example do we just obsolete 6001, 
> >> or do
> a
> >>> On the one hand, SONET/SDH and OTN are close: it is highly 
> >>> tempting
> >> to
> >>> 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
> >>> Let me quote the section about PSC in RFC 4202: "The various 
> >>> levels
> >> of
> >>> Furthermore, RFC 4203 says: "When the Switching Capability field 
> >>> is
> >> TDM,
> >>>>  asserting that there is "ambiguity related to bandwidth', 
> >>>> without  providing any evidence.
> >>>>
> >>>>> 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."
> >>>>>
> >>>>  [JD] I think it clarifies that switching capabilities is meant 
> >>>> to  describe how a given interface switches the information with
> which
> >> it

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Dec 2011 13:37:54 -0800

Hi Julien,

> from an almost single-stage control to a highly multi-stage control.

Are you saying that OTN can be considered "highly multi-stage"?  (asking, for my edification)

> original GMPLS specification.

I believe the primary reason is that in packet networks, hierarchy is primarily used for control plane scale.  In practice, this hierarchy was achieved as LDP over RSVP (not RSVP over RSVP, where one might have considered PSC levels); the current trend is LDP or RSVP over BGP.  (Perhaps we should signal "labeled BGP" as PSC-n (n>1) using the BGP TE attribute!)

> doing otherwise would depreciate existing GMPLS specification.

Agree completely with you.  If the thinking behind the PSC levels from one of the original authors is of any interest, here it is:

For packet networks, there is clearly no pre-assigned bandwidth for PSC levels.  The intent was purely to control hierarchy; one was allowed to tunnel PSC-1 over PSC-2 ... over TDM over lambda over fiber.  One could (should, would) not tunnel fiber over lambda, or lambda over TDM (or TDM over packet, but then, MPLS is rife with layer violations.)  Likewise, an attempt to tunnel PSC 2 over PSC 1 was to be disallowed (or flagged for management intervention).

One could have considering defining levels of TDM as well, but (a) SDH was beyond me; (b) the standardization atmosphere around SDH was extremely charged; (c) my eyes would glaze over whenever SUKLM was mentioned.  Could one really assign SC TDM levels to PDH/SDH that captured the allowed hierarchy?

With ODU, I believe that one can simply assign numbers to levels such that the tunneling hierarchy is adequately captured.  I believe (but am not completely sure, as people here are amazingly innovative) that one cannot tunnel ODU5 over ODU0.  If that is of value, then there should be multiple TDM levels (or perhaps, ODU levels, between TDM and lambda).  BTW, these levels have nothing to do with actual bandwidth.

> Thus, we have legacy vs. depreciation:

Rather, I would say, think utility -- if it is useful to have multiple SC levels to capture the ODUk hierarchy, please do so.  You will not escape putting bandwidth somewhere (as I understand, there are multiple bandwidths for ODU2, and one has to be careful with suffixes and decimal places), probably in the ISCD.

One point of consideration is ODUflex -- where does it fit in the hierarchy?  How does one (if at all) assign an SC value to ODUflex?

> my understanding of IETF work is

Clearly, one can solve the problem in multiple ways and in multiple TLVs, including rolling an entirely new one.

> My 2 cents,

ditto

Kireeti.

---

From: <[email-masked]>
Date: Tue, 13 Dec 2011 08:40:48 +0000

Kireeti,

I'm not surprised you are confused.  Let me try and shed a little light on the key underlying arch principles at play here.....

'Time' is a key resource dimension in networking ('space' is another one).  There are 2 main ways we can carve-up and label a time resource and so allocate layer network resource to many (client) users:

1	regular time-slices of (i) known starting epoch and (ii) known duration.
2	irregular time-slices of (i) variable starting epoch and (ii) variable duration

The former leads to the co-cs mode network technologies.  A forwarding label now becomes an implicit position in time (the 'time-slot') and the resource provided is fixed (since the duration is a precise number of bits at some bit rate...a bit being the atomic unit of (Shannon) information resource).

The latter leads to the cl-ps and co-ps mode network technologies.  Since we must have a connection in order to be able to deterministically manage resource we will only discuss the co-ps mode further (noting that by providing a parent connection the child co-ps mode traffic units can take various short cuts on their labelling vs their cl-ps mode cousins, specifically:  omit SA label, omit PID label (if constant client), reduce scope of DA label to link-unique rather than network-unique].  Here, a link-unique forwarding label (==DA proxy) now needs to be explicitly provided in each traffic unit and the traffic unit duration can be of a variable number of bits...so the resource required may not be known a priori of the arrival (at some variable epoch) of the traffic unit [Aside=> ATM fixed the number of bits in the traffic unit in order to attempt to provide some further determinism of resource demanded...and this has key implications wrt hierarchy, ie one cannot have 'self-nesting' in ATM, ie ATMoverATM...a critical observation that we come back to].

Now these factors on how we carve-up/label a time resource give rise to some key arch behaviours and differences between the modes...for example:
A	One is forced to have proper (single-source) connections in the co-cs mode....not necessarily true for the co-ps mode
B	One is forced to take the MP/CP logically OOB in the co-cs mode..... not necessarily true for the co-ps mode
C	Transparency (which is THE key client service property of a transport network) is always provided in the co-cs mode (ie all client symbols treated equally wrt forwarding importance irrespective of the ultimate TOS nature of the message/file/stream application, which must always be present in all networking cases).... not necessarily true for the co-ps mode
D	A key corollary of transparency is that there is no such thing as 'QoS classes' in a connection of the co-cs mode (which a very good thing for a transport network).... not necessarily true for the co-ps mode
E	Crucially (as we will see shortly) one cannot create hierarchy by 'self-nesting' traffic units of the co-cs mode, ie SDH VC4overVC4 is obviously not possible.....one can however 'self-nest' variable length generically structured traffic units of the co-ps mode (ATM being the exception as noted earlier due to the fixed traffic unit resource size).  

Now the PDH form of the co-cs mode was based on layer networks which could have independent clocks at each layer (within certain ranges).  The problem with this however is that one has to demultiplex the whole stack up to the highest layer of interest as one could not extract this easily/directly from some lower level aggregate.  SDH attempted to address this by providing much tighter allowed clock ranges over fewer layer networks.

However, these is still a major weakness here in SDH related to point E above which I will now explain...

In all networking scenarios there is always a:
-	TOS layer network like IP.....this interfaces directly with external message/file/stream applications) and a
-	BOS layer network present....this modulates an EM wave in either metallic/optical/radio media as this is the means to transfer information, ultimately sourced from the TOS message/file/stream applications, over large geographic distance.

A key measure of efficacy in networking (==cost) is the layer network distance TOS to BOS, ie how many layer networks do we have to create/configure/manage?....we need to reduce this to the smallest number possible (the answer is not one of course ;-)).  

Now consider the nature of the traditional PDH/SDH hierarchies and the fact that when not dealing with a TOS public network the key service one provides is the transparent carriage of the layer network of party M over a layer network of party N...this is a client/server relationship.  This means that party N has to carry the traffic units (ie whole bit-stream comprising DP/MP/CP) of the layer network of party M in a completely transparent manner.....so the payload area of the DP traffic units of the layer network of party N must fully contain al the DP/CP/MP traffic units of the layer network of party M.

But now what happens when party N wants its traffic units transparently carried over the layer network of some other party, O say? This means we have to create a even lower layer network to transparently carry of the DP/CP/MP traffic units of party N.  We can recurse this argument for carrying the traffic units of party O over an even lower layer network belonging to party P, etc, etc. 

What we end up doing is a creating a never-ending hierarchy of formally standardised layer networks, ie in theory an unbounded TOS to BOS layer network distance.  This is obviously not a great idea.

The current OTN just replicates the PDH/SDH hierarchy ideas.  What we really need is to recognise the above problem (ie we can't keep creating formal hierarchy just to carry some arbitrary defined layer network X over some further arbitrary defined layer network Y, etc) and move to the notion of a generic 'digital wrapper' framing structure for the traffic units of a true BOS co-cs mode layer network....which is in many ways looks like the co-ps mode, though we need the key arch behaviours I noted earlier for our BOS transport layer network, especially the notion of transparency.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kireeti Kompella
> Sent: 12 December 2011 21:38
> To: Julien Meuric
> Cc: CCAMP
> I believe the primary reason is that in packet networks, hierarchy is
> primarily used for control plane scale.  In practice, this hierarchy was
> achieved as LDP over RSVP (not RSVP over RSVP, where one might have
> considered PSC levels); the current trend is LDP or RSVP over BGP.
> (Perhaps we should signal "labeled BGP" as PSC-n (n>1) using the BGP TE
> attribute!)
> 
> Agree completely with you.  If the thinking behind the PSC levels from
> one of the original authors is of any interest, here it is:
> 
> For packet networks, there is clearly no pre-assigned bandwidth for PSC
> levels.  The intent was purely to control hierarchy; one was allowed to
> tunnel PSC-1 over PSC-2 ... over TDM over lambda over fiber.  One could
> (should, would) not tunnel fiber over lambda, or lambda over TDM (or TDM
> over packet, but then, MPLS is rife with layer violations.)  Likewise,
> an attempt to tunnel PSC 2 over PSC 1 was to be disallowed (or flagged
> for management intervention).
> 
> One could have considering defining levels of TDM as well, but (a) SDH
> was beyond me; (b) the standardization atmosphere around SDH was
> extremely charged; (c) my eyes would glaze over whenever SUKLM was
> mentioned.  Could one really assign SC TDM levels to PDH/SDH that
> captured the allowed hierarchy?
> 
> With ODU, I believe that one can simply assign numbers to levels such
> that the tunneling hierarchy is adequately captured.  I believe (but am
> not completely sure, as people here are amazingly innovative) that one
> cannot tunnel ODU5 over ODU0.  If that is of value, then there should be
> multiple TDM levels (or perhaps, ODU levels, between TDM and lambda).
> BTW, these levels have nothing to do with actual bandwidth.
> 
> Rather, I would say, think utility -- if it is useful to have multiple
> SC levels to capture the ODUk hierarchy, please do so.  You will not
> escape putting bandwidth somewhere (as I understand, there are multiple
> bandwidths for ODU2, and one has to be careful with suffixes and decimal
> places), probably in the ISCD.
> 
> One point of consideration is ODUflex -- where does it fit in the
> hierarchy?  How does one (if at all) assign an SC value to ODUflex?
> 
> Clearly, one can solve the problem in multiple ways and in multiple
> TLVs, including rolling an entirely new one.
> 
> > My 2 cents,
> 
> ditto
> 
> Kireeti.
> 
> > Julien
>

---

From: Julien Meuric <[email-masked]>
Date: Mon, 19 Dec 2011 11:27:57 +0100

Hi Kireeti,

See below.

Cheers,

Julien

Le 12/12/2011 22:37, Kireeti Kompella a écrit :
> > 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

[JM] This is what I said/wrote (but you may also work on my English 
language edification).
[JM] SDH core network planing teams are currently used to working on a 
single switching granularity: VC-4. When they look at the switching 
granularities in OTN cross-connects, their eyes start to glaze (think of 
SUKLM). They rather hope that smaller containers will be aggregated 
before entering the core (like in SDH), or that TDM services will evolve 
into a simplified sub-part of the hierarchy (e.g. ODUflex and ODU4)...

> > 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.
>
>  primarily used for control plane scale. In practice, this hierarchy
>  was achieved as LDP over RSVP (not RSVP over RSVP, where one might
>  have considered PSC levels); the current trend is LDP or RSVP over
>  BGP. (Perhaps we should signal "labeled BGP" as PSC-n (n>1) using
>  the BGP TE attribute!

[JM] My last experience in mixing BGP and GMPLS was in L1VPN WG. I've 
realized since that I should rather have worked on a GUI...

>
> > 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.
>
>  Agree completely with you. If the thinking behind the PSC levels
>  from one of the original authors is of any interest, here it is:
>
>  For packet networks, there is clearly no pre-assigned bandwidth for
>  PSC levels. The intent was purely to control hierarchy; one was
>  allowed to tunnel PSC-1 over PSC-2 ... over TDM over lambda over
>  fiber. One could (should, would) not tunnel fiber over lambda, or
>  lambda over TDM (or TDM over packet, but then, MPLS is rife with
>  layer violations.) Likewise, an attempt to tunnel PSC 2 over PSC 1
>  was to be disallowed (or flagged for management intervention).
>
>  One could have considering defining levels of TDM as well, but (a)
>  SDH was beyond me; (b) the standardization atmosphere around SDH was
>  that the tunneling hierarchy is adequately captured. I believe (but
>  am not completely sure, as people here are amazingly innovative) that
>  one cannot tunnel ODU5 over ODU0. If that is of value, then there
>  should be multiple TDM levels (or perhaps, ODU levels, between TDM
>  and lambda). BTW, these levels have nothing to do with actual
>  bandwidth.
>
[JM] Thank you for the bit of history. At that time, what a foolish idea 
to control transmission circuits using RSVP-TE! Have you ever considered 
MPLS label configuration using TL1 over CLNP?... ;-)

> > 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.
> >
>  Rather, I would say, think utility -- if it is useful to have
>  multiple SC levels to capture the ODUk hierarchy, please do so. You
>  will not escape putting bandwidth somewhere (as I understand, there
>  are multiple bandwidths for ODU2, and one has to be careful with
>  suffixes and decimal places), probably in the ISCD.

[JM] I guess we all agree the information will be in {ISCD, IACD}.

>  hierarchy?

[JM] That is an open discussion if that path is taken. I believe its 
definition can be reflected in several ways in the IGP (e.g. L2SC over 
ODUflex in IACD).

>  How does one (if at all) assign an SC value to ODUflex?

[JM] Ask IANA? ;-)

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

---

From: Julien Meuric <[email-masked]>
Date: Tue, 20 Dec 2011 15:54:07 +0100

Hi Fatai.

About the IGP, I believe we agree on several things:
- we are dealing with the ODUk layers within the OTN technology/regions;
- the ISCD is an appropriate place to put the information on ODUk 
capabilities of nodes.

What we disagree on:
- using the term "extension" to refer to encoding the hierarchy level in 
the SC field: the _fact_ is that PSC-[1~4] are part of existing RFCs 
(e.g. 4203);
- selecting the SC field as an information on the hierarchy level.

This leaves us with an open discussion on the latter. We already have 2 
options on the table for the ISCD in IGPs:
a) multiple SC values,
b)"Switching Cap & Signal Type (& Encoding Type as well)".

First of all, I do not believe the original intend of SC alone was to 
reflect the notion of region: xSC acronyms may map to "regions", but 
from a codepoint perspective we can have several values behind a single 
xSC (e.g. x=P).

Then you propose to use the "[OTN] Signal Type": as opposed to a) above, 
this is a new extension, created in 
draft-ietf-ccamp-gmpls-ospf-g709v3-00. As emphasized by Kireeti, the SC 
field should allow to constrain path computation into a range or a 
sub-part of the hierarchy (without necessarily specifying a full list). 
The I-D uses a single SC (OTN-TDM) for the whole OTN, which means the SC 
field is useless to prune the network graph when routing an ODUk: even 
for pruning, a CSFP implementation needs to parse some OTN-specific 
sub-TLVs. Hence I prefer the "old-fashion" approach which represent the 
hierarchy information at a higher level in the IGP, like it was done for 
PBB-TE (RFC 6060).

Regards,

Julien

Le 06/12/2011 20:21, Zhangfatai a écrit :
>  It is known that there are two cases described in RFC5212 and
>  RFC5339, one is MRN, another one is MLN. In RFC5212, it says:
> 
Thus, a control plane region, identified by its switching type value 
(e.g., TDM), can be sub-divided into smaller-granularity component 
networks based on "data plane switching layers".  The  Interface 
Switching Capability Descriptor (ISCD) [RFC4202],  identifying the 
interface switching capability (ISC), the encoding type, and the 
switching bandwidth granularity, enables the characterization of the 
associated layers.
>
>  In this document, we define a multi-layer network (MLN) to be a
>  Traffic Engineering (TE) domain comprising multiple data plane
>  switching layers either of the same ISC (e.g., TDM) or different ISC
>  (e.g., TDM and PSC) and controlled by a single GMPLS control plane
>  instance. We further define a particular case of MLNs. A multi-
>  region network (MRN) is defined as a TE domain supporting at least
>  two different switching types (e.g., PSC and TDM), either hosted on
>  the same device or on different ones, and under the control of a
>  single GMPLS control plane instance.
> 
Therefore, for MRN case, we can use Switching Cap to differentiate the 
different "layers"; for MLN case (same ISC with different granularity), 
we can use Switching Cap & Signal Type (& Encoding Type as well) to 
differentiate the different granularity.
>
>  So, come back to your question, it can be achived by using Switching
>  Cap&Encoding Type&Signal Type to identify the granularity requested
>  in OTN networks(e.g., this information can be carried in
>  SERVER_LAYER_INFO sub-object) .
>
>  Lastly, in my opinion, if there is no issue based on the existing
>  mechnism or definition without extending Switching Cap, I don't think
>  we need to extend Switching Cap.
>
>
>  Thanks
>
>  Fatai
>
>
>
>  ________________________________________ 发件人: Julien Meuric
>  [[email-masked]] 发送时间: 2011年12月7日 0:08 到: Zhangfatai Cc:
>  CCAMP; [email-masked] 主题: Re: [CCAMP] R: OSPF OTN considerations post
>  IETF 82 (Issue 1/2)
>
>  Hi Fatai.
>
>  As co-author of draft-ietf-pce-inter-layer-ext, I believe you will
>  agree on the fact that having a Switching Capability per ODUk layer
>  would make the use of objects including a Switching Cap field rather
>  straightforward and enables a fine-grained resource description, e.g.
>  in: - REQ-ADAP-CAP object, to precisely identify the type of
>  adaptation requested by a higher layer, or to get a clear feedback on
>  the missing adaptation for unsuccessful path computations; -
>  SERVER_LAYER_INFO sub-object, to precisely identify the type of
>  server layer within the ERO.
>
>  Do not you think that summarizing G.709 by a single Switching Cap
>  value would take some capabilities away? What would you suggest so as
>  to achieve the same level of details in that scenario?
>
>  Regards,
>
>  Julien
>
>
> >> 1:09 PM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject:
> >>> carried in other fields, and as Daniele noted, it
> >>> significantly overloads to intended meaning of Switching
> >>> Capability.
> >>
> >> completely consistent with the base GMPLS definition, i.e.,
> >> PSC-1 -> PSC-n.
> >
> > 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.
> >
> >>
> > 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 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."
> >>
> >>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP]
> >>>>>> OSPF OTN considerations post IETF 82 (Issue
> >>>> 1/2)
> >>>>>>
> >>>>>> Switching Capability Types. So we have a few
> >>>>>> definitions: 3471 says "the
> >> type
> >>>> of
> >>>>>> just references 4202), but does equate it with a
> >>>>>> "layer". While it allows for hierarchy within a "layer"
> >>>>>> it also says hierarchy
> >> occurs
> >>>>>> model OTN as
> >>>>>> that a per-OTUk Switching Capability Types will be used
> >>>>>> to support G.709v3. (2) that
> >>>>>> Switching Cap field value for each ODUk, and that it
> >>>>>> state that the value corresponding to the signal type
> >>>>>> any other changes to the current definition of ISCD.)
> >>>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be
> >>>>>> updated to match above.
> >>>>>>
> >>>>>>> meaning of the Switching Capability field. (even if
> >>>>>>> the definition of PSC1-2-3-4 already overloads the
> >>>>>>> meaning of the switching capability field)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> lead to interworking issues and the counter proposal
> >>>>>>> was to have both
> >>>> pieces
> >>>>>> of
> >>>>>>> Via L.Calda, 5 Genova, Italy Phone +390106002512
> >>>>>>> Mobile +393346725750 [email-masked]
> >>>>>>> www.ericsson.com
> >>>>>>>
> >>>>>>>
> >>>>>>>

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 07:14:01 -0800

Julien,

I don't know how many times we want to go over this.

As you might expect, Switching Capability enables path computation to be aware of regions in which there are different switching capabilities.  It was never intended to delineate sub-regions (layers) within those regions.  In particular, nowhere in the entire body of the Multi-Layer/Multi-Region work is this capability mentioned.

Further, it is not used in this manner in SDH/SONET which, along with OTN, is the best example of a multi-layer network with which we have to deal and the last time we had this discussion, prior to Maastricht, it was stated that the ITU has deprecated the use of the concept of multi-layer in its modeling of OTN networks.

Could we please agree that PSC 1-4 was an aberration that can be attributed to inexperience and just erase it from our collective memory?

Thanks,

John

> Of Julien Meuric
> Sent: Tuesday, December 20, 2011 6:54 AM
> To: Zhangfatai
> Cc: CCAMP
> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
>
> Hi Fatai.
>

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 07:53:14 -0800

Julien,

I would also like to observe that what we are doing in OTN is exactly the same as we did in SDH/SONET, viz, advertising the types of client LSPs a given interface supports.

Thanks,

John

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 20 Dec 2011 16:58:41 +0100

John,

Just to emphasize what you've already well mentioned about multi-layer in OTN.

This is what reports the Recommendation representing Optical Transport Network architecture , G.872.

.....

"Since the resources that support these topological components support a heterogeneous assembly of ODUs, the ODU layer is modelled as a single layer network that is independent of bit-rate.  The ODU bit-rate is a parameter that allows the number of Tributary Slots (TS) for the ODU link connection to be determined."

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

> - we are dealing with the ODUk layers within the OTN

> technology/regions;

> - using the term "extension" to refer to encoding the hierarchy level

> Then you propose to use the "[OTN] Signal Type": as opposed to a)

> above,

> The I-D uses a single SC (OTN-TDM) for the whole OTN, which means the

> SC

> hierarchy information at a higher level in the IGP, like it was done

> >  I agree the requirement that you mentioned, but it can be resovled

> >  without extending Switching Cap.

> =======================================================================

> ========

> =======================================================================

> ==============

> >  mechnism or definition without extending Switching Cap, I don't

> think

> >  [[email-masked]] 发送时间: 2011年12月7日 0:08 到: Zhangfatai

> Cc:

> >  CCAMP; [email-masked] 主题: Re: [CCAMP] R: OSPF OTN considerations

> post

> >  straightforward and enables a fine-grained resource description,

> e.g.

> >  adaptation requested by a higher layer, or to get a clear feedback

> >  value would take some capabilities away? What would you suggest so

> > >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82

> > >>>> (Issue

> > >>>>>>> WRT issue 1: the proposal was to indicate the bottom

> > >>>>>>> most ODUk of

> > >>>>>>> muxing hiearachy in the Switching Capability field of

> > >>>>>>> the ISCD.

> > >>>>>>> a quick talk with the other authors of the ID, the

> > >>>>>>> idea was to

> > >>>>>>> the proposal as it would lead to an overloading of the

> > >>>>>>> meaning of

> > >>>>>> switching that should be performed", 4202 says

> > >>>>>> "describes

> > >>>>>> capability of an interface." 3945 doesn't really define

> > >>>>>> the term

> > >>>>>> So I interpret Switching Capability Types to represent

> > >>>>>> (a)

> > >>>>>> switching/technology layers and (b) different levels of

> > >>>>>> the original GMPLS supported technologies (i.e., PSC,

> > >>>>>> L2SC, TDM

> > >>>>>> To me, the first question to ask relates to (a), and is

> > >>>>>> should

> > >>>>>> I know this has been a much debated point, and it seems

> > >>>>>> to me that

> > >>>>>> are, but more for the perspective of switching layers

> > >>>>>> than

> > >>>>>> layers (i.e., they are clearly the same technology but

> > >>>>>> are

> > >>>>>> I think the second question to ask relates to (b), and

> > >>>>>> is does

> > >>>>>> I see this as simply yes, and no different than what has

> > >>>>>> been done

> > >>>>>> There's also a minor processing efficiency gained by

> > >>>>>> this approach

> > >>>>>> nodes that support a smaller set of ODUks than are

> > >>>>>> advertised

> > >>>>>> To keep thinks generic, we probably should use TDM-1

> > >>>>>> through TDM-n

> > >>>>>> the new Switching Capability Types, but this is a

> > >>>>>> secondary

> > >>>>>> impact encoding and won't take much text to make the

> > >>>>>> actual

> > >>>>>> this is a discussion that can continue until Paris if we

> > >>>>>> really

> > >>>>>>> During the OTN OSPF draft presentation at the IETF

> > >>>>>>> meeting in

> > >>>>>>> comments were raised with respect to the following

> > >>>>>>> issues:

> > >>>>>>> - Issue 1: Using different switching caps for each ODU

> > >>>>>>> - Issue 2: Type 2 (unres bandwidth for variable

> > >>>>>>> containers) and

> > >>>>>>> (MAX LSP bandwidth foe variable containers always used

> > >>>>>>> in tandem?

> > >>>>>>> WRT issue 1: the proposal was to indicate the bottom

> > >>>>>>> most ODUk of

> > >>>>>>> muxing hiearachy in the Switching Capability field of

> > >>>>>>> the ISCD.

> > >>>>>>> quick talk with the other authors of the ID, the idea

> > >>>>>>> was to

> > >>>>>>> WRT issue 2: it is analyzed in section 5.3 of the

> > >>>>>>> draft (version

> > >>>>>>> shown. In case of ODUflex advertisement the MAX LSP

> > >>>>>>> bandwidth

> > >>>>>>> to be advertised but in some cases also information

> > >>>>>>> about the

> > >>>>>>> bandwidth does not give a clear indication of how many

> > >>>>>>> can be set up either at the MAX LSP Bandwidth or at

> > >>>>>>> as it gives no information about the spatial

> > >>>>>>> allocation of the

> > >>>>>>> An indication of the amount of Unreserved bandwidth

> > >>>>>>> could be

> > >>>>>>> during the path computation process, as shown in the

> > >>>>>>> following

> > >>>>>>> example. Supposing there are two TE-links (A and B)

> > >>>>>>> with MAX

> > >>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of

> > >>>>>>> Bandwidth are available on Link A, 10Gbps on Link B

> > >>>>>>> and 3

> > >>>>>>> LSPs of 10 GBps each, have to be restored, for sure

> > >>>>>>> only one

> > >>>>>>> restored along Link B and it is probable (but not

> > >>>>>>> sure) that

> > >>>>>>> mandatory piece of information and the Unreserved

> > >>>>>>> bandiwdth TLV

> > >>>>>>> information as mandatory and, as a consequence, merge

> > >>>>>>> the two

> > >>>>>>> We'd like to hear the opinion of the WG on both issues

> > >>>>>>> before

> > >>>>>>> This Communication is Confidential. We only send and

> > >>>>>>> receive

CCAMP mailing list

[email-masked]

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:01:46 -0800

Sergio,

Excellent.  Jonathan, check this out.

Thanks,

John

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Tuesday, December 20, 2011 7:59 AM
To: John E Drake
Cc: CCAMP; Zhangfatai; Julien Meuric
Subject: R: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

John,

.....

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

CCAMP mailing list

[email-masked]

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Tue, 20 Dec 2011 10:12:48 -0600

John,

While each ODU layer is a single layer network, how the ODUs interact with each other (e.g. placing an ODU0 into an ODU1) generates a multi-layer network.

This detail is especially important when dealing with multi-stage multiplexing (eg ODU0 over ODU1 over ODU2) AND dealing with different adaptation styles (e.g. 2.5G TS vs 1.2G TS)

CCAMP did get a liaison from ITU-T last year pointing these details out (LS221).

Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Tuesday, December 20, 2011 10:02 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Sergio,

Thanks,

John

John,

.....

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

CCAMP mailing list

[email-masked]

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Dec 2011 16:13:03 +0000

John,

> As you might expect, Switching Capability enables path computation to be aware of > regions in which there are different switching capabilities.  
>It was never  intended to delineate sub-regions (layers) within those regions.  In > particular, nowhere in the entire body of the Multi-Layer/Multi-Region work is 
> this capability mentioned.

You may recall that originally the work was named simply Multi-Region. It was me who suggested adding Multi-Layer part because of the very reason that multiple layers may happen within the same technology. There are certain differences between the cases when two adjacent layers belong to the same or different technologies. For example, you will signal connections using different set of signaling objects in the latter case. However, from the TE routing/PCE perspective IMO it is quite advantageous to keep these differences to the minimum, and treat separate layers as separate layers irrespectively whether they belong to the same or different regions. ODUk is a shining example IMO of the case where multiple layers co-exist within the same region. From the server-client relationship point of view two layers are separate when a connection in one layer could be used as a link in the other.

Cheers,
Igor

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:26:36 -0800

Jonathan,

I think what you stated, below, is inconsistent with what Sergio quoted;  the quote states that the set of interfaces in a given IGP instance, regardless of the rate individual interfaces, is modeled as a single layer network.

As this point I am a bystander – please ask Sergio for any G.872 related information.

Thanks,

John

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Tuesday, December 20, 2011 8:13 AM
To: John E Drake; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

John,

Jonathan Sadler

Sergio,

Thanks,

John

John,

.....

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

CCAMP mailing list

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 11:27:52 -0500

Jonathan,
	This point is precisely (one of) the key reasons I put forward the
proposal on multiple SC types.

Lou

On 12/20/2011 11:12 AM, Sadler, Jonathan B. wrote:
> John,
> 
>  
> 
> While each ODU layer is a single layer network, how the ODUs interact
> with each other (e.g. placing an ODU0 into an ODU1) generates a
> multi-layer network.
> 
>  
> 
> This detail is especially important when dealing with multi-stage
> multiplexing (eg ODU0 over ODU1 over ODU2) AND dealing with different
> adaptation styles (e.g. 2.5G TS vs 1.2G TS)
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *John E Drake
> *Sent:* Tuesday, December 20, 2011 10:02 AM
> *To:* BELOTTI, SERGIO (SERGIO)
> *Cc:* CCAMP
> *Subject:* Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
>  
> 
> Sergio,
> 
>  
> 
> *From:* BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
> *Sent:* Tuesday, December 20, 2011 7:59 AM
> *To:* John E Drake
> *Cc:* CCAMP; Zhangfatai; Julien Meuric
> *Subject:* R: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
>  
> 
> John,
> 
> "Since the resources that support these topological components support a
> heterogeneous assembly of ODUs, the ODU layer is modelled as a single
> layer network that is independent of bit-rate.  The ODU bit-rate is a
> parameter that allows the number of Tributary Slots (TS) for the ODU
> link connection to be determined."
> 
>  
> 
>  
> 
>  
> 
> Thanks
> 
>  
> 
> Sergio
> 
>  
> 
>  
> 
>  
> 
>  
> 
> As you might expect, Switching Capability enables path computation to be
> aware of regions in which there are different switching capabilities. 
> It was never intended to delineate sub-regions (layers) within those
> regions.  In particular, nowhere in the entire body of the
> Multi-Layer/Multi-Region work is this capability mentioned.
> 
>  
> 
> Further, it is not used in this manner in SDH/SONET which, along with
> OTN, is the best example of a multi-layer network with which we have to
> deal and the last time we had this discussion, prior to Maastricht, it
> was stated that the ITU has deprecated the use of the concept of
> multi-layer in its modeling of OTN networks.
> 
>  
> 
> Could we please agree that PSC 1-4 was an aberration that can be
> attributed to inexperience and just erase it from our collective memory?
> 
>  
> 
> Thanks,
> 
>  
> 
> John
> 
>  
>

---

From: Julien Meuric <[email-masked]>
Date: Tue, 20 Dec 2011 17:30:51 +0100

Hi John.

I hear your argument and agree that it is not inconsistent with 
SONET/SDH. My point is that deployments of GMPLS-controlled SONET/SDH 
cover a single granularity of containers (and relevant concatenations), 
thus GMPLS-controlled SONET/SDH is not enough as a starting point to be 
mechanically generalized into OTN (otherwise we would not be arguing).

Regards,

Julien

Le 20/12/2011 16:53, John E Drake a écrit :
>> b)"Switching Cap&  Signal Type (&  Encoding Type as well)".
>>
>> we can use Switching Cap&  Signal Type (&  Encoding Type as well) to
>>>>>>>>>> *DANIELE CECCARELLI * *System&  Technology - DU IP&
>>>>>>>>>> Broadband*
>>>>>>>>>>
>>>>>>>>>>

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:28:59 -0800

Igor,

I think it is fair to say that you share the perspective of Lou and Julien.

Thanks,

John

> From: Igor Bryskin [mailto:[email-masked]]
> To: John E Drake; Julien Meuric; Zhangfatai
> Cc: CCAMP
> > As you might expect, Switching Capability enables path computation to
> be aware of > regions in which there are different switching
> capabilities.
> regions.  In > particular, nowhere in the entire body of the Multi-
> Layer/Multi-Region work is
> You may recall that originally the work was named simply Multi-Region.
> It was me who suggested adding Multi-Layer part because of the very
> reason that multiple layers may happen within the same technology.
> There are certain differences between the cases when two adjacent
> layers belong to the same or different technologies. For example, you
> will signal connections using different set of signaling objects in the
> latter case. However, from the TE routing/PCE perspective IMO it is
> quite advantageous to keep these differences to the minimum, and treat
> separate layers as separate layers irrespectively whether they belong
> to the same or different regions. ODUk is a shining example IMO of the
> case where multiple layers co-exist within the same region. From the
> server-client relationship point of view two layers are separate when a
> connection in one layer could be used as a link in the other.
>
> Cheers,
> Igor
>
> was stated that the ITU has deprecated the use of the concept of multi-
> layer in its modeling of OTN networks.
>
> cases

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:41:20 -0800

We currently have two granularities with the aim of getting to one, but how does that have the slightest bearing on advertising an individual interface's bit rate?

> From: Julien Meuric [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2011 8:31 AM
> To: John E Drake
> Cc: Zhangfatai; CCAMP
> > I would also like to observe that what we are doing in OTN is exactly
> the same as we did in SDH/SONET, viz, advertising the types of client
> LSPs a given interface supports.
> >
> > Thanks,
> >
> > John
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:46:49 -0800

The snippet from Jonathan's email "how the ODUs interact with each other (e.g. placing an ODU0 into an ODU1)" is a useful short description of the problem we are solving.

I.e., the types of ODUj a given ODUk interface supports.  This is much more relevant in path computation than that interface's bandwidth, especially given that multiple bandwidths of ODUk support a given ODUj, and we advertise an interface's bandwidth separately.

> Sent: Tuesday, December 20, 2011 8:28 AM
> To: Sadler, Jonathan B.
> Cc: John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP
> > CCAMP did get a liaison from ITU-T last year pointing these details
> out
> > (LS221).
> >
> >
> >
> > Jonathan Sadler
> >
> >
> >
> > Just to emphasize what you've already well mentioned about multi-
> layer
> > in OTN.
> >
> >
> >
> > This is what reports the Recommendation representing Optical
> Transport
> > Network architecture , G.872.
> >
> > .....
> >
> > Da: [email-masked] [mailto:[email-masked]] Per conto
> di
> > John E Drake
> without

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 08:50:16 -0800

Hi,

I have several observations:

1)  We are just repeating ourselves

2)  I think both Lou and Julien are close to abusing their positions as WG chairs

3)  There seems to be a preponderance of opinion to go with the current design

Therefore, I would like to call the question and have Deborah decide what our design direction is to be.

Thanks,

John

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 20 Dec 2011 18:11:38 +0100

John,

my interpretation of Jonathan’s sentence is not in contradiction with G.872 statement: the relation among containers with different rates is an heterogeneous variety of possibilities that means we cannot state which is the server layer of a e.g. ODU2 since in an OTN network ODU2 can traverse link at different ODUkOTUk rates .(ODU3 , ODU4 or OTU2). This is capture in G.872 in the sentence related to “heterogeneous assembly of ODUs” for which the only way to manage an OTN network is consider ODU  as a single layer .

Thanks

Sergio

________________________________
Da: John E Drake [mailto:[email-masked]]
Inviato: martedì 20 dicembre 2011 17.27
A: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Oggetto: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Jonathan,

Thanks,

John

John,

Jonathan Sadler

Sergio,

Thanks,

John

John,

.....

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

CCAMP mailing list

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 12:11:36 -0500

> 2)  I think both Lou and Julien are close to abusing their positions
as WG chairs

John,
	So this is an interesting statement.  It implies a WG chair is not
allowed to take an technical positions within a WG that they chair.
This is, of course, pure nonsense.

If you really believe that I (or the PCE WG chair for that matter) have
acted in a manner inconsistent with RFC 2026 or RFC 2418, I strongly
encourage you to follow standard IETF process in this regard.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 09:30:54 -0800

Sergio,

I completely agree with your email, below.  What I thought was inconsistent in Jonathan’s email was the phrase “While each ODU layer is a single layer network”.  But since you are the expert I will defer to your interpretation.

Thanks,

John

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Tuesday, December 20, 2011 9:12 AM
To: John E Drake; Sadler, Jonathan B.
Cc: CCAMP
Subject: R: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

John,

Thanks

Sergio

Jonathan,

Thanks,

John

John,

Jonathan Sadler

Sergio,

Thanks,

John

John,

.....

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 20 dicembre 2011 16.14
A: Julien Meuric; Zhangfatai
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

Julien,

Thanks,

John

CCAMP mailing list

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 12:44:59 -0500

My proposal in Taipei was motivated by intra-technology hierarchy
representation in a generic method, ala PSC-2->N.  The fact that in OTN
level of hierarchy also implies a bandwidth is really
orthogonal&incidental from this perspective.

You have made your position clear, i.e., that you think that the
original definition of PSC-2->N (and use of SC as a generic
intra-technology hierarchy indicator) is flawed.  Others have made the
point that it is not. As I've stated on the list, I personally think
it's an interesting proposal that should be considered.

So how do we close on this discussion?

In an earlier message I asked if you were interested in putting a draft
together to document your proposed change to the base GMPLS specs.
Since you haven't expressed any interest in this, I'll bite and commit
to putting forward a draft (in January) that captures both/all sides of
the base GMPLS implications of this debate.  Hopefully this will help
move the non-technology specific GMPLS portions of this debate to
closure; any needed OTN changes/implications can then follow.

Anyone interested in contributing, in a constructive manner, to this
individual draft is welcome.  Just send me mail.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 10:43:22 -0800

If you are saying that we are free to ignore you, them I am fine and I think we are done with the OTN discussion.

> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP; ccamp-
> [email-masked]
> >>> OTN, is the best example of a multi-layer network with which we
> have
> >> to
> >>>> draft-ietf-ccamp-gmpls-ospf-g709v3-00. As emphasized by Kireeti,
> the
> >> SC
> >>>
> >>>> sub-TLVs. Hence I prefer the "old-fashion" approach which
> represent
> >> the
> >>>

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 11:02:03 -0800

> Sent: Tuesday, December 20, 2011 9:45 AM
> To: John E Drake
> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
> representation in a generic method, ala PSC-2->N.

[JD] There is no requirement to do this and in general it is of no use in path computation.  More specifically, for both SDH/SONET and OTN, it is of absolutely no use in path computation.

>  The fact that in OTN
[
[JD]  There are no changes to the base GMPLS specs.  We are not changing the base definition of PSC 1-4 and what we are defining is completely consistent with SDH/SONET.

> closure; any needed OTN changes/implications can then follow.

By your definition, above, this draft is going to contain no new information, so what is the purpose of the exercise?

> > The snippet from Jonathan's email "how the ODUs interact with each
> other (e.g. placing an ODU0 into an ODU1)" is a useful short
> description of the problem we are solving.
> >
> > I.e., the types of ODUj a given ODUk interface supports.  This is
> much more relevant in path computation than that interface's bandwidth,
> especially given that multiple bandwidths of ODUk support a given ODUj,
> and we advertise an interface's bandwidth separately.
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 15:04:47 -0500

John,
	Thanks for the humor.  I'm sure it's nice to vent.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 15:22:27 -0500

> [JD]  There are no changes to the base GMPLS specs.  We are not changing the base definition of PSC 1-4 and what we are defining is completely consistent with SDH/SONET.

John,
	In an earlier message you said:

On 11/30/2011 5:23 PM, John E Drake wrote:
> Yes, I think that's fair.
>
>> > Sent: Wednesday, November 30, 2011 1:51 PM
>> > To: John E Drake
>> > 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?
>> >

Deprecating PSC1-4 and making SC Type just an indicator of label and
ISCD format will be covered in the draft. The draft wouldn't say
anything specifically about OTN.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 13:37:46 -0800

Lou,

I don't see any inconsistency between the two statements.  Nobody uses PSC 1-4 so we don't have to touch it and the SDH/SONET model, which we are re-using, is already consistent with base GMPLS - what is advertised for an interface is a single switching type, the types of client signals it supports, and its available bandwidth. 

How does the existence of this draft, which will have no new information, help the chairs gauge rough consensus on this issue in the WG, especially since rough consensus seems to already exist?  (I.e., the editors, authors, and contributors of the OTN routing draft would seem to represent a substantial portion of the WG.) 

Thanks,

John 

> Sent: Tuesday, December 20, 2011 12:22 PM
> To: John E Drake
> > [JD]  There are no changes to the base GMPLS specs.  We are not
> changing the base definition of PSC 1-4 and what we are defining is
> completely consistent with SDH/SONET.
> >
> 
> John,

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Dec 2011 18:23:48 -0500

John,
	As you probably know, each time we have new technology or a
change/evolution in a technology the folks involved in the technology
come up with a fairly technology-specific solution to their problem.
Part of the WG process has always been looking at the technology
specific extensions and figuring out what, if any, impact the
technlogy-specific extensions should have on the common portion of
GMPLS.  Prior to OTNv3, this can most recently be seen in both the
ethernet and WSON WG work.  In these cases, WG participants triggered
generalization of the proposed mechanisms.  This was even the case for
Ethernet, where I was on the other side as an author and the WG prompted
taking one document and making it 3.  IMO, as both a WG participant and
co-chair (yes, this time I'm making a statement as a Chair!), this
process is consistent, and required, by both the CCAMP's charter and WG
procedural precedent.   It is also exactly what we, the co-chairs, said
in our OTN discussion at IETF-78. (We mentioned defining new common
mechanisms as part of the solution refinement stage.)

In this case the OTN documents are not proposing a new mechanism, but
rather using a technology-specific approach.  Furthermore, in our
discussions you proposed modifying/deprecating documented usage /
meaning of SC Type.  I still see this as fitting within 'defining new
common mechanisms as part of the solution refinement stage.'

As you also may recall, the usage of SC type has come up multiple times
since it was introduced (perhaps by Yakov?).  I think (again as
participant and chair) it would be good to close this issue once and for
all.

See below for specific responses (as a WG participant).

On 12/20/2011 4:37 PM, John E Drake wrote:
> Lou,
> 
> I don't see any inconsistency between the two statements.  Nobody
> uses PSC 1-4 so we don't have to touch it and the SDH/SONET model,
> which we are re-using, is already consistent with base GMPLS - what
> is advertised for an interface is a single switching type, the types
> of client signals it supports, and its available bandwidth.
> 
> How does the existence of this draft, which will have no new
> information, help the chairs gauge rough consensus on this issue in
> the WG, 

It depends on which issue you are talking about.  If talking about the
general issue as discussed above, I hope it will close it for the future.

If talking about my (individual, not chair) proposal of using multiple
SC types for OTNv3, I don't think it immediately does.  What it will do
is provide context for that proposal.  In the interim, I recommend (as a
WG participant, not chair) tabling discussion on my proposal until we
know which way the general issue is resolved.

> especially since rough consensus seems to already exist?
> (I.e., the editors, authors, and contributors of the OTN routing
> draft would seem to represent a substantial portion of the WG.)

Well if the WG used this as the sole measure, consensus could have been
declared in Maastrict.

Lou

PS I've noted where I'm speaking as an individual WG participant and
where I'm expressing opinions as a Co-chair as this message contains both.

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Dec 2011 16:17:12 -0800

> Sent: Tuesday, December 20, 2011 3:24 PM
> To: John E Drake

[JD]  As you probably know, I have been one of the most vocal proponents of generality/commonality/reuse since the beginning of GMPLS back in 1999 (or so). 

> rather using a technology-specific approach.

[JD]  I really disagree with this characterization.  The correct statement would be that the decision to overload Switching Capability to delineate presumed intra-region (layer) boundaries is made on a switching technology basis.  It was done for packet switching, PSC 1-4, but was not done for SDH/SONET and is currently not done for OTN.

> Furthermore, in our

[JD]  Absent PSC 1-4, the usage of Switching Capability has always been as I described.  Interestingly enough, PSC 1-4 makes a lot more sense than your proposal.  For PSC 1-4 at least the intra-region layer boundaries are under administrative control, while you are proposing to directly equate them with the underlying ODUk rates.  As an aside, why is this not a "technology-specific approach"?

And you have yet to articulate any reason why this is necessary.  I think the quote from Sergio this morning was a compelling and succinct rebuttal of its necessity. 

> know which way the general issue is resolved.

[JD]  The only issue is your specific proposal.  

> Well if the WG used this as the sole measure, consensus could have been

[JD]  The proposal developed in Maastricht was far more general than anything in base GMPLS.  The judgment articulated by the chairs in Beijing was that it was just too different from base GMPLs and that unfortunately it hadn't been thought of ten years earlier. 

> where I'm expressing opinions as a Co-chair as this message contains

[JD]  Are you referring to this specific email or in general?

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Dec 2011 08:10:25 -0500

John,
	I'm a little at a loss as to what you are looking for / arguing about
at the moment.  I've already said that (a) that I think we should
"table[ing] discussion on my [OTN] proposal" and (b) I (with others)
will submit an individual draft on the general issue.

You've stated that (b) serves no purpose nor contains any technical
content.  Given that the draft doesn't exist at the moment, I guess your
statement is technically correct at this time. Once the draft is
submitted, I'll be happy to resume this argument based on the actual
content of the draft.

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Dec 2011 06:02:12 -0800

Lou,

From my perspective the generalization/normalization part of the process started in Beijing and finished in Quebec, when the OTN draft was adopted as a WG draft; the OTN draft is completely consistent with the SDH/SONET GMPLS model.

You have yet to provide a technical justification for your subsequent proposal to overload the meaning of Switching Capability to delimit intra-region layer boundaries that are congruent with ODUk bandwidths and its discussion has consumed an inordinate number of cycles.

The quote that Sergio provided yesterday from G.872 provides a very succinct explanation for why your proposal is a Bad Idea(tm):  "Since the resources that support these topological components support a heterogeneous assembly of ODUs, the ODU layer is modelled as a single layer network that is independent of bit-rate.  The ODU bit-rate is a parameter that allows the number of Tributary Slots (TS) for the ODU link connection to be determined."

The editors, authors, and contributors of the have pretty firmly rejected your proposal, so my basic question is what is the *process* for closure?  Waiting for a draft to be written that contains a rehash of the points that have already been discussed does not strike me as a *process*.

Thanks,

John

> Sent: Wednesday, December 21, 2011 5:10 AM
> To: John E Drake
> >> > is provide context for that proposal.  In the interim, I recommend
> (as
> >> > a

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Dec 2011 06:04:55 -0800

Lou and Julien,

Upon reflection I think point 2) in my email, below, is unduly harsh and I would like to apologize to you for making it.

Thanks,

John

> From: John E Drake
> Sent: Tuesday, December 20, 2011 8:50 AM
> To: 'Lou Berger'; Sadler, Jonathan B.
> Cc: BELOTTI, SERGIO (SERGIO); CCAMP
> > >> >  switching layers either of the same ISC (e.g., TDM) or
> different
> > ISC
> > >
> > >> >  two different switching types (e.g., PSC and TDM), either
> hosted
> > on
> > >
> > >> > > had in the past.". I.e., we should all understand that PSC-1 -
> >
> > >
> > >> > > the authors saw no requirement to overload switching
> capability
> > in
> > >

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 21 Dec 2011 10:49:34 -0600

Hi John and Lou,

I also have been participating in the GMPLS discussions from early on (2002).

One item that always struck me funny the way GMPLS describes (ITU-T) layers by a tuple of information (e.g. <SwichCap, EncodType> or <SwitchCap, EncodType, SigType> for SDH/OTN) where the component information seems to be empirically defined.  More specifically:
 - Switching Capability defines some things based on large sweeping definitions but others more narrowly.  For example:
      TDM (which encompasses SONET/SDH and ODU)
   compared with:
      PSCx (which looks to be used only for MPLS)
      L2SC (which originally meant a combination of Frame Relay, Ethernet)
 - Encoding type defines sub-categories of Switching Capability, but doesn't scope under Switching Capability.  For example:
      ANSI/ETSI PDH - when would this be used for a SC other than TDM?
      SONET/SDH - ditto
      ODU - ditto (prior to use of the new 101 SC)
   compared with:
      Packet (This is not really descriptive)
      Ethernet (more descriptive - looks to be a sub-category of L2SC.  Of course, this has been deprecated.)

Signal Type is definitely a sub-space of <TDM, OTN> and <TDM, SDH>.

Regarding the issue at hand: what is probably more important is how well these namespaces are used.  Since each component is a 8-bit value (today), exhaust is a real problem - especially since there is no hierarchy/sub-spacing for SwitchCap and EncodType.

It is because of namespace usage, I am not in favor of assigning a Switching capability per ODU type (i.e. ODU0, ODU1, ODU2, ODU3, ODU4).

Jonathan Sadler

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Dec 2011 09:40:19 -0800

Jonathan,

The definitions in Switching Capability and Encoding Type were attempts to be forward looking; AKA "everything but the kitchen sink" 8->.   

I think you raise a very good point regarding namespace exhaustion.

Thanks,

John

> Sent: Wednesday, December 21, 2011 8:50 AM
> One item that always struck me funny the way GMPLS describes (ITU-T)
> layers by a tuple of information (e.g. <SwichCap, EncodType> or
> <SwitchCap, EncodType, SigType> for SDH/OTN) where the component
> information seems to be empirically defined.  More specifically:
>  - Switching Capability defines some things based on large sweeping
> definitions but others more narrowly.  For example:
>  - Encoding type defines sub-categories of Switching Capability, but
> doesn't scope under Switching Capability.  For example:
> Regarding the issue at hand: what is probably more important is how
> well these namespaces are used.  Since each component is a 8-bit value
> (today), exhaust is a real problem - especially since there is no
> hierarchy/sub-spacing for SwitchCap and EncodType.
> 
> 
> It is because of namespace usage, I am not in favor of assigning a
> Switching capability per ODU type (i.e. ODU0, ODU1, ODU2, ODU3, ODU4).
> 
> Jonathan Sadler
> 
> 
> [JD]  As you probably know, I have been one of the most vocal
> proponents of generality/commonality/reuse since the beginning of GMPLS
> back in 1999 (or so).
> 
> >
> [JD]  I really disagree with this characterization.  The correct
> statement would be that the decision to overload Switching Capability
> to delineate presumed intra-region (layer) boundaries is made on a
> switching technology basis.  It was done for packet switching, PSC 1-4,
> but was not done for SDH/SONET and is currently not done for OTN.
> 
> > Furthermore, in our
> [JD]  Absent PSC 1-4, the usage of Switching Capability has always been
> as I described.  Interestingly enough, PSC 1-4 makes a lot more sense
> than your proposal.  For PSC 1-4 at least the intra-region layer
> boundaries are under administrative control, while you are proposing to
> directly equate them with the underlying ODUk rates.  As an aside, why
> is this not a "technology-specific approach"?
> 
> And you have yet to articulate any reason why this is necessary.  I
> think the quote from Sergio this morning was a compelling and succinct
> rebuttal of its necessity.
> 
> >
> [JD]  The proposal developed in Maastricht was far more general than
> anything in base GMPLS.  The judgment articulated by the chairs in
> Beijing was that it was just too different from base GMPLs and that
> unfortunately it hadn't been thought of ten years earlier.
> 
> >
> > Lou
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 22 Dec 2011 11:04:51 +0100

All,

Just to add a consideration that has not been taken into account up to now.

We said that for congurence with RFC4203 we should reuse the different layers in the SC field as per PSC [1~4], but at the same time RFC4328 defines a single ODU value, and a that time three different "layers" already existed: ODU1, ODU2, ODU3...so in order to be consistence with RFC4328 we should not use different layers in the SC field.

We already passed the brach, let's make a decision, one or the other, but we can no longer look back.

I agree with what Jonathan and John said before and support the single SC option.

I also take the opportunity of this mail to wish all of you a very Merry Christmas.

Daniele

>Sent: mercoledì 21 dicembre 2011 18.40
>To: Sadler, Jonathan B.; Lou Berger
>Cc: CCAMP
>The definitions in Switching Capability and Encoding Type were 
>attempts to be forward looking; AKA "everything but the 
>kitchen sink" 8->.   
>
>> I also have been participating in the GMPLS discussions from 
>early on 
>> (2002).
>> 
>>       Ethernet (more descriptive - looks to be a 
>sub-category of L2SC.
>> Of course, this has been deprecated.)
>> 
>> > change/evolution in a technology the folks involved in the 
>> > technology come up with a fairly technology-specific 
>solution to their problem.
>> > ethernet and WSON WG work.  In these cases, WG participants 
>> > triggered generalization of the proposed mechanisms.  This 
>was even 
>> > the case
>> for
>> > Ethernet, where I was on the other side as an author and the WG 
>> > prompted taking one document and making it 3.  IMO, as both a WG 
>> > participant
>> and
>> > process is consistent, and required, by both the CCAMP's 
>charter and
>> WG
>> proponents of generality/commonality/reuse since the beginning of 
>> GMPLS back in 1999 (or so).
>> 
>> >
>> > In this case the OTN documents are not proposing a new mechanism, 
>> > but rather using a technology-specific approach.
>> 
>> switching technology basis.  It was done for packet switching, PSC 
>> 1-4, but was not done for SDH/SONET and is currently not 
>done for OTN.
>> 
>> > Furthermore, in our
>> > meaning of SC Type.  I still see this as fitting within 'defining 
>> > new common mechanisms as part of the solution refinement stage.'
>> 
>> [JD]  Absent PSC 1-4, the usage of Switching Capability has always 
>> been as I described.  Interestingly enough, PSC 1-4 makes a lot more 
>> sense than your proposal.  For PSC 1-4 at least the 
>intra-region layer 
>> boundaries are under administrative control, while you are proposing 
>> to directly equate them with the underlying ODUk rates.  As 
>an aside, 
>> why is this not a "technology-specific approach"?
>> 
>> > > information, help the chairs gauge rough consensus on this issue 
>> > > in the WG,
>> >
>> > SC types for OTNv3, I don't think it immediately does.  
>What it will
>> do
>> > WG participant, not chair) tabling discussion on my proposal until 
>> > we know which way the general issue is resolved.
>> 
>> > where I'm expressing opinions as a Co-chair as this 
>message contains 
>> > both.
>> 
>> The information contained in this message may be privileged and 
>> confidential and protected from disclosure. If the reader of this 
>> message is not the intended recipient, or an employee or agent 
>> responsible for delivering this message to the intended 
>recipient, you 
>> are hereby notified that any reproduction, dissemination or 
>> distribution of this communication is strictly prohibited. 
>If you have 
>> received this communication in error, please notify us 
>immediately by 
>> replying to the message and deleting it from your computer. 
>Thank you. 
>> Tellabs ============================================================

---

From: John E Drake <[email-masked]>
Date: Sat, 24 Dec 2011 06:47:16 -0800

An excellent point.

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Thursday, December 22, 2011 2:05 AM
> To: John E Drake; Sadler, Jonathan B.; Lou Berger
> Cc: CCAMP
> We said that for congurence with RFC4203 we should reuse the different
> layers in the SC field as per PSC [1~4], but at the same time RFC4328
> defines a single ODU value, and a that time three different "layers"
> already existed: ODU1, ODU2, ODU3...so in order to be consistence with
> RFC4328 we should not use different layers in the SC field.
>