Re: [CCAMP] RSVP OTN single stage vs multi stage

Fatai Zhang <zhangfatai@huawei.com> Wed, 13 July 2011 02:01 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2A39E801A for <ccamp@ietfa.amsl.com>; Tue, 12 Jul 2011 19:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6s6jcv7CpuZ for <ccamp@ietfa.amsl.com>; Tue, 12 Jul 2011 19:01:44 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D64B49E8004 for <ccamp@ietf.org>; Tue, 12 Jul 2011 19:01:42 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO900ESD1KKK1@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 13 Jul 2011 10:00:20 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO9008PQ1KJ53@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 13 Jul 2011 10:00:20 +0800 (CST)
Received: from z41162a ([10.70.76.157]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO90065H1KEZ9@szxml06-in.huawei.com> for ccamp@ietf.org; Wed, 13 Jul 2011 10:00:19 +0800 (CST)
Date: Wed, 13 Jul 2011 10:00:14 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
In-reply-to: <5E893DB832F57341992548CDBB333163A0A91E8292@EMBX01-HQ.jnpr.net>
To: 'John E Drake' <jdrake@juniper.net>, 'Igor Bryskin' <IBryskin@advaoptical.com>, "'Sadler, Jonathan B.'" <Jonathan.Sadler@tellabs.com>, 'Lou Berger' <lberger@labn.net>
Message-id: <005501cc4100$9b4de2c0$d1e9a840$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8hylirMVgKZCZr25ha6UVw)"
Content-language: zh-cn
Thread-index: AcwxxOPVO3QZTzTYcUOg7qxxn4vlzgAMnJkgAOVZfXAADZ+IAAAF6aNQAAEZOjAAFn+jkAAOCgmAABX/IkAAAqWssAAFiNjwAET2toAASIyenQAha/MAAAUf5gAAAL1lgAADIKQAAACdDwAAj3m5gAAAvRgAAAf1ujAAD7oywAAfJRGwAKsRQ6AACV28MAAnUG5gABpmeSAADj4QIA==
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <5E893DB832F57341992548CDBB333163A0A88459D7@EMBX01-HQ.jnpr.net> <D89B562FE4A5B341B18808FB8441CC7C176EA7F9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A0173A67A@atl-srv-mail10.atl.advaoptical.com> <5E893DB832F57341992548CDBB333163A0A899EE83@EMBX01-HQ.jnpr.net> <00a801cc363a$c6c6eb70$5454c250$@com> <5E893DB832F57341992548CDBB333163A0A899F371@EMBX01-HQ.jnpr.net> <005c01cc36cc$ded3c2f0$9c7b48d0$@com> <5E893DB832F57341992548CDBB333163A0A8A68BE9@EMBX01-HQ.jnpr.net> <007e01cc36f5$2dd9fd10$898df730$@com> <5E893DB832F57341992548CDBB333163A0A8A69780@EMBX01-HQ.jnpr.net> <00c401cc3920$0e6f65a0$0501a8c0@user> <26BE7302-C3BD-4D3C-8153-ACDB3FD82E3B@juniper.net> <4E108FA0.1040703@labn.net> <F325F329-2FF5-4ECF-8FEC-3F80799B1CC2@juniper.net> <4E10A994.9010004@labn.net> <2B33B885-12A0-412B-A353-AE08A84496B8@juniper.net> <5292FFA96EC22A4386067E9DBCC0CD2BF785731673@EX-NAP.tellabs-west.tellabsinc.net> <5E893DB832F57341992548CDBB333163A0A8E18F70@EMBX01-HQ.jnpr.net> <tl-srv-mail10.atl.advaoptical.com@huawei.com> <5E893DB832F57341992548CDBB333163A0A8E18FA7@EMBX01-HQ.jnpr.net> <CDAC6F6F5401B245A2C68D0CF8AFDF0A0176D694@atl-srv-mail10.atl.advaoptical.com> <007301cc3f94$e50a9f10$af1fdd30$@com> <5E893DB832F57341992548CDBB333163A0A8FB02E1@EMBX01-HQ.jnpr.net> <00c901cc4059$51c82540$f5586fc0$@com> <5E893DB832F57341992548CDBB333163A0A91E8292@EMBX01-HQ.jnpr.net>
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2011 02:01:44 -0000

Hi John,

 

Please see in-line.

 

If my email below cannot convince you, I have to give up explainning more, J.

 

 

 

Thanks
 
Fatai

 

From: John E Drake [mailto:jdrake@juniper.net] 
Sent: 2011年7月13日 2:44
To: Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Cc: 'CCAMP'
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

 

Fatai,

 

We have had this discussion for several weeks now.

 

Regardless of which of the two methods, implicit or explicit, are used to establish them, these intermediate LSPs exist solely to  support the ODUj service LSPs, so their creation and deletion should be driven what the ODUj service LSPs require.

 

[Fatai] Their creation and deletion should be driven not only by ODUj service LSPs but also the management objective. Right?

 

I don’t understand what it means to talk of rerouting one of these intermediate LSPs because they exist only in the context of the ODUk transport LSP and no one has been able to enlighten me.

 

[Fatai] Pietro and Jonathan has explained a lot about the rerouting of these intermediate LSPs.  

 

I don’t understand why you like to stress “ODUk transport LSP”. You usually like to assume that it must create ODUk transport LSP across multi-hops and then create ODUj service LSP and intermediate stage LSP (which has the same endpoints as ODUk transport LSP) concurrently. (As I have said repeatedly, multi-stage labels are used within the context of a multi-stage multi-hop hierarchical LSP, so I don’t think they apply to the following case.----taken from your another email ). Don’t you think this scenario is not much common? 

 

In addition, usually, “ODUk transport LSP” will not be created in the ODU layer, “ODUk transport LSP” will be created implicitly concurrently with OCh connections, because the relationship between ODUk and OCh is 1:1 (this has been discussed in ITU-T meetings and previous IETF meetings when discussing OTN framework document). For example, there are some OTU3 links between some nodes and these links  can support ODU1 switching, if an ODU1 connection is requested, ODU1 LSP can be created directly over theseOTU3 links and we don’t need to create any ODU3 transport LSP.  Agree?

 

As we discussed last week with Pietro, there is nothing gained by re-signaling an intermediate LSP if one of its endpoints fails. 

 

[Fatai] Endpoint failure is the extreme worst failure (there are lots of other failures/alarms). If the endpoint failure happens on the ODUj service LSPs, they also cannot be recovered.

 

Finally, you should either improve the tone of your emails or stop complaining about the tone of mine.

 

[Fatai] Sorry for my tone but not my intention, J, I just wanted to make things clear. Maybe I should not stress “You”, J, sorry for that.  

 

Thanks,

 

John 

 

Sent from my iPhone

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com] 
Sent: Monday, July 11, 2011 11:03 PM
To: John E Drake; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Cc: 'CCAMP'
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

 

Hi John,

 

> You need control state for an LSP if you want to manage the LSP

> independently from other LSPs. You don't really want to delete,

> reroute, restore, etc. intermediate stage H-LSPs independently from the

> top-of-the-stack LSP, do you?

 

JD:  Certainly not

 

[Fatai] This answer means that "You" don't really want to delete, reroute, restore, etc. intermediate stage H-LSPs independently from the top -of-the-stack LSP, but it does not mean that the operators don't want to do that, moreover, "You" should not force the operators to do as what "you" want (ie., we could provide the options to the operators, but we should not force the operators to do something), because it will overthrow the architecture of transport networks and the operators' habit to manage the transport networks.

 

 

 

Thanks

 

Fatai

 

 

-----Original Message-----
From: John E Drake [mailto:jdrake@juniper.net] 
Sent: 2011年7月11日 19:04
To: Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Cc: 'CCAMP'
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

 

Igor,

 

Comments inline.

 

Thanks,

 

John

 

Sent from my iPhone

 

 

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

> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]

> Sent: Wednesday, July 06, 2011 8:23 AM

> To: John E Drake; Sadler, Jonathan B.; Lou Berger

> Cc: CCAMP

> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> 

> John,

> 

> You need control state for an LSP if you want to manage the LSP

