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

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

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:[e-mail]]
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,

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:[e-mail]]
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,

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 ¨C please ask Sergio for any G.872 related information.

Thanks,

John

From: Sadler, Jonathan B. [mailto:[e-mail]]
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,

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: [e-mail] [mailto:[e-mail]] 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,

Excellent.  Jonathan, check this out.

Thanks,

John

From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
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,

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: [e-mail] [mailto:[e-mail]] 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,



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



> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]] On Behalf

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

>

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

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

> >  [[e-mail]] ·¢ËÍʱ¼ä: 2011Äê12ÔÂ7ÈÕ 0:08 µ½: Zhangfatai

> Cc:

> >  CCAMP; [e-mail] Ö÷Ìâ: 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

> >

> >

> >  Le 02/12/2011 09:51, Zhangfatai a ¨¦crit :

> > > Hi all,

> > >

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

> > >

> > >

> > >

> > >

> > >

> > > Thanks

> > >

> > > Fatai

> > >

> > >

> > > -----Original Message----- From: [e-mail]

> > > [mailto:[e-mail]] On Behalf Of BELOTTI, SERGIO

> > > (SERGIO)

> > >

> > > John, as co-authors, we shared completely your thoughts.

> > >

> > > Thanks Sergio and Pietro

> > >

> > > SERGIO BELOTTI

> > >

> > > ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio

> > > Evolution

> > >

> > > via Trento 30 , Vimercate(MI) Italy T: [phone]

> > > [e-mail]

> > >

> > >

> > >

> > > -----Messaggio originale----- Da: [e-mail]

> > > [mailto:[e-mail]] Per conto di John E Drake Inviato:

> > > mercoled¨¬ 30 novembre 2011 22.37 A: Lou Berger Cc: CCAMP Oggetto:

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

> > >

> > > Comments inline. I still think this is a terrible idea and I would

> > > like to see what the rest of the WG thinks.

> > >

> > >> -----Original Message----- From: Lou Berger

> > >> [mailto:[e-mail]] Sent: Wednesday, November 30, 2011

> > >> 1:09 PM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject:

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

> > >>

> > >>

> > >> John,

> > >>

> > >> see below

> > >>

> > >>

> > >> On 11/30/2011 2:59 PM, John E Drake wrote:

> > >>> Using Switching Capability to indicate link bandwidth seems

> > >>> ill-considered at best, especially since this information is

> > >>> carried in other fields, and as Daniele noted, it

> > >>> significantly overloads to intended meaning of Switching

> > >>> Capability.

> > >>

> > >> I agree with the point on BW, but my point was related to the

> > >> layer&hierarchy implications of the different ODUk values. I'd

> > >> think that using values that are TDM-1 -> TDM-n should make this

> > >> clear and remove any ambiguity related to bandwidth. It is also

> > >> completely consistent with the base GMPLS definition, i.e.,

> > >> PSC-1 -> PSC-n.

> > >

> > > [JD] You are simply asserting that this is a good idea and further

> > > asserting that there is "ambiguity related to bandwidth', without

> > > providing any evidence.

> > >

> > > To the best of my knowledge no one ever implemented or deployed

> > > the PSC-1 -> PSC-4 hierarchy, simply because no one could figure

> > > out what it meant. To quote from you, below, "Well hopefully we

> > > have a better understanding of the technologies involved than we

> > > had in the past.". I.e., we should all understand that PSC-1 ->

> > > PSC-4 was a bad idea (tm) and move on.

> > >

> > >>

> > >>> It also is inconsistent with the usage of Switching Capability

> > >>> in SDH/SONET.

> > >>

> > >> Well hopefully we have a better understanding of the

> > >> technologies involved than we had in the past.

> > >

> > > [JD] I think we had a very good understanding of SDH/SONET then

> > > and we have a very good understanding of OTN now, and in both cases

> > > the authors saw no requirement to overload switching capability in

> > > the manner you are suggesting.

> > >

> > >>

> > >>>

> > >>> A more extensive quote from RFC4202 is the following, which

> > >>> seems clear enough to me:

> > >>>

> > >>> "In the context of this document we say that a link is

> > >>> connected to a node by an interface. In the context of GMPLS

> > >>> interfaces may have different switching capabilities. For

> > >>> example an interface that connects a given link to a node may

> > >>> not be able to switch individual packets, but it may be able to

> > >>> switch channels within an SDH payload. Interfaces at each end

> > >>> of a link need not have the same switching capabilities.