> independently from other LSPs. You don't really want to delete,

> reroute, restore, etc. intermediate stage H-LSPs independently from the

> top-of-the-stack LSP, do you?

 

JD:  Certainly not

 

> 

> You also said:

> The ODU2 has capacity for additional ODU1s and the subsequent signaling

> of these ODU1s can reference that ODU2.

> 

> This could be done via suggested label signaled for a new ODU1, the

> ODU2 is referenced by its data plane (not control plane) ID.

 

JD:  We need to specify which ODU2 we are referencing in order to perform call admission control of the subsequent ODU1s and to set-up the data plane correctly

 

> 

> Igor

> 

 

Sent from my iPhone

 

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

> From: Fatai Zhang [mailto:zhangfatai@huawei.com]

> Sent: Sunday, July 10, 2011 11:37 PM

> To: 'Igor Bryskin'; John E Drake; 'Sadler, Jonathan B.'; 'Lou Berger'

> Cc: 'CCAMP'

> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> 

> Hi John,

> 

> What is the answer to Igor's question?

> 

> 

> 

> 

> 

> Thanks

> 

> Fatai

> 

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

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf

> Of Igor Bryskin

> Sent: 2011年7月6日 23:23

> To: John E Drake; Sadler, Jonathan B.; Lou Berger

> Cc: CCAMP

> Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

> 

> John,

> 

> You need control state for an LSP if you want to manage the LSP

> independently from other LSPs. You don't really want to delete,

> reroute, restore, etc. intermediate stage H-LSPs independently from the

> top-of-the-stack LSP, do you?

> 

> You also said:

> The ODU2 has capacity for additional ODU1s and the subsequent signaling

> of these ODU1s can reference that ODU2.

> 

> This could be done via suggested label signaled for a new ODU1, the

> ODU2 is referenced by its data plane (not control plane) ID.

> 

> Igor

> 

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

> From: John E Drake [mailto:jdrake@juniper.net]

> Sent: Wednesday, July 06, 2011 11:09 AM

> To: Igor Bryskin; Sadler, Jonathan B.; Lou Berger

> Cc: CCAMP

> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> 

> Igor,

> 

> If we have, for example, a containing hierarchical ODU3 LSP which is

> being used to switch ODU1s via an ODU2, then with multi-stage labels,

> an intermediate stage switching ODU2 LSP is implicitly created as part

> of the signaling of the first ODU1.  The ODU2 has capacity for

> additional ODU1s and the subsequent signaling of these ODU1s can

> reference that ODU2.

> 

> I have email from you agreeing with this which I can trot out if

> necessary 8->.

> 

> Thanks,

> 

> John

> 

> Sent from my iPhone

> 

> 

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

> > From: Igor Bryskin [mailto:IBryskin@advaoptical.com]

> > Sent: Wednesday, July 06, 2011 8:02 AM

> > To: John E Drake; Sadler, Jonathan B.; Lou Berger

> > Cc: CCAMP

> > Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> >

> > John,

> >

> > You said:

> >

> > JD:  A set of one or more intermediate stage switching LSPs are also

> > created in the control plane and can be referenced by subsequent ODUj

> > signaling requests.

> >

> > What do you need the control plane state for?

> >

> > Igor

> >

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

> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On

> Behalf

> > Of John E Drake

> > Sent: Wednesday, July 06, 2011 10:47 AM

> > To: Sadler, Jonathan B.; Lou Berger

> > Cc: CCAMP

> > Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

> >

> > Jonathan,

> >

> > Comments inline.

> >

> > Thanks,

> >

> > John

> >

> >

> > Sent from my iPhone

> >

> >

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

> > > From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]

> > > Sent: Wednesday, July 06, 2011 7:26 AM

> > > To: John E Drake; Lou Berger

> > > Cc: CCAMP

> > > Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > >

> > > John,

> > >

> > > This seems ambiguous depending on the scope of the term "LSP".

> This

> > > can refer to a dataplane construct or to a control plane construct.

> >

> > JD:  Doesn't the term LSP typically refer to both aspects?

> > >

> > > I assume you mean "The signaling of an ODUj LSP automatically

> creates

> > > the lower-layer dataplane LSP to support it in addition to the

> > service

> > > LSP.

> >

> > JD:  A set of one or more intermediate stage switching LSPs are also

> > created in the control plane and can be referenced by subsequent ODUj

> > signaling requests.

> >

> > > This is all done without additional signaling sessions for the

> > > lower-layer dataplane LSP."

> >

> > JD:  This is accomplished without explicit signaling of the

> > intermediate stage switching LSPs?

> >

> > >

> > > Can you validate the above statement?

> > >

> > > Thanks,

> > >

> > > Jonathan Sadler

> > >

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

> > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On

> > Behalf

> > > Of John E Drake

> > > Sent: Sunday, July 03, 2011 12:58 PM

> > > To: Lou Berger

> > > Cc: CCAMP

> > > Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

> > >

> > > 'The signaling of an ODUj LSP automatically creates the

> intermediate

> > > switching stage LSPs necessary to support it within the containing

> > > hierarchical ODUk LSP'

> > >

> > > Sent from my iPhone

> > >

> > > On Jul 3, 2011, at 1:40 PM, "Lou Berger" <lberger@labn.net> wrote:

> > >

> > > > John,

> > > >        I think all understand that the question relates to if

> there

> > > > is a

> > > > requirement to support signaling multiple stages in a single LSP.

> > > >

> > > >> What do I need to write to make this clear?

> > > >

> > > > If you disagree, please rephrase as you think is sufficient to

> make

> > > > the

> > > > question clear.

> > > >

> > > > Lou

> > > >

> > > > On 7/3/2011 12:11 PM, John E Drake wrote:

> > > >> Lou,

> > > >>

> > > >> As I think I have written at least two or three times over the

> > past

> > > >> day or so, I don't think the requirement as originally written

> or

> > as

> > > >> revised is useful because both or the two methods under

> discussion

> > > >> will meet it.

> > > >>

> > > >> What do I need to write to make this clear?

> > > >>

> > > >> Thanks,

> > > >>

> > > >> John

> > > >>

> > > >> Sent from my iPhone

> > > >>

> > > >> On Jul 3, 2011, at 11:49 AM, "Lou Berger" <lberger@labn.net>

> > wrote:

> > > >>

> > > >>> So John,

> > > >>>       From my list:

> > > >>> 2) is REQ: (answer yes/no, feel free to elaborate)

> > > >>> 2A) A real requirement? (yes/no)

> > > >>> 2B) A complete non-goal? (yes/no)

> > > >>> 2C) Useful, if can find a reasonable mechanism? (yes/no)

> > > >>> 2D) Just don't care? (yes/no)

> > > >>>

> > > >>> Are you a "yes" in 2C or 2D?

> > > >>>

> > > >>> Lou

> > > >>>

> > > >>> PS I think we have 1 yes on 2A and 1 on 2B so far...

> > > >>>

> > > >>> On 7/3/2011 9:23 AM, John E Drake wrote:

> > > >>>> Fatai,

> > > >>>>

> > > >>>> Since folks don't seem to like the term 'sub-layer LSP', how

> > about

> > > >>>> using 'intermediate switching stage

> > > >>>> LSP'?

> > > >>>>

> > > >>>> To answer your question, I don't agree with your second

> > paragraph.

> > > >>>> I thought I had made it clear that I would prefer one method,

> > > >>>> either sequential Path messages or multi-stage labels, to

> > > establish

> > > >>>> intermediate switching stage LSPs, but not both.  There is no

> > > >>>> reason to support both.

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>> On Jul 2, 2011, at 9:25 PM, "Fatai Zhang"

> > > <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com

> > > >>>>>> wrote:

> > > >>>>

> > > >>>> John,

> > > >>>>

> > > >>>> Do you agree with my second paragraph in my email below?

> > > >>>>

> > > >>>> If not, I would like to step further to make something

> explicit.

> > > >>>>

> > > >>>> Let's continue this example below. If there is no enough

> > resource

> > > >>>> on link BC or CD (or both of them) to create ODU3 FA LSP, or

> if

> > > >>>> Node C can not support ODU3 switching but support ODU3

> > > termination,

> > > >>>> how you can create ODU0 connection with multi-stage labels?

> > > >>>>

> > > >>>> Could you explain a little more?

> > > >>>>

> > > >>>>

> > > >>>> Fatai

> > > >>>>

> > > >>>> Thanks

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

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

> > > >>>> From: John E Drake<mailto:jdrake@juniper.net>

> > > >>>> To: Fatai Zhang<mailto:zhangfatai@huawei.com> ; 'Igor

> > > Bryskin'<mailto:IBryskin@advaoptical.com

> > > >>>>> ; 'GRANDI, PIETRO VITTORIO (PIETRO

> > > VITTORIO)'<mailto:pietro_vittorio.grandi@alcatel-lucent.com

> > > >>>>>

> > > >>>> Cc: 'CCAMP'<mailto:ccamp@ietf.org>

> > > >>>> Sent: Friday, July 01, 2011 10:51 PM

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Fatai,

> > > >>>>

> > > >>>> Please see the email I just sent to the CCAMP  mailing list in

> > > >>>> response to Pietro’s email.  I think it also addresses the

> > points

> > > >>>> in your email, below, and I would appreciate a line-by-line

> > analys

> > > >>>> is of it by you.

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>> From: Fatai Zhang [mailto:zhangfatai@huawei.com]

> > > >>>> Sent: Thursday, June 30, 2011 12:13 AM

> > > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO

> > (PIETRO

> > > >>>> VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Hi John,

> > > >>>>

> > > >>>> OK, Let’s converge.

> > > >>>>

> > > >>>> I think you will agree that multi-stage labels can only be

> used

> > > for

> > > >>>> some cases rather than universal cases.  Based on this example

> > > >>>> below, we can create ODU3 FA LSP and then use one single stage

> > > >>>> muxing (ie., ODU0->ODU3). Another alternative is to create

> ODU2

> > FA

> > > >>>> LSP and then use one single stage muxing (ODU0->ODU2).  For

> > these

> > > >>>> two ways, there is no need to use multi-stage labels. I think

> > you

> > > >>>> can understand that these two ways are better and more

> efficient

> > > >>>> than your approach (two stages (ODU0->ODU2->ODU3) +ODU3 FA-

> LSP).

> > > >>>>

> > > >>>> In addition, we are merging our drafts with [draft- Khuzema]

> to

> > > >>>> give the flexibility for the people to choose what they prefer

> > for

> > > >>>> multi-stage muxing scenario, either (single stage + H-LSP) or

> > > >>>> multi-

> > > >>>> stage labels in some cases. We have figured out a perfect

> > unified

> > > >>>> solution. If people like multi-stage labels, they can choose

> > this

> > > >>>> approach to use. If people do not like multi-stage labels,

> they

> > > can

> > > >>>> just choose single stage + H-LSP.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Fatai

> > > >>>>

> > > >>>> Thanks

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>> [mailto:jdrake@juniper.net]>

> > > >>>> Sent: 2011年6月30日 12:13

> > > >>>> To: John E Drake; Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO

> > > >>>> VITTORIO (PIETRO VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Fatai,

> > > >>>>

> > > >>>> I had one clarification.  Multi-stage labels can be used on

> > links,

> > > >>>> in which case the ‘containing hierarchical LSP’ is the link’s

> > > >>>> OUDk/OTUk, and they would be more efficient than signaling

> > multipl

> > > >>>> e one hop sub-layer LSPs.

> > > >>>>

> > > >>>> However, I seriously doubt than this will be a common case,

> > > because

> > > >>>> having awareness of individual ODUjs in the core of the

> network

> > in

> > > >>>> inherently less scalable than having multi-hop multi-stage

> > > >>>> hierarchical LSPs.

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>>

> > > >>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>> [mailto:jdrake@juniper.net]>

> > > >>>> Sent: 2011年6月30日 11:37

> > > >>>> To: Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO

> > (PIETRO

> > > >>>> VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Fatai,

> > > >>>>

> > > >>>> Comments inline.

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>> From: Fatai Zhang [mailto:zhangfatai@huawei.com]<mailto:

> > > >>>> [mailto:zhangfatai@huawei.com]>

> > > >>>> Sent: Wednesday, June 29, 2011 7:25 PM

> > > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO

> > (PIETRO

> > > >>>> VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Hi John,

> > > >>>>

> > > >>>> So, you admit that ODU0->ODU2->ODU3 cannot be created directly

> > by

> > > >>>> multi-stage label approach if there is no hierarchical ODU3

> > before

> > > >>>> ODU0 request? because you assume that a hierarchical ODU3 (FA)

> > is

> > > >>>> already there.

> > > >>>>

> > > >>>> JD:  Absolutely.  I think I actually stipulated this in an

> email

> > I

> > > >>>> sent you and others some months back.  The basic idea is that

> > you

> > > >>>> create the containing hierarchical  LSP first and then use it

> to

> > > >>>> establish  OUDj client  LSPs and their required sub-layer LSPs

> > as

> > > >>>> needed, with the sub-layer LSPs being established using one of

> > the

> > > >>>> two proposals being discussed.

> > > >>>>

> > > >>>> A few points for clarification, even though I follow your

> > thought.

> > > >>>>

> > > >>>> How to create the ODU3 FA before ODU0 request? I think it is

> > still

> > > >>>> H-LSP concept there.

> > > >>>>

> > > >>>> JD:  Absolutely.  If the ODU0 Path message arrives at B, B

> holds

> > > >>>> it, establishes the ODU3 containing hierarchical LSP to D,

> and

> > > >>>> then *either*

> > > >>>>

> > > >>>>

> > > >>>> 1)      Creates the ODU2 sub-layer by signaling D and then

> sends

> > > >>>> the ODU0 Path message to D *OR*

> > > >>>>

> > > >>>> 2)      Sends the ODU0 Path message to D along with the multi-

> > > stage

> > > >>>> label for the ODU2 LSP

> > > >>>>

> > > >>>> If ODU3 FA between B and D is already there, the FA should be

> > > >>>> regarded as one-hop, because there is no difference between

> one-

> > > hop

> > > >>>> FA and one-hop link. So, this scenario should be treated as

> one-

> > > hop

> > > >>>> scenario rather than multi-hop (Please pay attention to this

> > > >>>> sentence that we are trying to make you understood many

> times).

> > > >>>>

> > > >>>> JD:  I told Sergio and you  last week that I didn’t think mul

> > > >>>> ti-st

> > > >>>> age labels for links (one hop) were interesting or useful, and

> > tha

> > > >>>> t I only considered them useful in the context of multi-hop

> > multis

> > > >>>> tage hierarchical LSPs.  The signaling within the containing

> > hiera

> > > >>>> rchical LSP is between that LSP endpoints so it is one hop.

> > > >>>>

> > > >>>> If ODU3 between B and D is already there based on this

> example,

> > > why

> > > >>>> it needs to use two stage muxing (ODU0->ODU2->ODU3), why not

> > just

> > > >>>> use the simple one stage muxing (ie.,ODU0->ODU3)?  Please

> review

> > > >>>> our slides again to get more information about cons of multi-

> > stage

> > > >>>> muxing(slide 5).

> > > >>>>

> > > >>>> JD:  You could, if that branch is also supported.  In your

> > figure

> > > I

> > > >>>> had mentally edited out the ODU0 -> ODU3 branch so that we had

> > an

> > > >>>> interesting scenario to discuss.

> > > >>>>

> > > >>>> Thanks

> > > >>>>

> > > >>>> Fatai

> > > >>>>

> > > >>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>> [mailto:jdrake@juniper.net]>

> > > >>>> Sent: 2011年6月29日 23:39

> > > >>>> To: Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO

> > (PIETRO

> > > >>>> VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>> Fatai,

> > > >>>>

> > > >>>> Let’s assume we have a containing hierarchical ODU3 between n

> > > >>>> ode B

> > > >>>> and node D over which we want to establish and ODU0.  Using

> the

> > s

> > > >>>> ub-layer hierarchical LSP approach, we would signal a sub-

> layer

> > OD

> > > >>>> U2 hierarchical LSP between B and D and then signal the ODU0.

> > Wit

> > > >>>> h multi-stage labels we would signal the ODU0 and include an

> > ODU2

> > > >>>> multi-stage label.

> > > >>>>

> > > >>>> As I have repeatedly said, either can be made to work with

> some

> > > >>>> non-

> > > >>>> zero amount of effort, but my preference is for multi-stage

> > > labels,

> > > >>>> strictly from an efficiency perspective.  There isn’t enough

> > > >>>> diffe

> > > >>>> rence between the two approaches to warrant standardizing

> both.

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>> From: Fatai Zhang [mailto:zhangfatai@huawei.com]<mailto:

> > > >>>> [mailto:zhangfatai@huawei.com]>

> > > >>>> Sent: Wednesday, June 29, 2011 1:59 AM

> > > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO

> > (PIETRO

> > > >>>> VITTORIO)'

> > > >>>> Cc: 'CCAMP'

> > > >>>> Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>

> > > >>>> Hi John,

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Agree with Igor that let emotions aside if there was some

> > improper

> > > >>>> wording. Let’s discuss tech.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Could you clarify your point 1) a little more? Here is a

> simple

> > > >>>> example shown below.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Could you explain how to create ODU0 connection from Node A to

> > > Node

> > > >>>> E by multi-stage labels approach? What information (e.g.,

> > traffic

> > > >>>> parameters, labels) should be carried in the Path or Resv

> > message?

> > > >>>> What action should be taken for Node C when receiving the Path

> > or

> > > >>>> Resv message?

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> <image001.png>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Thanks

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Fatai

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

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

> > > >>>> From: <mailto:ccamp-bounces@ietf.org> ccamp-

> > > bounces@ietf.org<mailto:ccamp-bounces@ietf.org

> > > >>>>> [mailto:ccamp-bounces@ietf.org]<mailto:[mailto:ccamp-

> > > >>>> bounces@ietf.org]> On Behalf Of John E Drake

> > > >>>> Sent: 2011年6月29日 6:12

> > > >>>> To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>> Cc: CCAMP

> > > >>>> Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Igor,

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> I have a few clarifications.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> 1)  Multi-stage labels apply equally well to multi-hop

> > > hierarchical

> > > >>>> LSPs. (The is the point some people do not seem to

> understand.)

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> 2)  It is incorrect to say that LSP hierarchy, as is, just