> > >>> Interfaces on the same node need not have the same switching

> > >>> capabilities."

> > >>

> > >> Not sure how this helps clarify anything...

> > >

> > > [JD] I think it clarifies that switching capabilities is meant to

> > > describe how a given interface switches the information with which

> > > it is provided. This has nothing to do with the interface's

> > > bandwidth.

> > >

> > >>

> > >> Lou

> > >>>

> > >>>> -----Original Message----- From: Lou Berger

> > >>>> [mailto:[e-mail]] Sent: Wednesday, November 30, 2011

> > >>>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP

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

> > >>>> (Issue

> > >> 1/2)

> > >>>>

> > >>>> Great. Care to substantiate your point?

> > >>>>

> > >>>> On 11/30/2011 11:14 AM, John E Drake wrote:

> > >>>>> I completely disagree.

> > >>>>>

> > >>>>>> -----Original Message----- From: [e-mail]

> > >>>>>> [mailto:[e-mail]] On

> > >>>> Behalf

> > >>>>>> Of Lou Berger Sent: Wednesday, November 30, 2011 7:22 AM

> > >>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP]

> > >>>>>> OSPF OTN considerations post IETF 82 (Issue

> > >>>> 1/2)

> > >>>>>>

> > >>>>>> Hi Daniele, Since I raised the point, I guess I need to

> > >>>>>> champion it! (With chair hat off.)

> > >>>>>>

> > >>>>>> All,

> > >>>>>>

> > >>>>>> Daniele said:

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

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

> > >>>> the

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

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

> > >>>> After

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

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

> > >>>> reject

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

> > >>>>>>> meaning of

> > >>>> the

> > >>>>>>> Switching Capability field. (even if the definition of

> > >>>>>>> PSC1-2-3-4 already overloads the meaning of the

> > >>>>>>> switching capability field)

> > >>>>>>

> > >>>>>> This really goes to the interpretation of the intent of

> > >>>>>> Switching Capability Types. So we have a few

> > >>>>>> definitions: 3471 says "the

> > >> type

> > >>>> of

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

> > >>>>>> "describes

> > >> switching

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

> > >>>>>> the term

> > >> (it

> > >>>>>> just references 4202), but does equate it with a

> > >>>>>> "layer". While it allows for hierarchy within a "layer"

> > >>>>>> it also says hierarchy

> > >> occurs

> > >>>>>> "between interface types".

> > >>>>>>

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

> > >>>>>> (a)

> > >> different

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

> > >>>>>> hierarchy

> > >> --

> > >>>>>> even within a layer. I think (a) is identifiable in the

> > >> definition

> > >>>> of

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

> > >>>>>> L2SC, TDM

> > >> LSC,

> > >>>>>> and FSC), and (b) is identifiable in the original types

> > >>>>>> plus the

> > >>>> definition

> > >>>>>> of PSC-1 through PSC-4.

> > >>>>>>

> > >>>>>> So how does this apply to our current OTN work?

> > >>>>>>

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

> > >>>>>> should

> > >> each

> > >>>>>> ODUk be modeled as a separate layer?

> > >>>>>>

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

> > >>>>>> to me that

> > >>>> they

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

> > >>>>>> than

> > >>>> technology

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

> > >>>>>> are

> > >> different

> > >>>>>> granularity of swicthing.) So this is a yes for me.

> > >>>>>>

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

> > >>>>>> is does

> > >> each

> > >>>>>> ODUk represent a different level of hierarchy?

> > >>>>>>

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

> > >>>>>> been done

> > >>>> more

> > >>>>>> recently with Ethernet or, even if we do continue to

> > >>>>>> model OTN as

> > >> a

> > >>>>>> single layer, no different than PSC-1 -> PSC-4.

> > >>>>>>

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

> > >>>>>> this approach

> > >>>> for

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

> > >>>>>> advertised

> > >> within

> > >>>> an

> > >>>>>> IGP.

> > >>>>>>

> > >>>>>> Based on all this, I believe different ODUk's should use

> > >>>>>> different Switching Types. In particular, I'm proposing:

> > >>>>>> (1) that either the framework or info documents identify

> > >>>>>> that a per-OTUk Switching Capability Types will be used

> > >>>>>> to support G.709v3. (2) that

> > >>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3 define a different

> > >>>>>> Switching Cap field value for each ODUk, and that it

> > >>>>>> state that the value corresponding to the signal type

> > >>>>>> identified in the #stages=0 of the ISCP be set. (Without