> works

> > > >>>> for the establishment of a hierarchical LSP that supports

> multi-

> > > >>>> stage switching.  This involves a nested set of hierarchical

> > LSPs,

> > > >>>> the containing hierarchical LSP and the set of sub-layer LSPs

> > > which

> > > >>>> provide context for intermediate stage labels, between the

> same

> > > two

> > > >>>> endpoints.  This is a new construct and there are almost

> > certainly

> > > >>>> details to be worked out.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> 3)  I don't think we should standardize both approaches.  I

> > would

> > > >>>> prefer that the working group pick one to standardize.

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Thanks,

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> John

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>> Sent from my iPhone

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>

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

> > > >>>>

> > > >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]<mailto:

> > > >>>>> [mailto:IBryskin@advaoptical.com]>

> > > >>>>

> > > >>>>> Sent: Tuesday, June 28, 2011 9:24 AM

> > > >>>>

> > > >>>>> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); John E Drake

> > > >>>>

> > > >>>>> Cc: CCAMP

> > > >>>>

> > > >>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Hi Pietro,

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> You may not like John's tone, but emotions aside, what he

> keeps

> > > >>>>> saying

> > > >>>>

> > > >>>>> repeatedly in this discussion does make perfect sense to me.

> > > >>>>

> > > >>>>> 1) The point of CP signaling is to convey information

> pertinent

> > > to

> > > >>>>

> > > >>>>> network element provisioning in most efficient way. It does

> > seem

> > > >>>>> stupid

> > > >>>>

> > > >>>>> to signal numerous one hop hierarchical LSPs (when it is

> > > >>>>> sufficient a

> > > >>>>

> > > >>>>> single end-to-end round of signaling to do the job), create

> and

> > > >>>>> support

> > > >>>>

> > > >>>>> numerous extra CP states, take care of all restart

> > implications,

> > > >>>>> etc.

> > > >>>>

> > > >>>>> just to be consistent with RFC_XYZ written 10 years ago;

> > > >>>>

> > > >>>>> 2) Besides, you can think of multi-stage label as

> > identification

> > > >>>>> of a

> > > >>>>

> > > >>>>> new type of network resources controlled by GMPLS. Even the

> > GMPLS

> > > >>>>> god-

> > > >>>>

> > > >>>>> fathers would agree that they never meant to limit GMPLS to

> > > >>>>> control the

> > > >>>>

> > > >>>>> resources described in early CCAMP RFCs.

> > > >>>>

> > > >>>>> 3) Finally, no one ever said that you cannot orchestrate

> multi-

> > > >>>>> stage

> > > >>>>

> > > >>>>> provisioning through the hierarchy of LSPs if you choose to

> do

> > > so.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Cheers,

> > > >>>>

> > > >>>>> Igor

> > > >>>>

> > > >>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>> From: <mailto:ccamp-bounces@ietf.org> ccamp-

> > > bounces@ietf.org<mailto:ccamp-bounces@ietf.org

> > > >>>>>> [mailto:ccamp-bounces@ietf.org]<mailto:[mailto:ccamp-

> > > >>>>> bounces@ietf.org]> On Behalf

> > > >>>>

> > > >>>>> Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>> Sent: Tuesday, June 28, 2011 10:43 AM

> > > >>>>

> > > >>>>> To: John E Drake

> > > >>>>

> > > >>>>> Cc: CCAMP

> > > >>>>

> > > >>>>> Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Hello John,

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> 1) You have forwarded to the CCamp mailing list a number of

> > > >>>>> private

> > > >>>>

> > > >>>>> mails without asking the permission to the involved people.

> > This

> > > >>>>> is

> > > >>>>

> > > >>>>> impolite and unprofessional.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> 2) You are creating spam on the mailing list forwarding four

> > > >>>>> threads

> > > >>>>

> > > >>>>> that are each hundreds of lines long and very complicated to

> > > >>>>> follow for

> > > >>>>

> > > >>>>> people not involved in the discussion since the beginning.

> > > >>>>> Moreover,

> > > >>>>

> > > >>>>> this happened after a discussion from scratch was already

> > > >>>>> started in

> > > >>>>

> > > >>>>> the mailing list.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> 3) You moved from a technical discussion to arrogant and

> > > >>>>> deliberate

> > > >>>>

> > > >>>>> personal offenses not supported by any sound technical

> > > >>>>> motivation as

> > > >>>>

> > > >>>>> reported in your mails and snipped below:

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> "This shows a complete lack of understanding of hierarchical

> > LSP,

> > > >>>>

> > > >>>>> multi-stage labels, and GMPLS in general.  It is so bad it is

> > not

> > > >>>>> even

> > > >>>>

> > > >>>>> wrong."

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> " It might be more precise to say I reviewed your slides and

> > > found

> > > >>>>

> > > >>>>> them, shall we say, lacking."

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> We hope that from now on the discussion can be continued from

> a

> > > >>>>> purely

> > > >>>>

> > > >>>>> technical point of view.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Pietro, Sergio and Daniele

> > > >>>>

> > > >>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>> Pietro Vittorio Grandi

> > > >>>>

> > > >>>>> Terrestrial Optics Portfolio Evolution

> > > >>>>

> > > >>>>> Alcatel-Lucent Vimercate (Italy)

> > > >>>>

> > > >>>>> Tel: +39 039 686 4930

> > > >>>>

> > > >>>>> Mail: <mailto:pietro_vittorio.grandi@alcatel-lucent.com>

> > > pietro_vittorio.grandi@alcatel-lucent.com

> > > >>>>> <mailto:pietro_vittorio.grandi@alcatel-lucent.com>

> > > >>>>

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

> > > >>>>

> > > >>>>> Put your hand on a hot stove for a minute, and it seems like

> an

> > > >>>>> hour.

> > > >>>>

> > > >>>>> Sit with a pretty girl for an hour, and it seems like a

> > minute.