> > >>>>>> any other changes to the current definition of ISCD.)

> > >>>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be

> > >>>>>> updated to match above.

> > >>>>>>

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

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

> > >>>> as

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

> > >>>>>> secondary

> > >>>> discussion.

> > >>>>>>

> > >>>>>> Comments?

> > >>>>>>

> > >>>>>> Lou

> > >>>>>>

> > >>>>>> PS While the above is an important change, it doesn't

> > >> significantly

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

> > >>>>>> actual

> > >> change,

> > >>>> so

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

> > >>>>>> really

> > >> need

> > >>>> a

> > >>>>>> face to face to resolve the discussion.

> > >>>>>>

> > >>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote:

> > >>>>>>> Hi CCAMP,

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

> > >>>>>>> meeting in

> > >>>> Taipei

> > >>>>>> two

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

> > >>>>>>> issues:

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

> > >>>>>>> type

> > >>>>>>>

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

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

> > >>>> Type

> > >>>>>> 3

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

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

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

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

> > >>>> the

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

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

> > >>>> After

> > >>>>>> a

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

> > >>>>>>> was to

> > >> reject

> > >>>>>> the

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

> > >>>>>>> meaning of the Switching Capability field. (even if

> > >>>>>>> the definition of PSC1-2-3-4 already overloads the

> > >>>>>>> meaning of the switching capability field)

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

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

> > >> -

> > >>>>>> 00).

> > >>>>>>> I'm copying it below for your convenience

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> In this example the advertisement of an ODUflex->ODU3

> > >> hierarchy

> > >>>> is

> > >>>>>>>

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

> > >>>>>>> bandwidth

> > >>>>>> needs

> > >>>>>>>

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

> > >>>>>>> about the

> > >>>>>>>

> > >>>>>>> Unreserved bandwidth could be useful. The amount of

> > >> Unreserved

> > >>>>>>>

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

> > >>>>>>> ODUflex

> > >>>> LSP

> > >>>>>>>

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

> > >>>>>>> different

> > >>>>>> rates,

> > >>>>>>>

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

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

> > >>>>>> free

> > >>>>>>>

> > >>>>>>> TSs.

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

> > >>>>>>> could be

> > >>>>>> useful

> > >>>>>>>

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

> > >>>>>>> following

> > >>>>>>>

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

> > >>>>>>> with MAX

> > >>>> LSP

> > >>>>>>>

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

> > >>>>>>> Unreserved

> > >>>>>>>

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

> > >>>>>>> and 3

> > >>>> ODUflex

> > >>>>>>>

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

> > >>>>>>> only one

> > >> can

> > >>>>>> be

> > >>>>>>>

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

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

> > >> two

> > >>>>>> of

> > >>>>>>>

> > >>>>>>> them can be restored along Link A.

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> Early proposal was to have, in the case of variable

> > >>>>>>> containers advertisements (i.e. ODUflex), the MAX LSP

> > >>>>>>> bandwidth TLV (Type 3)

> > >>>> as

> > >>>>>> a

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

> > >>>>>>> bandiwdth TLV

> > >>>> (Type

> > >>>>>> 2)

> > >>>>>>> as an optional piece of information.

> > >>>>>>>

> > >>>>>>> The comment received is that optional information can

> > >>>>>>> lead to interworking issues and the counter proposal

> > >>>>>>> was to have both

> > >>>> pieces

> > >>>>>> of

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

> > >>>>>>> the two

> > >> TLVs

> > >>>>>> into

> > >>>>>>> a single one.

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

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

> > >>>>>>> before

> > >>>>>> proceeding

> > >>>>>>> with any modification to the document.

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> Thanks,

> > >>>>>>>

> > >>>>>>> Daniele

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP &

> > >>>>>>> Broadband*

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> Via L.Calda, 5 Genova, Italy Phone [phone]

> > >>>>>>> Mobile [phone] [e-mail]

> > >>>>>>> www.ericsson.com

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>> <http://www.ericsson.com/>

> > >>>>>>>

> > >>>>>>>

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

> > >>>>>>> receive

> > >> email

> > >>>> on

> > >>>>>>> the basis of the term set out at

> > >> www.ericsson.com/email_disclaimer

> > >>>>>>> <http://www.ericsson.com/email_disclaimer>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >>>>>>>

> > >

> > > _______________________________________________ CCAMP mailing list

> > > [e-mail] https://www.ietf.org/mailman/listinfo/ccamp

> _______________________________________________

> CCAMP mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ccamp

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