> > > >>>>> That's

> > > >>>>

> > > >>>>> relativity.

> > > >>>>

> > > >>>>> (A. Einstein)

> > > >>>>

> > > >>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>> From: <mailto:ccamp-bounces@ietf.org> ccamp-

> > > bounces@ietf.org<mailto:ccamp-bounces@ietf.org

> > > >>>>>> [mailto:ccamp-bounces@ietf.org]<mailto:[mailto:ccamp-

> > > >>>>> bounces@ietf.org]> On Behalf

> > > >>>>

> > > >>>>> Of John E Drake

> > > >>>>

> > > >>>>> Sent: martedì 28 giugno 2011 14.13

> > > >>>>

> > > >>>>> To: CCAMP

> > > >>>>

> > > >>>>> Subject: [CCAMP] FW: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>> From: John E Drake

> > > >>>>

> > > >>>>> Sent: Thursday, June 23, 2011 3:56 PM

> > > >>>>

> > > >>>>> To: 'Fatai Zhang'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>> Cc: Vallinayakam Somasundaram; Tellabs - Jonathan Sadler;

> > > Jonathan

> > > >>>>

> > > >>>>> Hardwick; Li Dan; NSN - Cyril Margaria;

> > > >>>>> <mailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn<mailto:fu.xihua@zte.com.cn

> > > >>>>>> ; Ciena -

> > > >>>>

> > > >>>>> Lyndon Ong; Steve Balls; Diego Caviglia; Ashok

> Kunjidhapatham;

> > > >>>>> BELOTTI,

> > > >>>>

> > > >>>>> SERGIO (SERGIO); Khuzema Pithewan; Rajan Rao; Daniele

> > Ceccarelli

> > > >>>>

> > > >>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Fatai,

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Comments inline.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Thanks,

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> John

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>>> From: Fatai Zhang [mailto:zhangfatai@huawei.com]<mailto:

> > > >>>>>> [mailto:zhangfatai@huawei.com]>

> > > >>>>

> > > >>>>>> Sent: Thursday, June 23, 2011 9:45 AM

> > > >>>>

> > > >>>>>> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); John E Drake

> > > >>>>

> > > >>>>>> Cc: Vallinayakam Somasundaram; Tellabs - Jonathan Sadler;

> > > >>>>>> Jonathan

> > > >>>>

> > > >>>>>> Hardwick; Li Dan; NSN - Cyril Margaria;

> > > >>>>>> <mailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn<mailto:fu.xihua@zte.com.cn

> > > >>>>>>> ; Ciena -

> > > >>>>

> > > >>>>>> Lyndon Ong; Steve Balls; Diego Caviglia; Ashok

> Kunjidhapatham;

> > > >>>>

> > > >>>>> BELOTTI,

> > > >>>>

> > > >>>>>> SERGIO (SERGIO); Khuzema Pithewan; Rajan Rao; Daniele

> > Ceccarelli

> > > >>>>

> > > >>>>>> Subject: Re: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Hi John,

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> I guess that you did not review our slides carefully.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> JD:  I will let this pass.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> You just see the only advantage for the corner case (i.e.,

> > > >>>>>> establish

> > > >>>>

> > > >>>>>> multi-layers LSP concurrently), but you did not see the

> issues

> > > >>>>>> that

> > > >>>>

> > > >>>>> we

> > > >>>>

> > > >>>>>> described in the slides and the issues that Jonathan

> mentioned

> > > >>>>>> (eg.,

> > > >>>>

> > > >>>>>> OAM/protection issues).

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> JD:  I'm sorry that I didn't provide enough context.  I don't

> > > >>>>> think the

> > > >>>>

> > > >>>>> one-hop hierarchical LSP case, w/ or w/o multi-stage labels

> is

> > > >>>>> either

> > > >>>>

> > > >>>>> interesting or common and it was not the case to which I was

> > > >>>>> addressing

> > > >>>>

> > > >>>>> my comments.  Rather, I was describing two ways of

> establishing

> > > >>>>> multi-

> > > >>>>

> > > >>>>> hop multi-stage hierarchical LSPs.  As far as I can tell the

> > > >>>>> issues

> > > >>>>

> > > >>>>> Jonathan raised in this context are red herrings rather than

> > blue

> > > >>>>

> > > >>>>> whales.  Furthermore, regardless of which of the two

> approaches

> > I

> > > >>>>

> > > >>>>> described is used, the issues, if any, would be exactly the

> > same.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> In addition, we have repeated many times that LSP hierarchy

> > > >>>>>> must be

> > > >>>>

> > > >>>>>> used in many cases, even though we have multi-stage label

> > > >>>>>> approach.

> > > >>>>

> > > >>>>>> E.g., an ODU0 connection request from A to E through B, C

> and

> > D,

> > > >>>>>> but

> > > >>>>

> > > >>>>> B,

> > > >>>>

> > > >>>>>> C and  D (or one of them ) can not support ODU0 switching,

> the

> > > HO

> > > >>>>

> > > >>>>> ODUj

> > > >>>>

> > > >>>>>> (ODU1 or ODU2 or ODU3 or ODU4) LSP must be created between B

> > > >>>>>> and D

> > > >>>>

> > > >>>>>> through LSP hierarchy. This example is very simple and there

> > are

> > > >>>>>> lots

> > > >>>>

> > > >>>>>> of transforms for this example to use LSP hierarchy.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>> JD:  Please see above.  I completely agree with you and was

> > > simply

> > > >>>>

> > > >>>>> pointing out that multi-stage labels can be used to improve

> wrt

> > > >>>>> latency

> > > >>>>

> > > >>>>> and control plane overhead, the establishment of ODUj LSPs

> > within

> > > >>>>

> > > >>>>> multi-stage hierarchical LSPs.

> > > >>>>

> > > >>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Fatai

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Thanks

> > > >>>>

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

> > > >>>>

> > > >>>>>> From: "John E Drake"

> > > >>>>>>

> > >

> >

> <<mailto:jdrake@juniper.net>jdrake@juniper.net<mailto:jdrake@juniper.ne

> > > t

> > > >>>>>>>>

> > > >>>>

> > > >>>>>> To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)"

> > > >>>>

> > > >>>>>> <<mailto:pietro_vittorio.grandi@alcatel-

> > > >>>>>> lucent.com>pietro_vittorio.grandi@alcatel-

> > > lucent.com<mailto:pietro_vittorio.grandi@alcatel-lucent.com

> > > >>>>>>>>

> > > >>>>

> > > >>>>>> Cc: "Daniele Ceccarelli"

> > > >>>>>> <<m

> > > >>>>>> ailto:daniele.ceccarelli@

> > > >>>>>>

> > >

> >

> ericsson.com>daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@

> > > ericsson.com

> > > >>>>>>>> ; "Rajan

> > > >>>>

> > > >>>>> Rao"

> > > >>>>

> > > >>>>>>

> > >

> <<mailto:rrao@infinera.com>rrao@infinera.com<mailto:rrao@infinera.com

> > > >>>>>>>> ; "Fatai Zhang"

> > > >>>>>>

> > >

> >

> <<mailto:zhangfatai@huawei.com>zhangfatai@huawei.com<mailto:zhangfatai@

> > > huawei.com

> > > >>>>>>>> ; "Khuzema

> > > >>>>

> > > >>>>>> Pithewan"

> > > >>>>>>

> > >

> >

> <<mailto:kpithewan@infinera.com>kpithewan@infinera.com<mailto:kpithewan

> > > @infinera.com

> > > >>>>>>>> ; "BELOTTI, SERGIO (SERGIO)"

> > > >>>>

> > > >>>>>> <<mailto:sergio.belotti@alcatel-

> > > >>>>>> lucent.com>sergio.belotti@alcatel-

> > > >>>>>> lucent.com<mailto:sergio.belotti@alcatel-lucent.com>>;

> "Ashok

> > > >>>>>> Kunjidhapatham"

> > > >>>>

> > > >>>>>> <<m

> > > >>>>>>

> > >

> >

> ailto:akunjidhapatham@infinera.com>akunjidhapatham@infinera.com<mailto:

> > > akunjidhapatham@infinera.com

> > > >>>>>>>> ; "Diego Caviglia"

> > > >>>>

> > > >>>>>> <<m

> > > >>>>>>

> > >

> >

> ailto:diego.caviglia@ericsson.com>diego.caviglia@ericsson.com<mailto:di

> > > ego.caviglia@ericsson.com

> > > >>>>>>>> ; "Steve Balls"

> > > >>>>

> > > >>>>>>

> > >

> >

> <<mailto:Steve.Balls@metaswitch.com>Steve.Balls@metaswitch.com<mailto:S

> > > teve.Balls@metaswitch.com

> > > >>>>>>>> ; "Ciena - Lyndon Ong"

> > > >>>>>>>>

> > > <<mailto:LyOng@Ciena.com>LyOng@Ciena.com<mailto:LyOng@Ciena.com

> > > >>>>>>>> ;

> > > >>>>

> > > >>>>>>

> > >

> >

> <<mailto:fu.xihua@zte.com.cn>fu.xihua@zte.com.cn<mailto:fu.xihua@zte.co

> > > m.cn

> > > >>>>>>>> ; "NSN - Cyril Margaria"

> > > >>>>

> > > >>>>>

> > >

> >

> <<mailto:cyril.margaria@nsn.com>cyril.margaria@nsn.com<mailto:cyril.mar

> > > garia@nsn.com

> > > >>>>>>> ;

> > > >>>>

> > > >>>>>> "Li Dan"

> > > >>>>>>

> > >

> >

> <<mailto:huawei.danli@huawei.com>huawei.danli@huawei.com<mailto:huawei.

> > > danli@huawei.com

> > > >>>>>>>> ; "Jonathan Hardwick"

> > > >>>>

> > > >>>>>> <<m

> > > >>>>>> ailto:Jonathan.Hardwick@

> > > >>>>>>

> > >

> >

> metaswitch.com>Jonathan.Hardwick@metaswitch.com<mailto:Jonathan.Hardwic

> > > k@metaswitch.com

> > > >>>>>>>> ; "Tellabs - Jonathan Sadler"

> > > >>>>

> > > >>>>>> <<m

> > > >>>>>>

> > >

> >

> ailto:jonathan.sadler@tellabs.com>jonathan.sadler@tellabs.com<mailto:jo

> > > nathan.sadler@tellabs.com

> > > >>>>>>>> ; "Vallinayakam Somasundaram"

> > > >>>>

> > > >>>>>>

> > >

> <<mailto:valli@juniper.net>valli@juniper.net<mailto:valli@juniper.net

> > > >>>>>>>>

> > > >>>>

> > > >>>>>> Sent: Thursday, June 23, 2011 7:21 PM

> > > >>>>

> > > >>>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Pietro,

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> If we are talking about the establishment of LSPs using

> > single-

> > > >>>>>> stage

> > > >>>>

> > > >>>>>> muxing, I think the only thing necessary is a new label

> > format,

> > > >>>>>> which

> > > >>>>

> > > >>>>> I

> > > >>>>

> > > >>>>>> believe is a bit map of tributary slots; i.e., LSP

> > establishment

> > > >>>>

> > > >>>>> using

> > > >>>>

> > > >>>>>> single-stage muxing is done.

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> We have never had a situation such as multi-stage muxing

> > before

> > > >>>>>> so we

> > > >>>>

> > > >>>>>> are breaking new ground and we have two choices, either use

> > LSP

> > > >>>>

> > > >>>>>> hierarchy to establish multiple single-stage sub-layer LSPs

> > > >>>>

> > > >>>>> explicitly

> > > >>>>

> > > >>>>>> and sequentially, or include the sub-layer information

> within

> > > the

> > > >>>>

> > > >>>>> Path

> > > >>>>

> > > >>>>>> message for the ODUj such that the sub-layers are

> established

> > > >>>>

> > > >>>>>> implicitly and concurrently with the establishment of the

> > ODUj.

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Either will work, but it seems to me that the latter is more

> > > >>>>

> > > >>>>> efficient

> > > >>>>

> > > >>>>>> wrt latency and control plane overhead.  The one thing I do

> > not

> > > >>>>>> want

> > > >>>>

> > > >>>>> to

> > > >>>>

> > > >>>>>> do is to say that both are supported.  If we can agree that

> we

> > > >>>>>> will

> > > >>>>

> > > >>>>>> only use one method to establish multi-stage LSPs, then when

> a

> > > >>>>>> node

> > > >>>>

> > > >>>>>> advertises multi-stage support in routing, we know how

> > > >>>>>> signaling is

> > > >>>>

> > > >>>>> to

> > > >>>>

> > > >>>>>> be accomplished.

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Thanks,

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> John

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>>

> > > >>>>

> > > >>>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>>>> [mailto:pietro_vittorio.grandi@alcatel-lucent.com]<mailto:

> > > >>>>>>> [mailto:pietro_vittorio.grandi@alcatel-lucent.com]>

> > > >>>>

> > > >>>>>>> Sent: Monday, June 20, 2011 1:31 AM

> > > >>>>

> > > >>>>>>> To: John E Drake

> > > >>>>

> > > >>>>>>> Cc: Daniele Ceccarelli; Rajan Rao; Fatai Zhang; Khuzema

> > > >>>>>>> Pithewan;

> > > >>>>

> > > >>>>>>> BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham; Diego

> > Caviglia;

> > > >>>>

> > > >>>>> Steve

> > > >>>>

> > > >>>>>>> Balls; Ciena - Lyndon Ong; <mailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn>; NSN - Cyril

> > > >>>>

> > > >>>>> Margaria;

> > > >>>>

> > > >>>>>>> Li Dan; Jonathan Hardwick; Tellabs - Jonathan Sadler;

> > > >>>>>>> Vallinayakam

> > > >>>>

> > > >>>>>>> Somasundaram; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> John,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> It seems as though you consider on the same level something

> > (H-

> > > >>>>>>> LSP

> > > >>>>

> > > >>>>>>> concept) already used in CP managing multi-layer with

> > something

> > > >>>>

> > > >>>>> that

> > > >>>>

> > > >>>>>>> does not exist at all.

> > > >>>>

> > > >>>>>>> Operators are used to managed their CP network together

> with

> > > >>>>>>> NMS.

> > > >>>>

> > > >>>>>>> Most of the NMS work per-layer. The utilization of a multi-

> > > stage

> > > >>>>

> > > >>>>>> label

> > > >>>>

> > > >>>>>>> would force NMS to work in another manner with heavy

> > > >>>>>>> implementation

> > > >>>>

> > > >>>>>>> consequences.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> We should also keep in mind that multi-stage label approach

> > can

> > > >>>>

> > > >>>>> only

> > > >>>>

> > > >>>>>> be

> > > >>>>

> > > >>>>>>> used in some cases (not for all the one-hop multi-stage

> > muxing)

> > > >>>>>>> and

> > > >>>>

> > > >>>>>> it

> > > >>>>

> > > >>>>>>> will bring some management issues. Please see the slides

> that

> > > >>>>>>> Fatai

> > > >>>>

> > > >>>>>>> sent a few days ago.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> For both these reasons the "optional" condition of multi-

> > stage

> > > >>>>

> > > >>>>> label

> > > >>>>

> > > >>>>>>> concept is absolutely mandatory for us.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Pietro, Sergio, Fatai & Daniele

> > > >>>>

> > > >>>>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> Pietro Vittorio Grandi

> > > >>>>

> > > >>>>>>> Terrestrial Optics Portfolio Evolution

> > > >>>>

> > > >>>>>>> Alcatel-Lucent Vimercate (Italy)

> > > >>>>

> > > >>>>>>> Tel: +39 039 686 4930

> > > >>>>

> > > >>>>>>> Mail: <mailto:pietro_vittorio.grandi@alcatel-lucent.com>

> > > pietro_vittorio.grandi@alcatel-lucent.com

> > > >>>>>>> <mailto:pietro_vittorio.grandi@alcatel-lucent.com>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> Put your hand on a hot stove for a minute, and it seems

> like

> > an

> > > >>>>

> > > >>>>> hour.

> > > >>>>

> > > >>>>>>> Sit with a pretty girl for an hour, and it seems like a

> > > minute.

> > > >>>>

> > > >>>>>> That's

> > > >>>>

> > > >>>>>>> relativity.

> > > >>>>

> > > >>>>>>> (A. Einstein)

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>>>>> [mailto:jdrake@juniper.net]>

> > > >>>>

> > > >>>>>>> Sent: sabato 18 giugno 2011 2.40

> > > >>>>

> > > >>>>>>> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>>>> Cc: Daniele Ceccarelli; Rajan Rao; Fatai Zhang; Khuzema

> > > >>>>>>> Pithewan;

> > > >>>>

> > > >>>>>>> BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham; Diego

> > Caviglia;

> > > >>>>

> > > >>>>> Steve

> > > >>>>

> > > >>>>>>> Balls; Ciena - Lyndon Ong; <mailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn>; NSN - Cyril

> > > >>>>

> > > >>>>> Margaria;

> > > >>>>

> > > >>>>>>> Li Dan; Jonathan Hardwick; Tellabs - Jonathan Sadler;

> > > >>>>>>> Vallinayakam

> > > >>>>

> > > >>>>>>> Somasundaram

> > > >>>>

> > > >>>>>>> Subject: Re: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Pietro,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> We can certainly say that a node that advertises multistage

> > > >>>>

> > > >>>>> switching

> > > >>>>

> > > >>>>>>> support in routing MUST support multistage signaling.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> As I said before, using mutiple RSVP exchanges between the

> > same

> > > >>>>>>> LSP

> > > >>>>

> > > >>>>>>> endpoints to establish intermediate switching stages seems

> > ill-

> > > >>>>

> > > >>>>>>> considered and forcing everyone to support two ways of

> > > signaling

> > > >>>>

> > > >>>>>>> multistage LSPs seems like a really Bad Idea.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> John

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> On Jun 17, 2011, at 2:55 AM, "GRANDI, PIETRO VITTORIO

> (PIETRO

> > > >>>>

> > > >>>>>>> VITTORIO)" <pietro_vittorio.grandi@alcatel-

> > > >>>>

> > > >>>>>>>

> > >

> lucent.com<http://lucent.com><<mailto:pietro_vittorio.grandi@alcatel-

> > > lucent.com

> > > >>>>>>>> mailto:pietro_vittorio.grandi@alcatel-lucent.com>>

> > > >>>>

> > > >>>>> wrote:

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Hello John,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> I understand that you think that the new switching type in

> > > >>>>>>> routing

> > > >>>>

> > > >>>>>>> should also convey implicitly the information that a

> > > >>>>

> > > >>>>>>> multi-stage label is supported.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> I do not agree with this statement.

> > > >>>>

> > > >>>>>>> Implementations using H-LSPs plus single stage labels are

> > > >>>>>>> possible

> > > >>>>

> > > >>>>>> (and

> > > >>>>

> > > >>>>>>> already standard) and the fact the a node supports

> > > >>>>

> > > >>>>>>> the new switching type is not enough to clearly tell what

> is

> > > >>>>

> > > >>>>>> supported.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Pietro

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> ________________________________

> > > >>>>

> > > >>>>>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>>>>> [mailto:jdrake@juniper.net]>

> > > >>>>

> > > >>>>>>> Sent: venerdì 17 giugno 2011 2.09

> > > >>>>

> > > >>>>>>> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele

> > > >>>>>>> Ceccarelli;

> > > >>>>

> > > >>>>>>> Rajan Rao; Fatai Zhang; Khuzema Pithewan; BELOTTI, SERGIO

> > > >>>>>>> (SERGIO);

> > > >>>>

> > > >>>>>>> Ashok Kunjidhapatham; Diego Caviglia; 'Steve Balls'; 'Ciena

> -

> > > >>>>

> > > >>>>> Lyndon

> > > >>>>

> > > >>>>>>> Ong'; <mailto:fu.xihua@zte.com.cn

> > > >>>>>>> %3cmailto:fu.xihua@zte.com.cn> fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn><mailto:fu.xihua@zte.com.cn>;

> > 'NSN

> > > -

> > > >>>>>>> Cyril

> > > >>>>

> > > >>>>>>> Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs -

> Jonathan

> > > >>>>

> > > >>>>>> Sadler';

> > > >>>>

> > > >>>>>>> Vallinayakam Somasundaram

> > > >>>>

> > > >>>>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Pietro,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Actually we are already covered.   Our advertisements use a

> > > >>>>

> > > >>>>> different

> > > >>>>

> > > >>>>>>> switching type, which is also carried in signaling.  This

> > means

> > > >>>>

> > > >>>>> that

> > > >>>>

> > > >>>>>> we

> > > >>>>

> > > >>>>>>> get to define the signaling used for this switching type,

> and

> > > >>>>>>> I am

> > > >>>>

> > > >>>>>>> proposing that we use multistage.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Thanks,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> John

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)

> > > >>>>

> > > >>>>>>> [mailto:pietro_vittorio.grandi@alcatel-lucent.com]<mailto:

> > > >>>>>>> [mailto:pietro_vittorio.grandi@alcatel-lucent.com]>

> > > >>>>

> > > >>>>>>> Sent: Thursday, June 16, 2011 6:52 AM

> > > >>>>

> > > >>>>>>> To: Daniele Ceccarelli; John E Drake; Rajan Rao; Fatai

> Zhang;

> > > >>>>

> > > >>>>> Khuzema

> > > >>>>

> > > >>>>>>> Pithewan; BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham;

> > Diego

> > > >>>>

> > > >>>>>>> Caviglia; 'Steve Balls'; 'Ciena - Lyndon Ong';

> > > >>>>

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn%3cmailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn><mailto:fu.xihua@zte.com.cn>;

> > 'NSN

> > > -

> > > >>>>>>> Cyril

> > > >>>>

> > > >>>>>>> Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs -

> Jonathan

> > > >>>>

> > > >>>>>> Sadler';

> > > >>>>

> > > >>>>>>> Vallinayakam Somasundaram

> > > >>>>

> > > >>>>>>> Subject: RE: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Hi all,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> I  agree with Daniele' statement.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> in my mind this means that single stage label support is

> > > >>>>>>> implicit

> > > >>>>

> > > >>>>> and

> > > >>>>

> > > >>>>>>> that

> > > >>>>

> > > >>>>>>> multi-stage labels should not be used unless a machine

> > > >>>>>>> explicitly

> > > >>>>

> > > >>>>>>> declares the support.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Pietro

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> Pietro Vittorio Grandi

> > > >>>>

> > > >>>>>>> Terrestrial Optics Portfolio Evolution

> > > >>>>

> > > >>>>>>> Alcatel-Lucent Vimercate (Italy)

> > > >>>>

> > > >>>>>>> Tel: +39 039 686 4930

> > > >>>>

> > > >>>>>>> Mail: <<mailto:pietro_vittorio.grandi@alcatel-

> > > >>>>>>> lucent.com>mailto:pietro_vittorio.grandi@alcatel-

> lucent.com>

> > > >>>>

> > > >>>>>>> pietro_vittorio.grandi@alcatel-

> > > >>>>>>> <mailto:pietro_vittorio.grandi@alcatel->

> > > >>>>

> > > >>>>>>>

> > >

> lucent.com<http://lucent.com><<mailto:pietro_vittorio.grandi@alcatel-

> > > lucent.com

> > > >>>>>>>> mailto:pietro_vittorio.grandi@alcatel-lucent.com>

> > > >>>>

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

> > > >>>>

> > > >>>>>>> Put your hand on a hot stove for a minute, and it seems

> like

> > an

> > > >>>>

> > > >>>>> hour.

> > > >>>>

> > > >>>>>>> Sit with a pretty girl for an hour, and it seems like a

> > > minute.

> > > >>>>

> > > >>>>>> That's

> > > >>>>

> > > >>>>>>> relativity.

> > > >>>>

> > > >>>>>>> (A. Einstein)

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> ________________________________

> > > >>>>

> > > >>>>>>> From: Daniele Ceccarelli

> > > >>>>>>> [mailto:daniele.ceccarelli@ericsson.com]

> > > >>>>>>> <mailto:[mailto:daniele.ceccarelli@ericsson.com]>

> > > >>>>

> > > >>>>>>> Sent: giovedì 16 giugno 2011 15.48

> > > >>>>

> > > >>>>>>> To: John E Drake; Rajan Rao; Fatai Zhang; Khuzema Pithewan;

> > > >>>>

> > > >>>>> BELOTTI,

> > > >>>>

> > > >>>>>>> SERGIO (SERGIO); Ashok Kunjidhapatham; GRANDI, PIETRO

> > VITTORIO

> > > >>>>

> > > >>>>>> (PIETRO

> > > >>>>

> > > >>>>>>> VITTORIO); Diego Caviglia; 'Steve Balls'; 'Ciena - Lyndon

> > Ong';

> > > >>>>

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn%3cmailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn><mailto:fu.xihua@zte.com.cn>;

> > 'NSN

> > > -

> > > >>>>>>> Cyril

> > > >>>>

> > > >>>>>>> Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs -

> Jonathan

> > > >>>>

> > > >>>>>> Sadler';

> > > >>>>

> > > >>>>>>> Vallinayakam Somasundaram

> > > >>>>

> > > >>>>>>> Subject: RSVP OTN single stage vs multi stage

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Starting a new thread as we're now moving to signaling...

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Assuming we still have not decided whether we're going to

> > > >>>>>>> support

> > > >>>>

> > > >>>>>>> single stage only, multi stage only or both of them i

> believe

> > > >>>>>>> that

> > > >>>>

> > > >>>>> as

> > > >>>>

> > > >>>>>>> per OSPF we need to consider backward compatibility.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> An implementation RFC4328 based (that we've explicitly been

> > > told

> > > >>>>

> > > >>>>> not

> > > >>>>

> > > >>>>>> to

> > > >>>>

> > > >>>>>>> deprecate) is single stage based, so in case of multi stage

> > > only

> > > >>>>>>> or

> > > >>>>

> > > >>>>>>> multi-stage + single stage we should be able to cover

> > backward

> > > >>>>

> > > >>>>>>> compatibility issues somehow.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> BR

> > > >>>>

> > > >>>>>>> Daniele

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> ________________________________

> > > >>>>

> > > >>>>>>> From: John E Drake [mailto:jdrake@juniper.net]<mailto:

> > > >>>>>>> [mailto:jdrake@juniper.net]>

> > > >>>>

> > > >>>>>>> Sent: giovedì 16 giugno 2011 8.53

> > > >>>>

> > > >>>>>>> To: Rajan Rao; Daniele Ceccarelli; Fatai Zhang; Khuzema

> > > >>>>>>> Pithewan;

> > > >>>>

> > > >>>>>>> 'BELOTTI, SERGIO (SERGIO)'; Ashok Kunjidhapatham

> > > >>>>

> > > >>>>>>> Cc: 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'; Diego

> > > Caviglia;

> > > >>>>

> > > >>>>>> 'Steve

> > > >>>>

> > > >>>>>>> Balls'; 'Ciena - Lyndon Ong';

> > > >>>>

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn%3cmailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn><mailto:fu.xihua@zte.com.cn>;

> > 'NSN

> > > -

> > > >>>>>>> Cyril

> > > >>>>

> > > >>>>>>> Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs -

> Jonathan

> > > >>>>

> > > >>>>>> Sadler';

> > > >>>>

> > > >>>>>>> Vallinayakam Somasundaram

> > > >>>>

> > > >>>>>>> Subject: RE: Latest version of the OTN OSPF draft (support

> > for

> > > >>>>

> > > >>>>> multi-

> > > >>>>

> > > >>>>>>> stage Vs Single Stage labels)

> > > >>>>

> > > >>>>>>> Rajan,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> I didn't want to allow interoperability options.  I much

> > > >>>>>>> preferred

> > > >>>>

> > > >>>>> to

> > > >>>>

> > > >>>>>>> say that we do signaling in one way only, using multistage

> > > >>>>>>> labels.

> > > >>>>

> > > >>>>>>> These are also needed for signaling within  hierarchical

> > LSPs.

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Thanks,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> John

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Sent from my iPhone

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> From: Rajan Rao [mailto:rrao@infinera.com]<mailto:

> > > >>>>>>> [mailto:rrao@infinera.com]>

> > > >>>>

> > > >>>>>>> Sent: Wednesday, June 15, 2011 10:46 PM

> > > >>>>

> > > >>>>>>> To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Khuzema

> > > >>>>

> > > >>>>> Pithewan;

> > > >>>>

> > > >>>>>>> 'BELOTTI, SERGIO (SERGIO)'; Ashok Kunjidhapatham

> > > >>>>

> > > >>>>>>> Cc: 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'; Diego

> > > Caviglia;

> > > >>>>

> > > >>>>>> 'Steve

> > > >>>>

> > > >>>>>>> Balls'; 'Ciena - Lyndon Ong';

> > > >>>>

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn%3cmailto:fu.xihua@zte.com.cn>

> > > fu.xihua@zte.com.cn

> > > >>>>>>> <mailto:fu.xihua@zte.com.cn><mailto:fu.xihua@zte.com.cn>;

> > 'NSN

> > > -

> > > >>>>>>> Cyril

> > > >>>>

> > > >>>>>>> Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs -

> Jonathan

> > > >>>>

> > > >>>>>> Sadler';

> > > >>>>

> > > >>>>>>> Vallinayakam Somasundaram

> > > >>>>

> > > >>>>>>> Subject: RE: Latest version of the OTN OSPF draft (support

> > for

> > > >>>>

> > > >>>>> multi-

> > > >>>>

> > > >>>>>>> stage Vs Single Stage labels)

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Hi,

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> While we are making updates, let us discuss support

> required

> > in

> > > >>>>

> > > >>>>> link

> > > >>>>

> > > >>>>>>> advertisement for single/multi-stage label options:

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Given that there is interest in both multi-stage label and

> > > >>>>>>> single-

> > > >>>>

> > > >>>>>> stage

> > > >>>>

> > > >>>>>>> with H-LSPs, we should consider inclusion of a FLAG to

> > indicate

> > > >>>>

> > > >>>>> what

> > > >>>>

> > > >>>>>>> the link is capable of.  This will address some of the

> issues

> > > we

> > > >>>>

> > > >>>>> have

> > > >>>>

> > > >>>>>>> discussed in the past relating to path computation

> involving

> > > NEs

> > > >>>>

> > > >>>>> with

> > > >>>>

> > > >>>>>>> different capabilities (inter-op).

> > > >>>>

> > > >>>>>>>

> > > >>>>

> > > >>>>>>> Thanks

> > > >>>>

> > > >>>>>>> Rajan

> > > >>>>

> > > >>>>> _______________________________________________

> > > >>>>

> > > >>>>> CCAMP mailing list

> > > >>>>

> > > >>>>> <mailto:CCAMP@ietf.org> CCAMP@ietf.org<mailto:CCAMP@ietf.org>

> > > >>>>

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

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

> > > >>>>

> > > >>>>> _______________________________________________

> > > >>>>

> > > >>>>> CCAMP mailing list

> > > >>>>

> > > >>>>> <mailto:CCAMP@ietf.org> CCAMP@ietf.org<mailto:CCAMP@ietf.org>

> > > >>>>

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

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

> > > >>>>

> > > >>>> _______________________________________________

> > > >>>>

> > > >>>> CCAMP mailing list

> > > >>>>

> > > >>>> <mailto:CCAMP@ietf.org>CCAMP@ietf.org<mailto:CCAMP@ietf.org>

> > > >>>>

> > > >>>>

> > >

> >

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

> > > an/listinfo/ccamp

> > > >>>> _______________________________________________

> > > >>>> CCAMP mailing list

> > > >>>> CCAMP@ietf.org

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

> > > _______________________________________________

> > > CCAMP mailing list

> > > CCAMP@ietf.org

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

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

> > _______________________________________________

> > CCAMP mailing list

> > CCAMP@ietf.org

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

> _______________________________________________

> CCAMP mailing list

> CCAMP@ietf.org

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

>