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

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 1 Jul 2011 09:23:27 -0500

Fatai,

While putting both into a single document is a simple editorial exercise, it doesn’t provide any of the architectural guidance required for the multi-layer label case.

As John mentioned in a previous email, how to handle multi-layer in a single signaling session has not been done before.  A solution will address more than just the label format – it will also look at OAM trigger/response configuration.

I look forward to seeing the details for more than just a multi-layer label (e.g. OAM config, Protection object handling, Bundled link processing).  Once this is specified, a real comparison can be performed between the H-LSP approach and the multi-layer label approach.

Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Thursday, June 30, 2011 2: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:[email-masked]]<mailto:[mailto:[email-masked]]>
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 multiple 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:[email-masked]]<mailto:[mailto:[email-masked]]>
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:[email-masked]]<mailto:[mailto:[email-masked]]>
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 multi-stage labels for links (one hop) were interesting or useful, and that I only considered them useful in the context of multi-hop multistage hierarchical LSPs.  The signaling within the containing hierarchical 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:[email-masked]]<mailto:[mailto:[email-masked]]>
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 node B and node D over which we want to establish and ODU0.  Using the sub-layer hierarchical LSP approach, we would signal a sub-layer ODU2 hierarchical LSP between B and D and then signal the ODU0.  With 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 difference between the two approaches to warrant standardizing both.

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
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?

Thanks

Fatai

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

> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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: [email-masked]<mailto:[email-masked]>

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

> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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; [email-masked]<mailto:[email-masked]>; 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:[email-masked]]<mailto:[mailto:[email-masked]]>

> > 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; [email-masked]<mailto:[email-masked]>; 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" <[email-masked]<mailto:[email-masked]>>

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

> > <[email-masked]<mailto:[email-masked]>>

> > Cc: "Daniele Ceccarelli" <[email-masked]<mailto:[email-masked]>>; "Rajan

> Rao"

> > <[email-masked]<mailto:[email-masked]>>; "Fatai Zhang" <[email-masked]<mailto:[email-masked]>>; "Khuzema

> > Pithewan" <[email-masked]<mailto:[email-masked]>>; "BELOTTI, SERGIO (SERGIO)"

> > <[email-masked]<mailto:[email-masked]>>; "Ashok Kunjidhapatham"

> > <[email-masked]<mailto:[email-masked]>>; "Diego Caviglia"

> > <[email-masked]<mailto:[email-masked]>>; "Steve Balls"

> > <[email-masked]<mailto:[email-masked]>>; "Ciena - Lyndon Ong" <[email-masked]<mailto:[email-masked]>>;

> > <[email-masked]<mailto:[email-masked]>>; "NSN - Cyril Margaria"

> <[email-masked]<mailto:[email-masked]>>;

> > "Li Dan" <[email-masked]<mailto:[email-masked]>>; "Jonathan Hardwick"

> > <[email-masked]<mailto:[email-masked]>>; "Tellabs - Jonathan Sadler"

> > <[email-masked]<mailto:[email-masked]>>; "Vallinayakam Somasundaram"

> > <[email-masked]<mailto:[email-masked]>>

> > 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:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > 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; [email-masked]<mailto:[email-masked]>; 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: [email-masked]<mailto:[email-masked]>

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

> > > 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:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > 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; [email-masked]<mailto:[email-masked]>; 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<mailto:[email-masked]>>

> 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:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > 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'; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; '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:[email-masked]]<mailto:[mailto:[email-masked]]>

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

> > > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; '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:[email-masked]>

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

> > > lucent.com<mailto:[email-masked]>

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

> > > 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:[email-masked]]<mailto:[mailto:[email-masked]]>

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

> > > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; '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:[email-masked]]<mailto:[mailto:[email-masked]]>

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

> > > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; '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:[email-masked]]<mailto:[mailto:[email-masked]]>

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

> > > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; '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

> [email-masked]<mailto:[email-masked]>

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

> _______________________________________________

> CCAMP mailing list

> [email-masked]<mailto:[email-masked]>

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

_______________________________________________

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Jul 2011 07:35:09 -0700

Pietro,

We are talking past each other.  I agree with most of what you have written, but it is not applicable to the construct under discussion.  I have been trying to explain this since January, but let me try again.  This is the note I was trying to avoid writing the other day when I sent multiple 'private' emails to the CCAMP mailing list.  Again, my apologies for my sloth.

I would suggest that you read this email and then annotate it line by line to indicate what you agree or disagree with and what you do not understand, rather than simply writing another email telling me how ignorant I am.

The construct is a containing hierarchical ODUk LSP which is being used for multi-stage ODUj switching.  This means that within the containing hierarchical ODUk LSP, additional hierarchical LSPs need to be established in order to provide intermediate context for the ODUj LSPs.  I have been calling these sub-layer LSPs, because they are only there to provide label support between the containing hierarchical ODUk LSP and the ODUj LSPs it is being used to switch and because they have no existence outside the context of the containing hierarchical ODUk LSP.

E.g., if the containing hierarchical ODUk LSP is an ODU3 and the hierarchy it supports is ODU1 -> ODU2 -> ODU3, then after the containing hierarchical ODU3 LSP is established, an ODU2 LSP between the same endpoints as the containing hierarchical ODU3 LSP needs to be established in order to allow the containing hierarchical ODU3 LSP to be used for switching ODU1 LSPs.

THE ONLY POINT OF DISCUSSION is whether these 'sub-layer' LSPs are to established using hierarchical LSP signaling prior to the signaling of the ODUj LSPs or whether multi-stage labels can be piggy-backed on the ODUj signaling message.  Please reread the preceding sentence as many times as necessary in order to understand crux of the discussion.

In our example, the first method would require the signaling of an hierarchical ODU2 LSP between the endpoints of the containing hierarchical ODU3 LSP prior to the signaling of any ODU1 LSPs between the endpoints of the containing hierarchical ODU3 LSP.

The second method would allow the labels for the hierarchical ODU2 LSP to be piggybacked on the signaling of an ODU1 LSP between the endpoints of the containing hierarchical ODU3 LSP.  This allows the hierarchical ODU2 LSP to be implicitly established during the signaling of an ODU1 LSP.

This type of multi-layer hierarchical LSP is new and REGARDLESS of which of the two methods is used to establish the sub-layer LSPs it has the following characteristics:

1)  The sub-layer LSPs share fate with the containing hierarchical LSP

2)  It is IMPOSSIBLE to perform protection/restoration of these sub-layer LSPs outside the context of the containing hierarchical LSP.  This is because the only two nodes that are aware of the existence of these sub-layer LSPs are the nodes at either end of the containing hierarchical LSP

3)  Similarly, and for the same reason, OAM for these sub-layer LSPs can only be done between the endpoints of the containing hierarchical LSPs.  AS AN ASIDE, control plane control of OTN OAM in general is in a nascent state and this construct has not been considered at all.

4)  Existing network management applications do not understand this construct.

5)  From a layer network perspective, the containing hierarchical ODUk LSP and the ODUj LSPs for which it is being used to switch would be visible BUT the sub-layer LSPs would not be.

AND AGAIN, items 1) through 5) above are INVARIANT REGARDLESS of which of the two methods is selected to establish the sub-layer LSP within the containing hierarchical ODUk LSP.

FINALLY, the term 'containing hierarchical ODUk LSP' could be replaced with the term 'link' in all of the above text, BUT I don't think multi-stage switching over links in the core of an OTN link network is viable from a scalability perspective.

Thanks,

John

Sent from my iPhone

> [mailto:[email-masked]]
> Sent: Thursday, June 30, 2011 3:13 AM
> To: John E Drake; CCAMP
> Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO
> (PIETRO VITTORIO)
> it is not clear which is the meaning of "sub-layer" that you have in
> mind,
> but if we consider ITU-T definitions,  from data plane point of view an
> ODU containing another ODU does not define a sub-layer, it defines
> instead a layer.
>
> ITU-T defines the possibility to protect independently all layers in
> the OTN network architecture as well as in SDH architecture.
> As consequence the possibility to perform protection of all layers has
> to be taken as a requirement for signaling and routing protocols.
>
> Protecting or not intermediate layers is a decision in charge of
> operators and not of SDOs.
>
> Multi-layer networking has been standardized by ITU-T several years
> ago,
> has been applied in field to SDH networks and it has been adopted for
> OTN networks. Multi-layer networking is directly supported by H-LSPs,
> thus
> solutions based on H-LSPs would have low impact on NMS because they are
> consistent with current practice and NMS architectures.
>
> Assigning multi-stage labels is just a way to perform signaling
> in very special cases of multi-layer networks, but it imposes a way of
> working in which intermediate layers pops up when client
> This way of working is very different from what is currently supported
> and thus implies  huge modifications.
>
> Moreover to support the generic requirement stated above, a solution
> based only on H-LSPs has to be supported in any case, so there is no
> reason to impose multi-stage label since day one.
>
> A comment about: " The containing hierarchical LSP with multiple sub-
> layer LSPs, regardless of which of the two proposals being discussed
> for establishing the sub-layer LSPs, has nothing whatever to do with
> layer management."
>
> Signaling is an instrument to put in place LSPs that are managed by NMS
> as belonging to layers. So there is a precise relationship with respect
> to layer management in the sense that signaling protocols are tools
> devoted to implement what is needed for management plane and must not
> provide requirements to management.
>
> Said this, again, I have nothing in contrary to support both solutions
> because I understand very well that in some cases there can be
> processing advantages in using multi-stage labels. I am also convinced,
> for what I said before, that multi-stage label support MUST NOT be
> mandatory.
>
> Pietro
>
> From: John E Drake [mailto:[email-masked]]
> Sent: mercoledì 29 giugno 2011 17.53
> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); CCAMP
> Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
> > [mailto:[email-masked]]
> > Sent: Wednesday, June 29, 2011 12:42 AM
> > To: CCAMP
> > Cc: John E Drake; Igor Bryskin; BELOTTI, SERGIO (SERGIO); GRANDI,
> > PIETRO VITTORIO (PIETRO VITTORIO)
> > Hello Igor,
> > The discussion is all in deciding whether to consider the
> > support of multi-stage label as optional or mandatory.
> >
> > Support of multi-stage labels have consequences that include:
> > 1) the fact that it is not possible to protect intermediate layers
> > either via protection or restoration. This restricts the application
> > field of the concept in such a way that it can be considered an
> > optimization applicable to specific cases.
>
> JD:  As I have said before, for the new construct we are dealing with,
> viz, a containing hierarchical LSP with one or more sub-layer LSPs
> between the same two endpoints, it is not possible to protect the
> individual sub-layer LSPs outside the context of the containing
> hierarchical LSP.
>
> >
> > 2) Heavy impacts on transport network management systems that are
> > currently based on "per layer management" and should work in a very
> > different way.
>
> JD:  The construct defined above is new and management systems will
> have to be modified to understand it.
>
> > Last but not least, the OTN architecture allows explicitly the "per
> > layer"
> > management, that is the reference for transport networks. Every GMPLS
> > implementation has to be consistent with this reference.
>
> JD:  The containing hierarchical LSP with multiple sub-layer LSPs,
> regardless of which of the two proposals being discussed for
> establishing the sub-layer LSPs, has nothing whatever to do with layer
> management.
>
> >
> > In conclusion, the usage of the multi-stage label  should be
> considered
> > as optional and the support should be clearly stated via an
> appropriate
> > advertising.
> >
> > Unfortunately, contrary to  point 3), someone insists in forcing the
> > usage and support of multi-stage labels as mandatory.
> >
> > The point in discussion is all here.
> >
> > Best Regards
> > Pietro & Sergio
> >
> >
> > Hi Pietro,
> >
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Mail: [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of John E Drake
> > Hardwick; Li Dan; NSN - Cyril Margaria; [email-masked]; Ciena -
> > > From: Fatai Zhang [mailto:[email-masked]]
> > > Hardwick; Li Dan; NSN - Cyril Margaria; [email-masked]; Ciena
> -
> > > From: "John E Drake" <[email-masked]>
> > > <[email-masked]>
> > > Cc: "Daniele Ceccarelli" <[email-masked]>; "Rajan
> > Rao"
> > > <[email-masked]>; "Fatai Zhang" <[email-masked]>;
> "Khuzema
> > > Pithewan" <[email-masked]>; "BELOTTI, SERGIO (SERGIO)"
> > > <[email-masked]>; "Ashok Kunjidhapatham"
> > > <[email-masked]>; "Diego Caviglia"
> > > <[email-masked]>; "Steve Balls"
> > > <[email-masked]>; "Ciena - Lyndon Ong"
> <[email-masked]>;
> > > <[email-masked]>; "NSN - Cyril Margaria"
> > <[email-masked]>;
> > > "Li Dan" <[email-masked]>; "Jonathan Hardwick"
> > > <[email-masked]>; "Tellabs - Jonathan Sadler"
> > > <[email-masked]>; "Vallinayakam Somasundaram"
> > > <[email-masked]>
> > > > [mailto:[email-masked]]
> > > > Balls; Ciena - Lyndon Ong; [email-masked]; NSN - Cyril
> > Margaria;
> > > > Mail: [email-masked]
> > > > From: John E Drake [mailto:[email-masked]]
> > > > Balls; Ciena - Lyndon Ong; [email-masked]; NSN - Cyril
> > Margaria;
> > > > From: John E Drake [mailto:[email-masked]]
> > > > Ong'; [email-masked]<mailto:[email-masked]>; 'NSN -
> Cyril
> > > > [mailto:[email-masked]]
> > > > [email-masked]<mailto:[email-masked]>; 'NSN - Cyril
> > > > pietro_vittorio.grandi@alcatel-
> > > > From: Daniele Ceccarelli [mailto:[email-masked]]
> > > > [email-masked]<mailto:[email-masked]>; 'NSN - Cyril
> > > > From: John E Drake [mailto:[email-masked]]
> > > > [email-masked]<mailto:[email-masked]>; 'NSN - Cyril
> > > > From: Rajan Rao [mailto:[email-masked]]
> > > > [email-masked]<mailto:[email-masked]>; 'NSN - Cyril
> > [email-masked]
> > [email-masked]

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Jul 2011 07:46:11 -0700

Jonathan,

What I actually said was that stacked hierarchical LSPs, i.e., multiple hierarchical LSPs between the same endpoints, regardless of how they are established, have never been done before.  What I also said was that  control plane control of OAM for OTN networks in general and for stacked hierarchical LSPs in particular, has not really been addressed.

Please see the other email I just sent to the CCAMP mailing list.

Thanks,

John

Sent from my iPhone

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Friday, July 01, 2011 7:23 AM
To: Fatai Zhang; John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'
Cc: 'CCAMP'
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Jonathan Sadler

Hi John,

OK, Let’s converge.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Jul 2011 07:51:06 -0700

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 analysis of it by you.

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
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.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Jul 2011 07:52:12 -0700

What do folks think of the term ‘stacked hierarchical LSPs’?  I think it is pretty evocative.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, July 01, 2011 7:46 AM
To: Sadler, Jonathan B.; Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'
Cc: 'CCAMP'
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Jonathan,

Thanks,

John

Sent from my iPhone

Fatai,

Jonathan Sadler

Hi John,

OK, Let’s converge.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

CCAMP mailing list

---

From: Lou Berger <[email-masked]>
Date: Fri, 01 Jul 2011 11:16:06 -0400

John/All
	I think there's a subtlety in the " crux of the discussion" you refer
to.  I think we're debating requirements but only in the context of a
particular mechanism.  (There are alternate signaling mechanisms that
may make sense, but IMO it doesn't make sense to discuss them without
first agreeing on the requirements.)

So perhaps we can up level a moment and just discuss the key requirement
that is being addressed by multi-stage labels.  If I understand it
correctly (Khuzema, please chime in if I get it wrong), the unaddressed
requirement is:

REQ: Signaling shall provide a mechanism to indicate, in a single
message, the ODUk stages to be used to support a particular ODUj service
across a particular physical or logical link/interface.

  Note that this requirement is limited to a single link/H-LSP.

So two questions for the WG:

1) Does REQ accurately reflect the new requirement? (answer Yes/no)
   If not, what's wrong/missing?

2) is REQ: (answer yes/no, feel free to elaborate)
2A) A real requirement?
2B) A complete non-goal?
2C) Useful, if can find a reasonable mechanism?

I think getting consensus on this at a requirement level is critical for
reaching closure on this discussion.

Lou

On 7/1/2011 10:35 AM, John E Drake wrote:
> THE ONLY POINT OF DISCUSSION is whether these 'sub-layer' LSPs are to
> established using hierarchical LSP signaling prior to the signaling
> of the ODUj LSPs or whether multi-stage labels can be piggy-backed on
> the ODUj signaling message.  Please reread the preceding sentence as
> many times as necessary in order to understand crux of the
> discussion.
>

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 1 Jul 2011 15:43:44 +0000

Lou,

your formulation of REQ is correct. The plurality of "ODUk stages" is important. Use of word "one or more than one" ODUk stages would be more explicit.

Thanks
Khuzema

----- Original Message -----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, July 01, 2011 08:16 AM
To: John E Drake <[email-masked]>; CCAMP <[email-masked]>
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John/All

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 01 Jul 2011 23:47:33 +0800

Hi Jonathan,

I agree with you.

We really don't like multi-stage labels for the corner cases, but some people are fighting to death to make it standardized.

Fatai

Thanks
  ----- Original Message ----- 
  From: Sadler, Jonathan B. 
  To: Fatai Zhang ; 'John E Drake' ; 'Igor Bryskin' ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)' 
  Cc: 'CCAMP' 
  Sent: Friday, July 01, 2011 10:23 PM
  Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

  Fatai,

  Jonathan Sadler

  Hi John,

  OK, Let’s converge. 

   

  Fatai

  Thanks

  Fatai,

  Thanks,

  John

  Sent from my iPhone

  Fatai,

  Comments inline.

  Thanks,

  John

  Sent from my iPhone

  Hi John,

  Thanks
   
  Fatai

  Fatai,

  Thanks,

  John

  Sent from my iPhone

  Hi John,

   

   

  Thanks

  Fatai

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

  Thanks,

  John

  Sent from my iPhone

  > From: Igor Bryskin [mailto:[email-masked]]

  > From: [email-masked] [mailto:[email-masked]] On Behalf

  > From: [email-masked] [mailto:[email-masked]] On Behalf

  > > <[email-masked]>; "Fatai Zhang" <[email-masked]>; "Khuzema

  > > <[email-masked]>; "Ciena - Lyndon Ong" <[email-masked]>;

  > > > Ong'; [email-masked]<mailto:[email-masked]>; 'NSN - Cyril

  CCAMP mailing list

  [email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 02 Jul 2011 00:34:30 +0800

Hi Khuzema and Lou,

I would like to describe the REQ as follows:

Signaling shall provide a mechanism to create a particular ODUj service through one or more than one stages across a particular physical or logical link/interface.

Fatai

Thanks

---

From: Lou Berger <[email-masked]>
Date: Fri, 01 Jul 2011 12:59:04 -0400

So you are saying:
2A) YES
2B) NO
2C) NO

Right?

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 01 Jul 2011 12:59:47 -0400

So you are saying:
2A) YES
2B) NO
2C) NO

Right?  Somehow, I think not...

Lou

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 1 Jul 2011 17:15:08 +0000

Right. Because using multiple single hop H-LSPs in that scenario is overkill.

Thanks
Khuzema

----- Original Message -----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, July 01, 2011 09:59 AM
To: Khuzema Pithewan
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

So you are saying:
2A) YES
2B) NO
2C) NO

Right?

Lou

---

From: John E Drake <[email-masked]>
Date: Sat, 2 Jul 2011 03:36:42 -0700

Lou,

It's a very nice requirement but it does not serve to distinguish between the two proposals;  they both accomplish this.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 01, 2011 8:16 AM
> To: John E Drake; CCAMP

---

From: John E Drake <[email-masked]>
Date: Sat, 2 Jul 2011 03:37:57 -0700

Fatai,

That's also a nice requirement, but again, it does not serve to distinguish between the two.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 01, 2011 9:35 AM
> To: Khuzema Pithewan; [email-masked]; John E Drake; [email-masked]
> Signaling shall provide a mechanism to create a particular ODUj service
> through one or more than one stages across a particular physical or
> logical link/interface.
> 
> 
> 
> 
> Fatai
> 
> Thanks
> > your formulation of REQ is correct. The plurality of "ODUk stages" is
> important. Use of word "one or more than one" ODUk stages would be more
> explicit.
> >
> > Thanks
> > Khuzema
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Sat, 02 Jul 2011 09:06:10 -0400

okay, I thought *stages* was sufficient, but John's right that stages is
1 on more and this question was only about N>1 stages.  so let's
substitute s/the/multiple and we have:

REQ: Signaling shall provide a mechanism to indicate, in a single
message, multiple ODUk stages to be used to support a particular ODUj
service across a particular physical or logical link/interface.

and (added 2D):
>> 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)

So far we have one yes on 2A. (From Khuzema)

Lou

On 7/2/2011 6:36 AM, John E Drake wrote:
> Lou,
> 
> It's a very nice requirement but it does not serve to distinguish
> between the two proposals; they both accomplish this.
> 
> Thanks,
> 
> John
> Sent from my iPhone
>

---

From: John E Drake <[email-masked]>
Date: Sat, 2 Jul 2011 09:07:11 -0700

Lou,

I'm sorry but my point was that as I read the requirement, both  
proposals would meet it.

Thanks,

John

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 03 Jul 2011 08:53:30 +0800

Lou,

I think requirements should not be based on some  specific solution.

I am not a English speaker, but I think your substitute should be correct. 

Could you permit me to describe the REQ as follows?

Signaling shall provide a mechanism to create a particular ODUj service through ODUk stages across a particular physical or logical link/interface.

Fatai

Thanks

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 03 Jul 2011 09:10:08 +0800

Hi John,

All the people have understood that mult-stage labels can only be used for one-hop (ie., a particular physical or logical link/interface).

One of your most important points is: It is more useful to use multi-stage labels across a logical one-hop link than a physical one-hop link.

I agree with your following point: 

=================================================================================================================================================
BUT I don't think multi-stage switching over links in the core of an OTN link network is viable from a scalability perspective.

I told Sergio and you  last week that I didn't think multi-stage labels for links (one hop) were interesting or useful -------taken from another email from you.
==================================================================================================================================================

To Khuzema, Do you agree with John's above conclusion?

Fatai 

Thanks

----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>; "CCAMP" <[email-masked]>
Sent: Friday, July 01, 2011 10:35 PM
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Pietro,

Thanks,

John

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 03 Jul 2011 09:19:27 +0800

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 
  To: Fatai Zhang ; 'Igor Bryskin' ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)' 
  Cc: 'CCAMP' 
  Sent: Friday, July 01, 2011 10:51 PM
  Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

  Fatai,

  Thanks,

  John 

  Sent from my iPhone

  Hi John,

  OK, Let’s converge. 

   

  Fatai

  Thanks

  Fatai,

  Thanks,

  John

  Sent from my iPhone

  Fatai,

  Comments inline.

  Thanks,

  John

  Sent from my iPhone

  Hi John,

  Thanks
   
  Fatai

  Fatai,

  Thanks,

  John

  Sent from my iPhone

  Hi John,

   

   

  Thanks

  Fatai

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

  Thanks,

  John

  Sent from my iPhone

  CCAMP mailing list

  [email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 03 Jul 2011 09:34:14 +0800

Hi Khuzema,

Could you provide a scenario to justify this is a real REQ in the reality rather than in someone's mind in theory?

Fatai

Thanks

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 03 Jul 2011 10:10:52 +0800

Hi Lou,

Sorry for missing "multiple", :-)

---

From: John E Drake <[email-masked]>
Date: Sun, 3 Jul 2011 06:23:08 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

John,

Fatai

Thanks

----- Original Message -----
From: John E Drake<mailto:[email-masked]>
To: Fatai Zhang<mailto:[email-masked]> ; 'Igor Bryskin'<mailto:[email-masked]> ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'<mailto:[email-masked]>
Cc: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, July 01, 2011 10:51 PM
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

OK, Let’s converge.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

> From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf

> Mail: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

> From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf

> Hardwick; Li Dan; NSN - Cyril Margaria; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; Ciena -

> > Hardwick; Li Dan; NSN - Cyril Margaria; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; Ciena -

> > From: "John E Drake" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

> > Cc: "Daniele Ceccarelli" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Rajan

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Fatai Zhang" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Khuzema

> > Pithewan" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "BELOTTI, SERGIO (SERGIO)"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Ashok Kunjidhapatham"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Diego Caviglia"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Steve Balls"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Ciena - Lyndon Ong" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>;

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "NSN - Cyril Margaria"

> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>;

> > "Li Dan" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Jonathan Hardwick"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Tellabs - Jonathan Sadler"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Vallinayakam Somasundaram"

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

> > > Balls; Ciena - Lyndon Ong; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; NSN - Cyril

> > > Mail: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

> > > Balls; Ciena - Lyndon Ong; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; NSN - Cyril

> > > lucent.com<http://lucent.com><<mailto:[email-masked]>mailto:[email-masked]>>

> > > Ong'; <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; 'NSN - Cyril

> > > <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; 'NSN - Cyril

> > > Mail: <<mailto:[email-masked]>mailto:[email-masked]>

> > > lucent.com<http://lucent.com><<mailto:[email-masked]>mailto:[email-masked]>

> > > <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; 'NSN - Cyril

> > > <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; 'NSN - Cyril

> > > <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; 'NSN - Cyril

> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

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

> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

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

CCAMP mailing list

<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 03 Jul 2011 11:49:52 -0400

So John,
	From my list:

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

Lou

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 03 Jul 2011 11:59:45 -0400

Fatai,
	I'm not sure this would be useful to *this thread* (although, if you'd
like to justify why it isn't, please feel free.)

I'd really like to keep the focus of *this thread* on where the WG
participants fall on question 2:

2) is REQ (multiple-stages singled in one LSP):

Thanks,
Lou

PS so far we have 1 2A (Khuzema) and 1 2B (you, by inference).

---

From: John E Drake <[email-masked]>
Date: Sun, 3 Jul 2011 09:11:03 -0700

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" <[email-masked]> wrote:

>> 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" <[email-masked]<mailto:[email-masked]
>> >> wrote:
>>
>> John,
>>
>> 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?
>>
>> To: Fatai Zhang<mailto:[email-masked]> ; 'Igor Bryskin'<mailto:[email-masked]
>> > ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'<mailto:[email-masked]
>> >
>> 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
>>
>> 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
>>
>>
>>
>> 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
>>
>>
>> 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.
>>
>> JD:  Absolutely.  If the ODU0 Path message arrives at B, B holds
>> it, establishes the ODU3 containing hierarchical LSP to D,  and
>> then *either*
>>
>>
>> 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 multi-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
>>
>> Let’s assume we have a containing hierarchical ODU3 between node 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
>>
>> 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?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>> Fatai
>>
>>
>>
>>
>>
>> From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]
>> > [mailto:[email-masked]]<mailto:[mailto:ccamp-
>> [email-masked]]> On Behalf Of John E Drake
>> Sent: 2011年6月29日 6:12
>> 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
>>
>>
>>
>>
>>
>>> From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]
>>> > [mailto:[email-masked]]<mailto:[mailto:ccamp-
>>> [email-masked]]> On Behalf
>>
>>> Mail: <mailto:[email-masked]> [email-masked]
>>> <mailto:[email-masked]>
>>
>>> From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]
>>> > [mailto:[email-masked]]<mailto:[mailto:ccamp-
>>> [email-masked]]> On Behalf
>>
>>> Of John E Drake
>>
>>> Hardwick; Li Dan; NSN - Cyril Margaria;
>>> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]
>>> >; Ciena -
>>
>>>> Hardwick; Li Dan; NSN - Cyril Margaria;
>>>> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]
>>>> >; Ciena -
>>
>>>> From: "John E Drake"
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>
>>
>>>> <<mailto:pietro_vittorio.grandi@alcatel-
>>>> lucent.com>[email-masked]<mailto:[email-masked]
>>>> >>
>>
>>>> Cc: "Daniele Ceccarelli"
>>>> <<m
>>>> ailto:daniele.ceccarelli@
>>>> ericsson.com>[email-masked]<mailto:[email-masked]
>>>> >>; "Rajan
>>
>>> Rao"
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Fatai Zhang"
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Khuzema
>>
>>>> Pithewan" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "BELOTTI, SERGIO (SERGIO)"
>>
>>>> <<mailto:[email-masked]>sergio.belotti@alcatel-
>>>> lucent.com<mailto:[email-masked]>>; "Ashok
>>>> Kunjidhapatham"
>>
>>>> <<m
>>>> ailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Diego Caviglia"
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Steve Balls"
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Ciena - Lyndon Ong" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>;
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "NSN - Cyril Margaria"
>>
>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>> >>;
>>
>>>> "Li Dan" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Jonathan Hardwick"
>>
>>>> <<m
>>>> ailto:Jonathan.Hardwick@
>>>> metaswitch.com>[email-masked]<mailto:[email-masked]
>>>> >>; "Tellabs - Jonathan Sadler"
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>; "Vallinayakam Somasundaram"
>>
>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>> >>
>>
>>>>> [mailto:[email-masked]]<mailto:
>>>>> [mailto:[email-masked]]>
>>
>>>>> Balls; Ciena - Lyndon Ong; <mailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]>; NSN - Cyril
>>
>>> Margaria;
>>
>>>>> Mail: <mailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]>
>>
>>>>> Balls; Ciena - Lyndon Ong; <mailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]>; NSN - Cyril
>>
>>> Margaria;
>>
>>>>> lucent.com<http://lucent.com><<mailto:[email-masked]
>>>>> >mailto:[email-masked]>>
>>
>>> wrote:
>>
>>>>>
>>
>>>>> Hello John,
>>
>>>>>
>>
>>>>> Ong'; <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]><mailto:[email-masked]>; 'NSN -
>>>>> Cyril
>>
>>>>> [mailto:[email-masked]]<mailto:
>>>>> [mailto:[email-masked]]>
>>
>>>>> <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]><mailto:[email-masked]>; 'NSN -
>>>>> Cyril
>>
>>>>> Mail: <<mailto:pietro_vittorio.grandi@alcatel-
>>>>> lucent.com>mailto:[email-masked]>
>>
>>>>> <mailto:pietro_vittorio.grandi@alcatel->
>>
>>>>> lucent.com<http://lucent.com><<mailto:[email-masked]
>>>>> >mailto:[email-masked]>
>>
>>>>> <mailto:[mailto:[email-masked]]>
>>
>>>>> <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]><mailto:[email-masked]>; 'NSN -
>>>>> Cyril
>>
>>>>> <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]><mailto:[email-masked]>; 'NSN -
>>>>> Cyril
>>
>>>>> <mailto:[email-masked]%3cmailto:[email-masked]> [email-masked]
>>>>> <mailto:[email-masked]><mailto:[email-masked]>; 'NSN -
>>>>> Cyril
>>

---

From: Lou Berger <[email-masked]>
Date: Sun, 03 Jul 2011 13:40:36 -0400

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

---

From: John E Drake <[email-masked]>
Date: Sun, 3 Jul 2011 10:58:10 -0700

'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" <[email-masked]> wrote:

>>>>>> Pithewan"
>>>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>>>> ailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>>>>>> ; "Steve Balls"
>>>>
>>>>>>>> ; "Ciena - Lyndon Ong"
>>>>>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>>>>>> ;
>>>>
>>>>>> "Li Dan"
>>>>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>>>>>> ; "Jonathan Hardwick"
>>>>
>>>>>> <<m
>>>>>> ailto:Jonathan.Hardwick@
>>>>>> ailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>>>>>> Ong'; <mailto:[email-masked]
>>>>>>> %3cmailto:[email-masked]> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Sun, 03 Jul 2011 14:10:39 -0400

Okay.  So what's your opinion:

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 04 Jul 2011 09:04:46 +0800

Hi John,

I guessed that you would answer "No", :-)~~

But, you ignored my consequent question:  

If there is no enough resource on link BC or CD (or both of them) to create ODU3 FA LSP between node B and D (but there are available resource for ODU2), or if Node C cannot support ODU3 switching but support ODU3 termination, how you can create ODU0 connection with multi-stage labels?

Thanks
 
Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: 2011年7月3日 21:23
To: Fatai Zhang
Cc: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

John,

Fatai

Thanks

----- Original Message -----
From: John E Drake<mailto:[email-masked]>
To: Fatai Zhang<mailto:[email-masked]> ; 'Igor Bryskin'<mailto:[email-masked]> ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'<mailto:[email-masked]>
Cc: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, July 01, 2011 10:51 PM
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

OK, Let’s converge.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 4 Jul 2011 03:58:00 -0700

Fatai,

I'm sorry but I really have been using my iPhone for the past few days
and I didn't have access to the figure.

I think multi-stage switching is more efficient but it doesn't
introduce magic, so if the resources are not available, multi-stage
labels will not make them available.

Thanks,

John

Sent from my iPhone

On Jul 3, 2011, at 9:04 PM, "Fatai Zhang" <[email-masked]> wrote:

> If there is no enough resource on link BC or CD (or both of them) to
> create ODU3 FA LSP between node B and D (but there are available
> resource for ODU2), or if Node C cannot support ODU3 switching but
> support ODU3 termination, how you can create ODU0 connection with
> multi-stage labels?
>
>
>
>
>
> Thanks
>
> Fatai
>
>
> 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
>
> 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?
>
> response to Pietro’s email.  I think it also addresses the points in
>  your email, below, and I would appreciate a line-by-line analysis o
> f it by you.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> 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
> OUDk/OTUk, and they would be more efficient than signaling multiple
> one hop sub-layer LSPs.
>
> JD:  Absolutely.  If the ODU0 Path message arrives at B, B holds it,
> establishes the ODU3 containing hierarchical LSP to D,  and then
> *either*
>
>
> JD:  I told Sergio and you  last week that I didn’t think multi-stag
> e labels for links (one hop) were interesting or useful, and that I
> only considered them useful in the context of multi-hop multistage h
> ierarchical LSPs.  The signaling within the containing hierarchical
> LSP is between that LSP endpoints so it is one hop.
>
> 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).
>
> Let’s assume we have a containing hierarchical ODU3 between node B a
> nd node D over which we want to establish and ODU0.  Using the sub-l
> ayer hierarchical LSP approach, we would signal a sub-layer ODU2 hie
> rarchical LSP between B and D and then signal the ODU0.  With multi-
> stage labels we would signal the ODU0 and include an ODU2 multi-stag
> e label.
>
> strictly from an efficiency perspective.  There isn’t enough differe
> nce between the two approaches to warrant standardizing both.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> 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
>>> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
>>> >>; "Diego Caviglia"
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 04 Jul 2011 20:19:56 +0800

Hi John,

I think you misunderstood my question, I am not saying that multi-stage labels could be magic, :-)~~~

I just want to make you understand that multi-stage labels cannot handle these typical cases, but H-LSP can do.

Thanks
 
Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: 2011年7月4日 18:58
To: Fatai Zhang
Cc: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 4 Jul 2011 05:41:22 -0700

Fatai,

I am traveling and I'll take
a look at the figure tomorrow.

Thanks,

John

Sent from my iPhone

On Jul 4, 2011, at 8:20 AM, "Fatai Zhang" <[email-masked]> wrote:

> I just want to make you understand that multi-stage labels cannot
> handle these typical cases, but H-LSP can do.
>
>
>
> Thanks
>
> Fatai
>
>
>>  in

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Mon, 4 Jul 2011 15:31:29 +0200

Hello John, in line.

I tried to answer point by point and to add where possible some additional considerations. This time they are from me only but I think they can be shared.

Pietro

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:[email-masked]]
Sent: venerdì 1 luglio 2011 16.35
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); CCAMP
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Pietro,

[[PG]] This is reasonable.  Note also that this first method is the only way in which a network manager is currently able to operate. When deploying a control plane we MUST have in my opinion the possibility to deploy it in such a way that is not disruptive for NMS implementations, and this could mean that setup of LSPs  that need implicit creation of intermediate stages via multi-stage label is an option that could be activated/deactivated on node base.

[[PG]] The optional behavior can be easily obtained simply telling that:
1) A node advertises what is supported
2) A signaling request containing a multi-stage label (with more then 1 stage) can be rejected with a motivation like "feature not supported".
I do not understand why such behavior should not be foreseen.

[[PG]] Yes. I would add that the intermediate stage cannot be completely transparent because bandwidth accounting and restoration are impacting on it. At least two important questions have to be answered too:

1) Which is the de-allocation policy of the intermediate stages.
2) Which are the set-up and hold priorities of the intermediate stages ?
This is motivated by the fact that intermediate stages could be pre-empted for restoration reasons (even if it cannot be restored).

[[PG]] John, this is one point of disagreement. The first mechanism is just the currently standardized H-LSP with FA creation support (I mean the possibility to transmit with signaling an address for the LSP).

Only the second is completely new.

[[PG]] If I have well understood your hypothesis in your example ODU1 -> ODU2 -> ODU3, it must be that  ODU2 and ODU3 have terminations on the same
interfaces. That same interfaces must be also able to demux ODU1 for switching.
This MAY be true or not dependently from implementation of
the mux/demux. If the mux/demux function is obtained cascading two interfaces within the same NE you can have a failure in the intermediate stage without having it in the ODUk. Probably in the case of cascaded interfaces the first method should be preferable.

[[PG]] This is a choice that is in charge of the operator. The physical interface by itself never prevents restoration. FA-LSPs have logical interfaces associated, so when restoring them it is possible to move the endpoints from one interface to another within the same NE, re-signaling only the FA LSP. In your example this allows restoring ODU2s without re-signaling ODU1s. Moreover as said above intermediate stages can be in any case subject to pre-emption.

[[PG]] If the operator chooses so and the function is not obtained with cascaded boards.

[[PG]] Existent NMS do not understand multi-stage label but do understand very well multistage made with H-LSPs because they work exactly with that same logic. They did it for SDH and nothing changes conceptually for OTN.

[[PG]] Yes. But it is an operator choice, not an HW implementation.

[[PG]] John this is another point of disagreement. The conditions are not invariant.
With H-LSPs only you do not need to care about points 1 to 5 while instead all the conditions have to be satisfied in order to go with multi-stage labels and some of the conditions are operator choices not
HW constraints. We should make in such a way that an operator can choose
not to use the mechanism (even by error)

[[PG]] I have understood this.

Thanks,

John

Sent from my iPhone

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 5 Jul 2011 16:20:18 +0200

Hi John and all,

There is a quite common scenario that i don't understand whether it is supported or not by the multistage label.
The scenario is simply a path where the multistage hierarchy is built as a sequence of multiple single stages.
E.g.

A ------- B ---------- C -------------- D ------ E
    ODU1  +                             |  ODU1
          |                             |
          + ODU1->ODU2 +                +
                       |                |
                       +ODU1->ODU2->ODU3+

This is an "asymmetric" scenario, in which an ODU1 is carried from A to B, it is muxed into an ODU2 in B and sent as ODU1->ODU2 from B to C, then another single stage muxing is performed muxing the ODU1->ODU2 into an ODU3 and the ODU1->ODU2->ODU3 is carried form C to D. Node D performes a dual stage demuxing and extracts the ODU1. The ODU1 is then delivered to E.

Is the multistage label able to set-up this kind of path?

I would like to have a single method too, but unless all scenarios are covered also by the multi-stage label method i would prefer to have the sequential path messges as a must and the multi-stage method as optional.

Thanks
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: domenica 3 luglio 2011 15.23
To: Fatai Zhang
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Since folks don't seem to like the term 'sub-layer LSP', how about using 'intermediate switching stage LSP'?

Thanks,

John

Sent from my iPhone

John,

Fatai

Thanks

----- Original Message -----
From: John E Drake<mailto:[email-masked]>
To: Fatai Zhang<mailto:[email-masked]> ; 'Igor Bryskin'<mailto:[email-masked]> ; 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'<mailto:[email-masked]>
Cc: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, July 01, 2011 10:51 PM
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

OK, Let’s converge.

Fatai

Thanks

Fatai,

Thanks,

John

Sent from my iPhone

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

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

Thanks,

John

Sent from my iPhone

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

> From: <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]
> > On Behalf

> [email-masked]<mailto:pietro_vittorio.grand
> [email-masked]>

> From: <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]
> > On Behalf

> Hardwick; Li Dan; NSN - Cyril Margaria; <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>; Ciena -

> > From: Fatai Zhang
> > [mailto:[email-masked]]<mailto:[mailto:[email-masked]]
> > >

> > Hardwick; Li Dan; NSN - Cyril Margaria; <mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>; Ciena -

> > From: "John E Drake"
> > <<mailto:[email-masked]>[email-masked]<mailto:jdrake@juniper
> > .net>>

> > <<mailto:[email-masked]>pietro_vittorio.g
> > [email-masked]<mailto:pietro_vittorio.grandi@alcatel-lucen
> > t.com>>

> > Cc: "Daniele Ceccarelli"
> > <<mailto:[email-masked]>daniele.ceccarelli@ericsson
> > .com<mailto:[email-masked]>>; "Rajan

> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]
> > m>>; "Fatai Zhang"
> > <<mailto:[email-masked]>[email-masked]<mailto:zhangfat
> > [email-masked]>>; "Khuzema

> > <<mailto:[email-masked]>[email-masked]<mailt
> > o:[email-masked]>>; "Ciena - Lyndon Ong"
> > <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>;

> > > [mailto:[email-masked]]<mailto:[mailto:
> > > [email-masked]]>

> > > Balls; Ciena - Lyndon Ong; <mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>; NSN - Cyril

> > > [email-masked]<mailto:pietro_vittorio.g
> > > [email-masked]>

> > > From: John E Drake
> > > [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > Balls; Ciena - Lyndon Ong; <mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>; NSN - Cyril

> > > lucent.com<http://lucent.com><<mailto:pietro_vittorio.grandi@alcat
> > > el-lucent.com>mailto:[email-masked]>>

> > > From: John E Drake
> > > [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > Ong'; <mailto:[email-masked]%3cmailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]><mailto:fu.xihua@zt
> > > e.com.cn>; 'NSN - Cyril

> > > [mailto:[email-masked]]<mailto:[mailto:
> > > [email-masked]]>

> > > <mailto:[email-masked]%3cmailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]><mailto:fu.xihua@zt
> > > e.com.cn>; 'NSN - Cyril

> > > Mail:
> > > <<mailto:[email-masked]>mailto:pietro_v
> > > [email-masked]>

> > > lucent.com<http://lucent.com><<mailto:pietro_vittorio.grandi@alcat
> > > el-lucent.com>mailto:[email-masked]>

> > > From: Daniele Ceccarelli
> > > [mailto:[email-masked]]<mailto:[mailto:daniele.ce
> > > [email-masked]]>

> > > <mailto:[email-masked]%3cmailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]><mailto:fu.xihua@zt
> > > e.com.cn>; 'NSN - Cyril

> > > From: John E Drake
> > > [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > <mailto:[email-masked]%3cmailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]><mailto:fu.xihua@zt
> > > e.com.cn>; 'NSN - Cyril

> > > From: Rajan Rao
> > > [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> > > <mailto:[email-masked]%3cmailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]><mailto:fu.xihua@zt
> > > e.com.cn>; 'NSN - Cyril

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

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

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 06:32:27 -0700

Snipped, comments inline ...

Sent from my iPhone

> 
> The second method would allow the labels for the hierarchical ODU2 LSP
> to be piggybacked on the signaling of an ODU1 LSP between the endpoints
> of the containing hierarchical ODU3 LSP.  This allows the hierarchical
> ODU2 LSP to be implicitly established during the signaling of an ODU1
> LSP.
> 
> [[PG]] Yes. I would add that the intermediate stage cannot be
> completely transparent because bandwidth accounting and restoration are
> impacting on it.

JD:  Bandwidth accounting is the same with either method

> At least two important questions have to be answered
> too:
> 

JD:  A reasonable default would be to remove a set of intermediate switching stage LSPs when there are no more ODUj LSPs requiring that set

> 2) Which are the set-up and hold priorities of the intermediate stages

JD:  A reasonable default would be to use the set-up and holding priorities of the highest ODUj LSP using that set of intermediate switching stage LSPs.

This is actually an important differentiator between the two methods.  The sequential establishment of intermediate switching stage LSPs introduces a number of error cases involving a mismatch in the set-up and holding priorities between the intermediate switching stage LSPs as well as between these LSPs and the ODUj LSPs they are supporting.  These error cases and their ramifications would need to be analyzed and addressed.  

This is an example of the type of issues you are overlooking when you say there is no work to be done to support cascaded hierarchical LSPs using LSP hierarchy

> This is motivated by the fact that intermediate stages could be pre-
> empted for restoration reasons (even if it cannot be restored).

JD:  I would think that it would be the ODUj LSPs that would be pre-empted, followed by my reply to 1), above

> 
> This type of multi-layer hierarchical LSP is new and REGARDLESS of
> which of the two methods is used to establish the sub-layer LSPs it has
> the following characteristics:
> 
> [[PG]] John, this is one point of disagreement. The first mechanism is
> just the currently standardized H-LSP with FA creation support (I mean
> the possibility to transmit with signaling an address for the LSP).
> 

JD:  Stacked hierarchical LSPs are new.  The amount of work required to support them both from an architecture and development perspective is under discussion

> [[PG]] If I have well understood your hypothesis in your example ODU1 -
> > ODU2 -> ODU3, it must be that  ODU2 and ODU3 have terminations on the
> same
> the mux/demux. If the mux/demux function is obtained cascading two
> interfaces within the same NE you can have a failure in the
> intermediate stage without having it in the ODUk. Probably in the case
> of cascaded interfaces the first method should be preferable.

JD:  My point was that if the containing hierarchical LSP fails, all of the intermediate switching stage LSPs also fail.

Wrt your point, the successful restoration of a failed intermediate switching stage LSP at one of its endpoints can be transparent to the other endpoint regardless of the method used to initially establish that LSP, because this is strictly internal to the node at which the LSP failed.

> 
> 3)  Similarly, and for the same reason, OAM for these sub-layer LSPs
> can only be done between the endpoints of the containing hierarchical
> LSPs.  AS AN ASIDE, control plane control of OTN OAM in general is in a
> nascent state and this construct has not been considered at all.
> 

JD:  I don't understand your point

> [[PG]] Existent NMS do not understand multi-stage label but do
> understand very well multistage made with H-LSPs because they work
> exactly with that same logic. They did it for SDH and nothing changes
> conceptually for OTN.

JD:  Cascaded hierarchical LSPs are something new regardless of how the intermediate switching stage LSPs are established, and the network management plane would neither understand nor care how the intermediate switching stage LSPs are established.  In the data plane the two methods produce identical results

> 
> 5)  From a layer network perspective, the containing hierarchical ODUk
> LSP and the ODUj LSPs for which it is being used to switch would be
> visible BUT the sub-layer LSPs would not be.
> 

JD:  I don't understand your point

> 
> AND AGAIN, items 1) through 5) above are INVARIANT REGARDLESS of which
> of the two methods is selected to establish the sub-layer LSP within
> the containing hierarchical ODUk LSP.
> 
> With H-LSPs only you do not need to care about points 1 to 5 while
> instead all the conditions have to be satisfied in order to go with
> multi-stage labels and some of the conditions are operator choices not

JD:  I re-checked my list of five points and I don't see any dependency in them on the method used to establish the intermediate switching stage LSPs

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 6 Jul 2011 09:26:19 -0500

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.

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.  This is all done without additional signaling sessions for the lower-layer dataplane LSP."

Can you validate the above statement?

Thanks,

Jonathan Sadler

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

Sent from my iPhone

On Jul 3, 2011, at 1:40 PM, "Lou Berger" <[email-masked]> wrote:

>>>>>>> [mailto:[email-masked]]

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 10:38:04 -0400

John,
	A couple of things on your mail.

On 7/6/2011 9:32 AM, John E Drake wrote:
>...
> JD: Stacked hierarchical LSPs are new. The amount of work required
> to support them both from an architecture and development perspective
> is under discussion
> 

Not sure why you say "Stacked hierarchical LSPs are new".  There's
nothing new about multiple levels of H-LSPs/FAs.  Although most
implementations only deal with 2 levels in a single CP instance.  The
only thing I see as new is trying to signal them in one signaling
message (which BTW has also been done before, just not standardized.)

> ... 
> JD:  Cascaded hierarchical LSPs are something new regardless of how
> the intermediate switching stage LSPs are established, 

Again, not sure why you're saying this, the *only* thing I see as new is
a standards based way of signaling multiple levels of hierarchy in a
single message.

On an a side, existing signaling uses interface semantics to bind
together hierarchy levels.  Perhaps those are the semantics we should be
considering rather than label semantics to bind multiple levels together
(assuming "multistage/multilevel" signaling is something the WG decides
to pursue.)

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Jul 2011 14:45:55 +0000

Jonathan,
Let me validate your assumption for John :=)
This is exactly my understanding.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sadler, Jonathan B.
Sent: Wednesday, July 06, 2011 10:26 AM
To: John E Drake; Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,

Thanks,

Jonathan Sadler

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

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 07:47:28 -0700

Jonathan,

Comments inline.

Thanks,

John

Sent from my iPhone

> Sent: Wednesday, July 06, 2011 7:26 AM
> 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?

> >>>> On Jul 2, 2011, at 9:25 PM, "Fatai Zhang"
> <[email-masked]<mailto:[email-masked]
> >>>>>> wrote:
> >>>>
> >>>> John,
> >>>>
> >>>>> ; 'GRANDI, PIETRO VITTORIO (PIETRO
> VITTORIO)'<mailto:[email-masked]
> >>>>>
> >>>> 2)      Sends the ODU0 Path message to D along with the multi-
> stage
> >>>> label for the ODU2 LSP
> >>>>
> >>>> From: <mailto:[email-masked]> ccamp-
> [email-masked]<mailto:[email-masked]
> >>>>> From: <mailto:[email-masked]> ccamp-
> [email-masked]<mailto:[email-masked]
> [email-masked]
> >>>>> From: <mailto:[email-masked]> ccamp-
> [email-masked]<mailto:[email-masked]
> >>>>> <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]
> >>>>>> ; Ciena -
> >>>>
> >>>>>> <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]
> >>>>>>> ; Ciena -
> >>>>
> >>>>>> lucent.com>pietro_vittorio.grandi@alcatel-
> lucent.com<mailto:[email-masked]
> >>>>>>>>
> >>>>
> >>>>>> Cc: "Daniele Ceccarelli"
> >>>>>> <<m
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> >>>>>>> deprecate) is single stage based, so in case of multi stage
> only
> >>>>>>> or
> >>>>
> [email-masked]
> [email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 07:53:44 -0700

Lou,

Comments inline.

Thanks,

John

Sent from my iPhone

> Sent: Wednesday, July 06, 2011 7:38 AM
> To: John E Drake
> Cc: CCAMP

JD:  A containing hierarchical LSP with a set of one or more intermediate stage switching LSPs whose endpoints are the same as the endpoints of the containing hierarchical LSP.  I think this is a new construct;  if you were to tell me that Movaz did this ten years ago I would have to believe you and add it my list of Movaz-specific GMPLS extensions.

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Jul 2011 15:01:30 +0000

John,

You said:

What do you need the control plane state for? 

Igor

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

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 08:09:26 -0700

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

> Sent: Wednesday, July 06, 2011 8:02 AM
> To: John E Drake; Sadler, Jonathan B.; Lou Berger
> Cc: CCAMP
> 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.
>
> 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.
>
> > >>>> Since folks don't seem to like the term 'sub-layer LSP', how
> about
> > >>>> using 'intermediate switching stage
> > >>>> LSP'?
> > >>>>
> > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO
> (PIETRO
> > >>>> VITTORIO)'
> > >>>> Cc: 'CCAMP'
> > >>>> To: Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO
> (PIETRO
> > >>>> VITTORIO)'
> > >>>> Cc: 'CCAMP'
> > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO
> (PIETRO
> > >>>> VITTORIO)'
> > >>>> Cc: 'CCAMP'
> > >>>> How to create the ODU3 FA before ODU0 request? I think it is
> still
> > >>>> H-LSP concept there.
> > >>>>
> > >>>> JD:  You could, if that branch is also supported.  In your
> figure
> > I
> > >>>> To: Fatai Zhang; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO
> (PIETRO
> > >>>> VITTORIO)'
> > >>>> Cc: 'CCAMP'
> > >>>> To: John E Drake; 'Igor Bryskin'; 'GRANDI, PIETRO VITTORIO
> (PIETRO
> > >>>> VITTORIO)'
> > >>>> Cc: 'CCAMP'
> > >>>> Agree with Igor that let emotions aside if there was some
> improper
> > >>>> wording. Let’s discuss tech.
> > >>>>
> > >>>>
> > >>>>
> > >>>>> network element provisioning in most efficient way. It does
> seem
> > >>>>> stupid
> > >>>>
> > >>>>> numerous extra CP states, take care of all restart
> implications,
> > >>>>> etc.
> > >>>>
> > >>>>> 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-
> > >>>>
> > >>>>> mails without asking the permission to the involved people.
> This
> > >>>>> is
> > >>>>
> > >>>>> multi-stage labels, and GMPLS in general.  It is so bad it is
> not
> > >>>>> even
> > >>>>
> > >>>>> wrong."
> > >>>>
> > >>>>>
> > >>>>
> > >>>>>> E.g., an ODU0 connection request from A to E through B, C and
> D,
> > >>>>>> but
> > >>>>
> > >>>>> B,
> > >>>>
> > >>>>>> through LSP hierarchy. This example is very simple and there
> are
> > >>>>>> lots
> > >>>>
> > >>>>>> 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
> > >>>>
> > >>>>>> We have never had a situation such as multi-stage muxing
> before
> > >>>>>> so we
> > >>>>
> > >>>>>> wrt latency and control plane overhead.  The one thing I do
> not
> > >>>>>> want
> > >>>>
> > >>>>> to
> > >>>>
> > >>>>>>> It seems as though you consider on the same level something
> (H-
> > >>>>>>> LSP
> > >>>>
> > >>>>>>> used in some cases (not for all the one-hop multi-stage
> muxing)
> > >>>>>>> and
> > >>>>
> > >>>>>> it
> > >>>>
> > >>>>>>> As I said before, using mutiple RSVP exchanges between the
> same
> > >>>>>>> LSP
> > >>>>
> > >>>>>>> <mailto:[email-masked]><mailto:[email-masked]>;
> 'NSN
> > -
> > >>>>>>> Cyril
> > >>>>
> > >>>>>>> <mailto:[email-masked]><mailto:[email-masked]>;
> 'NSN
> > -
> > >>>>>>> Cyril
> > >>>>
> > >>>>>>> <mailto:[email-masked]><mailto:[email-masked]>;
> 'NSN
> > -
> > >>>>>>> Cyril
> > >>>>
> > >>>>>>> <mailto:[email-masked]><mailto:[email-masked]>;
> 'NSN
> > -
> > >>>>>>> Cyril
> > >>>>
> > >>>>>>> <mailto:[email-masked]><mailto:[email-masked]>;
> 'NSN
> > -
> > >>>>>>> Cyril
> > >>>>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Jul 2011 15:23:13 +0000

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:[email-masked]] 
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,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 08:26:04 -0700

Daniele,

I think the short answer is yes.  I wouldn't necessarily describe this situation as asymmetric because it is actually pair-wise symmetric; i.e., A & B support ODU1 switching directly, B & C support ODU1 switching over a containing hierarchical ODU2 LSP (without multi-stage labels), C & D support ODU1 switching over an ODU2 intermediate stage switching LSP (with multi-stage label) within a containing hierarchical ODU3 LSP, and D & E support ODU1 switching directly.

Thanks,

John

Sent from my iPhone

> Sent: Tuesday, July 05, 2011 7:20 AM
> To: John E Drake; Fatai Zhang
> Cc: CCAMP
> There is a quite common scenario that i don't understand whether it is
> supported or not by the multistage label.
> This is an "asymmetric" scenario, in which an ODU1 is carried from A to
> B, it is muxed into an ODU2 in B and sent as ODU1->ODU2 from B to C,
> then another single stage muxing is performed muxing the ODU1->ODU2
> into an ODU3 and the ODU1->ODU2->ODU3 is carried form C to D. Node D
> performes a dual stage demuxing and extracts the ODU1. The ODU1 is then
> delivered to E.
>
> I would like to have a single method too, but unless all scenarios are
> covered also by the multi-stage label method i would prefer to have the
> sequential path messges as a must and the multi-stage method as
> optional.
>
> Thanks
> Daniele
>
> 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
> intermediate switching stage LSPs, but not both.  There is no reason to
> support both.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> John,
>
> 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?
>
> To: Fatai Zhang<mailto:[email-masked]> ; 'Igor
> Bryskin'<mailto:[email-masked]> ; 'GRANDI, PIETRO VITTORIO
> (PIETRO VITTORIO)'<mailto:[email-masked]>
> 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 analysis of it by you.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> 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).
>
> 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
> 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 multiple one hop sub-
> layer LSPs.
>
> inherently less scalable than having multi-hop multi-stage hierarchical
> LSPs.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
> From: John E Drake
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> 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.
>
> 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 multi-stage
> labels for links (one hop) were interesting or useful, and that I only
> considered them useful in the context of multi-hop multistage
> hierarchical LSPs.  The signaling within the containing hierarchical
> 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
> Let’s assume we have a containing hierarchical ODU3 between node B and
> node D over which we want to establish and ODU0.  Using the sub-layer
> hierarchical LSP approach, we would signal a sub-layer ODU2
> hierarchical LSP between B and D and then signal the ODU0.  With multi-
> stage labels we would signal the ODU0 and include an ODU2 multi-stage
> label.
>
> strictly from an efficiency perspective.  There isn’t enough difference
> between the two approaches to warrant standardizing both.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> From: Fatai Zhang
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> 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?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks
>
>
>
> Fatai
>
>
>
>
>
> [email-masked]<mailto:[email-masked]> [mailto:ccamp-
> [email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of
> John E Drake
> Sent: 2011年6月29日 6:12
> 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.
>
>
>
> [email-masked]]
> [email-masked]]
> lucent.com>pietro_vittorio.g
> <<mailto:[email-masked]>[email-masked]<mailto:kpithewan
> @infinera.com>>; "BELOTTI, SERGIO (SERGIO)"
>
> <<mailto:[email-masked]>[email-masked]<mail
> to:[email-masked]>>; "Diego Caviglia"
>
> > >
> <<mailto:[email-masked]>[email-masked]<mailto
> :[email-masked]>>; "Steve Balls"
>
> > >
> <<mailto:[email-masked]>[email-masked]<mailto:huawei.
> [email-masked]>>; "Jonathan Hardwick"
>
> > >
> <<mailto:[email-masked]>Jonathan.Hardwick@metaswitch.
> com<mailto:[email-masked]>>; "Tellabs - Jonathan
> Sadler"
>
> > >
> <<mailto:[email-masked]>[email-masked]<mailto
> :[email-masked]>>; "Vallinayakam Somasundaram"
>
> > >

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 08:31:58 -0700

Igor,

Comments inline.

Thanks,

John

Sent from my iPhone

> Sent: Wednesday, July 06, 2011 8:23 AM
> 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

> 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

> 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 think all understand that the question relates to if
> there
> > > > is a
> > > > If you disagree, please rephrase as you think is sufficient to
> make
> > > > the
> > > > question clear.
> > > >
> > > > Lou
> > > >
> > > >> day or so, I don't think the requirement as originally written
> or
> > as
> > > Bryskin'<mailto:[email-masked]
> > > >>>> I think you will agree that multi-stage labels can only be
> used
> > > for
> > > >>>> muxing (ie., ODU0->ODU3). Another alternative is to create
> ODU2
> > FA
> > > >>>> approach to use. If people do not like multi-stage labels,
> they
> > > can
> > > >>>> having awareness of individual ODUjs in the core of the
> network
> > in
> > > >>>> JD:  Absolutely.  I think I actually stipulated this in an
> email
> > I
> > > >>>> 1)      Creates the ODU2 sub-layer by signaling D and then
> sends
> > > >>>> the ODU0 Path message to D *OR*
> > > >>>>
> > > >>>> 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
> > > >>>> If ODU3 between B and D is already there based on this
> example,
> > > why
> > > >>>> 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
> > > >>>> As I have repeatedly said, either can be made to work with
> some
> > > >>>> non-
> > > >>>> Could you clarify your point 1) a little more? Here is a
> simple
> > > >>>> example shown below.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> provide context for intermediate stage labels, between the
> same
> > > two
> > > >>>>> You may not like John's tone, but emotions aside, what he
> keeps
> > > >>>>> saying
> > > >>>>
> > > >>>>> 1) The point of CP signaling is to convey information
> pertinent
> > > to
> > > >>>>
> > > >>>>> single end-to-end round of signaling to do the job), create
> and
> > > >>>>> support
> > > >>>>
> > > >>>>> 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
> > > >>>>
> > > >>>>>
> > > >>>>
> > > >>>>> We hope that from now on the discussion can be continued from
> a
> > > >>>>> purely
> > > >>>>
> > > >>>>> technical point of view.
> > > >>>>
> > > >>>>>
> > > >>>>
> > > >>>>>> 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).
> > > >>>>
> > > >>>>>
> > > >>>>
> > > >>>>> one-hop hierarchical LSP case, w/ or w/o multi-stage labels
> is
> > > >>>>> either
> > > >>>>
> > > >>>>> my comments.  Rather, I was describing two ways of
> establishing
> > > >>>>> multi-
> > > >>>>
> > > >>>>> whales.  Furthermore, regardless of which of the two
> approaches
> > I
> > > >>>>
> > > >>>>>> C and  D (or one of them ) can not support ODU0 switching,
> the
> > > HO
> > > >>>>
> > > >>>>> ODUj
> > > >>>>
> > > >>>>> pointing out that multi-stage labels can be used to improve
> wrt
> > > >>>>> latency
> > > >>>>
> > > @infinera.com
> > > [email-masked]
> > > >>>>>> and sequentially, or include the sub-layer information
> within
> > > the
> > > >>>>
> > > >>>>> Path
> > > >>>>
> > > >>>>>> 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
> > > >>>>
> > > >>>>>>> Operators are used to managed their CP network together
> with
> > > >>>>>>> NMS.
> > > >>>>
> > > >>>>>>> will bring some management issues. Please see the slides
> that
> > > >>>>>>> Fatai
> > > >>>>
> > > >>>>>>> sent a few days ago.
> > > >>>>
> > > >>>>>>>
> > > >>>>
> > > >>>>>>> Put your hand on a hot stove for a minute, and it seems
> like
> > an
> > > >>>>
> > > >>>>> hour.
> > > >>>>
> > > >>>>>>> get to define the signaling used for this switching type,
> and
> > > >>>>>>> I am
> > > >>>>
> > > >>>>>>> Put your hand on a hot stove for a minute, and it seems
> like
> > an
> > > >>>>
> > > >>>>> hour.
> > > >>>>
> > > >>>>>>> single stage only, multi stage only or both of them i
> believe
> > > >>>>>>> that
> > > >>>>
> > > >>>>> as
> > > >>>>
> > > >>>>>>> While we are making updates, let us discuss support
> required
> > in
> > > >>>>
> > > >>>>> link
> > > >>>>
> > > >>>>>>> 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
> > > >>>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 11:53:43 -0400

John,
	See below.

On 7/6/2011 10:53 AM, John E Drake wrote:
> JD: A containing hierarchical LSP with a set of one or more
> intermediate stage switching LSPs whose endpoints are the same as the
> endpoints of the containing hierarchical LSP. 

I'm having a really hard time parsing this sentence.  I terms familiar
to me include label stacks, H-LSPs, FAs, Upper and Lower (from MLN/MRN),
channel sets, calls, VCGs, etc.  "containing hierarchical LSP" and
"intermediate stage switching LSPs" are not.  I'm not sure which is
upper/lower or inner/outer...  Can you rephrase?

>I think this is a new
> construct; 

I think there may be some new CP constructs, but as you pointed out in
an earlier mail, the label stack / DP is not.

> if you were to tell me that Movaz did this ten years ago I
> would have to believe you and add it my list of Movaz-specific GMPLS
> extensions.

Movaz had a specific proprietary multi-layer construct (I don't know if
it's still used in deployments or not) that went the other way, i.e.,
overlayed multiple (port-based) services on top of what was essentially
an H-LSP.  This approach, while possibly saving some per-LSP state, had
many issues and I really don't think that this approach would be
suitable for standardization.

I was actually thinking of early RSVP-TE (3209) drafts that included a
label stack instead of a single label.  I don't know if anyone ever
implemented or deployed this, but the idea certainly was at least
floated in the early days of TE.

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 6 Jul 2011 16:13:29 +0000

Lou,

Movaz data service construct is very different from the ODUk multi-stage provisioning, IMO the two have nothing in common, I don't understand why you brought it up.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, July 06, 2011 11:54 AM
To: John E Drake
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,
	See below.

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Jul 2011 09:21:05 -0700

Igor,

I'm sorry, it was a joke.  Lou has a long habit of ending GMPLS debates by alluding to Movaz proprietary extensions.

Thanks,

John

Sent from my iPhone

> Sent: Wednesday, July 06, 2011 9:13 AM
> To: Lou Berger; John E Drake
> Cc: CCAMP
> Movaz data service construct is very different from the ODUk multi-
> stage provisioning, IMO the two have nothing in common, I don't
> understand why you brought it up.
> 
> Igor
> 
> Of Lou Berger
> >>>> [[PG]] John, this is one point of disagreement. The first
> mechanism
> >> is

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 12:31:54 -0400

On 7/6/2011 12:13 PM, Igor Bryskin wrote:
> Lou,
> 
> Movaz data service construct is very different from the ODUk
> multi-stage provisioning, 

Igor,
	I believe I said as much in my mail.  I only brought it up in response
to John's comment regarding Movaz 10 years ago...

Lou

> IMO the two have nothing in common, I don't

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 12:36:33 -0400

John,
	Sorry about ruining your joke (and alluding to something the IETF did
~13 years ago.)

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 07 Jul 2011 11:10:49 +0800

Hi John,

I think you misinterpreted Daniele’s scenario and my question in another
email. I am trying to make a clarification here together.

(1)Daniele’s scenario

In Daniele’s scenario, Node C cannot support ODU1 switching, it performs
ODU2 into ODU3. I illustrated this scenario, but replacing ODU1 with ODU0 to
make it more understandable. In this scenario, Node C cannot support ODU0
switching.

Do you think multi-stage labels can handle this scenario? If yes, how to
create ODU0 LSP with multi-stage labels?

(2) Another scenario from me (that you misinterpreted in another email).

In the following secnario, if Node C cannot support ODU3 switching, how you
can create ODU0 LSP with multi-stage labels?

Thanks

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: 2011年7月6日 23:26
To: Daniele Ceccarelli; Fatai Zhang
Cc: CCAMP
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Daniele,

I think the short answer is yes.  I wouldn't necessarily describe this
situation as asymmetric because it is actually pair-wise symmetric; i.e., A
& B support ODU1 switching directly, B & C support ODU1 switching over a
containing hierarchical ODU2 LSP (without multi-stage labels), C & D support
ODU1 switching over an ODU2 intermediate stage switching LSP (with
multi-stage label) within a containing hierarchical ODU3 LSP, and D & E
support ODU1 switching directly.

Thanks,

John

Sent from my iPhone

> The scenario is simply a path where the multistage hierarchy is built

> as a sequence of multiple single stages.

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

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

> (PIETRO VITTORIO)'

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

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

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

> LSP concept there.

> 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

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

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

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

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

> shown below.

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

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

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

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

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

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

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

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

> lucent.com<mailto:pietro_vittorio.grand

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

> establish

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

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

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

> > addressing

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

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

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

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

> > > [email-masked]<mailto:pietro_vittorio.grandi@alcatel-

> lucen

> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]

> m.cn>>; "NSN - Cyril Margaria"

> <<mailto:[email-masked]>[email-masked]<mailto:cyril.ma

> > [email-masked]>>;

> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]

> > > t>>

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

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

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

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

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

> lucent.com]<mailto:[mailto:

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

> Vallinayakam

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

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

> > > > implementation

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

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

> lucent.com<mailto:pietro_vittorio.g

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

> Vallinayakam

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

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

> routing

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

> possible

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

> Ceccarelli;

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

> > > > (SERGIO);

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

> am

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

> lucent.com]<mailto:[mailto:

> lucent.com>mailto:pietro_v

> <mailto:pietro_vittorio.grandi@alca

> > > > tel->

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

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

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

> preferred

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

> labels.

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

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

> an/listinfo/ccamp

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 7 Jul 2011 16:45:34 +0200

Hello John,

Point by point in line with technical consideration.

Personally, I do not believe that in presence of any HW flexibility an operator will leave to CP the freedom to choose which
is the intermediate stage to be allocated. This independently from the way 
in which an LSP is signaled.

When there is a choice between let's say ODU2 or ODU3 intermediate stages this somewhat involves planning, because capacities are high.
Moreover, the operator will not have available certain functionalities for intermediate stages (e.g restoration) when using multi-stage labels.
So the operator must have an explicit way to choose not to make use of multi-stage label.

I expect that a NMS will issue one or more explicit commands telling to the NE what has to be done.

This considered, there is no reason to force an implementation to have
multi-stage label since day one. (and even no reason to implement it until
it has been verified that there is a real scaling problem)

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: mercoledì 6 luglio 2011 15.32
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); CCAMP
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Sent from my iPhone

[[PG]] As you say below, bandwidth accounting of intermediate stages depends from the priority of ODUj if multi-stage labels are used and the effect has to be cascaded to all intermediate stages .
It is not so if signaling with H-LSPs is used. 

[[PG]] This is reasonable. If we go with multi-stage labels it can be inserted in the specs.

This is an example of the type of issues you are overlooking when you say there is no work to be done to support cascaded hierarchical LSPs using LSP hierarchy[[PG]] .

[[PG]] 
When intermediate stages are explicitly signaled, the priority
of ALL upper layers is dependent from the priority of the intermediate
layers. This is reflected in bandwidth accounting reducing the resources
of all upper layers accordingly to the priority of the intermediate stage.
This operation is made once and for all.

So if intermediate stage is allocated at priority 5, we simply have to
subtract from upper layers resources from priority 1 to 4, so that high priority ODUj cannot use LO-priority H-LSPs.

With multi-stage label, bandwidth accounting for intermediate stages
changes dynamically dependently from the priorities of the clients and
the algorithm is not very clear to me. 
For instance, why should we accept an ODUj with priority = 0 if the intermediate stage has already been instantiated implicitly with a lower priority ?  If we allow the intermediate stage change in priority then
indirectly other ODUjs are affected. I am not really convinced that
it is something easy to control.

[[PG]] Let me explain better what I intended. 
Take the usual example of ODU1-ODU2-ODU3  when we are restoring an ODU2 LSP with a certain priority, routing checks bandwidth accounting for ODU 2. If the priority allows it the ODU2 is pre-empted independently from the fact that it is explicitly signaled or not. 

This has as side effect that ODUjs are pre-empted as well (and maybe are restored). With this respect the ODUj bandwidth accounting mechanism makes
some difference. 

Even if I cannot prove it I have the suspect that the dynamic bandwidth accounting of intermediate stages might cause a higher
number of crankbacks during heavy restoration processes because some intermediate stages that are believed pre-emptable suddenly are no more pre-emptable because a high priority ODUj forbids it. 

[[PG]]
The situation seems to be that up to now I do not see a single thing that cannot be supported with  current H-LSPs, while you say otherwise. 
In order to progress with the discussion I suggest that
you produce a list of items that in your mind have to be studied.

[[PG]] Yes

[[PG]] My point was more about fate sharing. I was trying to say that
fate sharing is not the same because the intermediate stages traverse
two boards, so the alarm situation is very different. The fact that a node 
is able to restore the intermediate layer internally is implementation dependent. It may happen that a NE can repair the problem internally, but it may also not happen. 
Having the LSP signaled in this case allows to restore intermediate stages instead of all the ODUjs. Of course the decision of which method use cannot be made by CP. I expect it is made by an operator.

JD:  I don't understand your point
[[PG]] Sorry John, I was to much telegraphic.. The point is related to fate sharing. When the intermediate stage is obtained cascading boards, OAM points are not only at the end points because you may need to perform alarm
localization, so some sort of tandem monitoring should be equipped. But
I do not want really to enter this discussion.

The important point is that while having different HW architectures to obtain the same thing, some of them granting fate sharing and some not, it is an operator choice to decide whether leave the control plane to use multi-stage labels or not. 

[[PG]]Well, SDH works with cascaded LSPs since a long time. (VC2, VC3 and VC4 are nothing else then cascaded LSPs). So in transport technology the concepts are not really new. Transport NMS are also multi-technology (they support PDH,WDM etc... managing them with SDH as a whole).

> [[PG]] Yes. But it is an operator choice, not an HW implementation.

JD:  I don't understand your point.

[PG] OK. Let me explain better. The point is generic: since some functionalities for intermediate stages are lost , it is the operator that has to say to CP: I allow usage of multi-stage and I know what I cannot do on intermediate stages. 

[[PG]] If I have well understood, if point 1 to 5 are satisfied then multi-stage label can be applied. What I intended is that with H-LSPs
there is no need to perform any check because they can be applied in any condition.

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Jul 2011 08:31:26 -0700

Fatai,

Comments inline.  Btw, you should be more precise in your terminology – we are discussing the capabilities of Node C’s interfaces and not Node C’s capabilities.

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, July 06, 2011 8:11 PM
To: John E Drake; 'Daniele Ceccarelli'
Cc: 'CCAMP'
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Hi John,

I think you misinterpreted Daniele’s scenario and my question in another email. I am trying to make a clarification here together.

(1)Daniele’s scenario

In Daniele’s scenario, Node C cannot support ODU1 switching, it performs ODU2 into ODU3. I illustrated this scenario, but replacing ODU1 with ODU0 to make it more understandable. In this scenario, Node C cannot support ODU0 switching.

Do you think multi-stage labels can handle this scenario? If yes, how to create ODU0 LSP with multi-stage labels?

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

I think an ODU2 hierarchical LSP needs to be created between Node B’s left facing interface and Node D’s right facing interface and that hierarchical LSP supports single stage ODU0 switching.

In the following secnario, if Node C cannot support ODU3 switching, how you can create ODU0 LSP with multi-stage labels?

JD:  See above

Thanks

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: 2011年7月6日 23:26
To: Daniele Ceccarelli; Fatai Zhang
Cc: CCAMP
Subject: RE: [CCAMP] RSVP OTN single stage vs multi stage

Daniele,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Jul 2011 12:31:11 -0700

Snipped, comments inline.

Sent from my iPhone

> Personally, I do not believe that in presence of any HW flexibility an
> operator will leave to CP the freedom to choose which
> When there is a choice between let's say ODU2 or ODU3 intermediate
> stages this somewhat involves planning, because capacities are high.

JD:  The capabilities are exactly the same whether the intermediate switching stages are established with a set of sequential Path messages (method 1) or with multi-stage labels (method 2)
  
> Moreover, the operator will not have available certain functionalities
> for intermediate stages (e.g restoration) when using multi-stage
> labels.

JD:  Would you please give me a brief description of what you mean by 'restoration' in the above text and how you think it will be accomplished using GMPLS signaling?  We have gone around on this multiple times and I think either one or both of us is confused.

> it has been verified that there is a real scaling problem)

JD:  My preference has always been one method.

> [[PG]] As you say below, bandwidth accounting of intermediate stages
> depends from the priority of ODUj if multi-stage labels are used and
> the effect has to be cascaded to all intermediate stages .

JD:  Bandwidth accounting is the same with either method.  Per Section 6.3 of RFC 4206 and as I stated in my previous email,
the intermediate switching stages inherit the holding priority of the ODUj service LSP.  More importantly, the containing hierarchical ODUk transport LSP also inherits the ODUj holding priority.

> 
> > 2) Which are the set-up and hold priorities of the intermediate
> stages
> > ?
> 
> JD:  A reasonable default would be to use the set-up and holding
> priorities of the highest ODUj LSP using that set of intermediate
> switching stage LSPs.
> 
> This is actually an important differentiator between the two methods.
> The sequential establishment of intermediate switching stage LSPs
> introduces a number of error cases involving a mismatch in the set-up
> and holding priorities between the intermediate switching stage LSPs as
> well as between these LSPs and the ODUj LSPs they are supporting.
> These error cases and their ramifications would need to be analyzed and
> addressed.
> 
> This is an example of the type of issues you are overlooking when you
> say there is no work to be done to support cascaded hierarchical LSPs
> using LSP hierarchy[[PG]] .
> 
> [[PG]]
> subtract from upper layers resources from priority 1 to 4, so that high
> priority ODUj cannot use LO-priority H-LSPs.

JD:  Per Section 6.3 of RFC 4206 the above is simply incorrect.

> For instance, why should we accept an ODUj with priority = 0 if the
> intermediate stage has already been instantiated implicitly with a
> lower priority ?  If we allow the intermediate stage change in priority
> then

JD:  Per Section 6.3 of RFC 4206, this is the way hierarchical LSPs work.

> JD:  I would think that it would be the ODUj LSPs that would be pre-
> empted, followed by my reply to 1), above
> 
> Take the usual example of ODU1-ODU2-ODU3  when we are restoring an ODU2
> LSP with a certain priority, routing checks bandwidth accounting for
> ODU 2. If the priority allows it the ODU2 is pre-empted independently
> from the fact that it is explicitly signaled or not.

JD:  For your example, above, we would advertise the bandwidth available for the ODUj (= ODU1) service LSPs and the underlying ODUK (= ODU3) transport LSP bandwidth.  We would not be advertising the intermediate switching stage (= ODU2) bandwidth.  As I originally wrote, above, it is the ODUj LSPs that would be pre-empted. 

> 
> This has as side effect that ODUjs are pre-empted as well (and maybe
> are restored). With this respect the ODUj bandwidth accounting
> mechanism makes
> some difference.

JD:  See Section 6.3 of RFC 4206.

> 
> Even if I cannot prove it I have the suspect that the dynamic bandwidth
> accounting of intermediate stages might cause a higher
> number of crankbacks during heavy restoration processes because some
> intermediate stages that are believed pre-emptable suddenly are no more
> pre-emptable because a high priority ODUj forbids it.

JD:  See Section 6.3 of RFC 4206, and again, we don't advertise intermediate switching stage bandwidth.  

> JD:  Stacked hierarchical LSPs are new.  The amount of work required to
> support them both from an architecture and development perspective is
> under discussion
> 
> [[PG]]
> The situation seems to be that up to now I do not see a single thing
> that cannot be supported with  current H-LSPs, while you say otherwise.

JD:  The issue I with which I am most concerned is that in signaling the endpoint addresses of an intermediate switching stage LSP are also the addresses of the containing hierarchical LSP.  Even if this is allowed in RFC 6107, I am not sure that implementations would allow this.

We will also need to define some new flags in the RFC 6107 objects to indicate that the LSP being signaled is an intermediate switching stage LSP.

And as I mentioned, above, in my previous email, I think we also need to indicate that the set-up and holding priorities in the signaling message for an intermediate switching stage LSP are meaningless.
 
> 
> Wrt your point, the successful restoration of a failed intermediate
> switching stage LSP at one of its endpoints can be transparent to the
> other endpoint regardless of the method used to initially establish
> that LSP, because this is strictly internal to the node at which the
> LSP failed.
> 
> is able to restore the intermediate layer internally is implementation
> dependent. It may happen that a NE can repair the problem internally,
> but it may also not happen.
> Having the LSP signaled in this case allows to restore intermediate
> stages instead of all the ODUjs. Of course the decision of which method
> use cannot be made by CP. I expect it is made by an operator.

JD:  Either the node that experiences the failure can fix it transparently or it can't.  If it can, then nothing is externally visible.  If it can't, it should indicate that the affected ODUJ service LSPs have failed.

Re-signaling the intermediate LSP seems absolutely useless.
   
> JD:  Cascaded hierarchical LSPs are something new regardless of how the
> intermediate switching stage LSPs are established, and the network
> management plane would neither understand nor care how the intermediate
> switching stage LSPs are established.  In the data plane the two
> methods produce identical results
> 
> 
> [[PG]]Well, SDH works with cascaded LSPs since a long time. (VC2, VC3
> and VC4 are nothing else then cascaded LSPs). So in transport
> technology the concepts are not really new. Transport NMS are also
> multi-technology (they support PDH,WDM etc... managing them with SDH as
> a whole).

JD:  Let me try again.  Our new construct is what I am terming a 'stacked hierarchical LSP' which consists of a containing hierarchical LSP (the ODUk transport LSP) and a set of one or more intermediate switching stage LSPs, where the endpoints of both the containing hierarchical LSP and the intermediate switching stage LSPs are congruent.  

It is congruency that is new, and as I indicated above, I have a few concerns about it.

> JD:  I re-checked my list of five points and I don't see any dependency
> in them on the method used to establish the intermediate switching
> stage LSPs
> 
> [[PG]] If I have well understood, if point 1 to 5 are satisfied then
> multi-stage label can be applied. What I intended is that with H-LSPs

JD:  Points 1 - 5 apply to 'stacked hierarchical LSPs' and not to multi-stage labels.

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Jul 2011 13:13:23 -0700

Hi,

Thanks,

John

Sent from my iPhone

> > endpoints of the containing hierarchical LSP.

JD:  We first signal a containing hierarchical LSP.  (I use the term 'containing' simply to indicate that everything else is contained within it.)  This is the ODUk transport LSP the endpoints of which have an RSVP signaling adjacency used to establish ODUj service LSPs which transit it.

If j < k - 1, the ODUk transport LSP is performing multi-stage switching, e.g., ODU1 <-> ODU2 <-> ODU3 (where right arrows indicate multiplexing and left arrows indicate de-multiplexing), and hierarchical LSPs need to be established for the intermediate switching stages.  I use the term 'intermediate switching stage LSP' to describe such an LSP, which in this example is the ODU2 LSP.

'Sequential hierarchical LSPs' is the term used to indicate that the intermediate switching stage LSPs are explicitly established to complete the OTN multi-stage switching path between the ODUj service LSPs and the ODUk transport LSP.  'Multi-stage labels' is the term used to indicate that the intermediate switching stage LSPs are implicitly established as part of the establishment of select ODUj service LSPs.

It should be noted that if the ODUk transport LSP provides switching of multiple types of ODUj service LSPs, then there may be multiple sets of intermediate switching stage LSPs, one for each different type of ODUj service LSP.

Finally, the term 'stacked hierarchical LSP' refers to an ODUk transport LSP and one or more sets of intermediate switching stage LSPs.  This construct has the interesting property that the endpoints of the ODUk transport LSP and the endpoints of the intermediate switching stage LSPs are congruent.

Thanks,

John

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 8 Jul 2011 09:08:00 +0200

Hello John.

SNIP:

" JD:  Would you please give me a brief description of what you mean by 'restoration' in the above text and how you think it will be accomplished using GMPLS signaling?  We have gone around on this multiple times and I think either one or both of us is confused."

In transport, we distinguish between protection and restoration.
Protection is always based on data-plane mechanisms. An example is 1+1 protection where CP signals protection set-up and changes of states
but the switch is usually performed by dataplane depending from OAM.

For LSP reroute, either pre-computed or on the fly when detecting an alarm.
LSP reroute is always performed via GMPLS signaling.

Note that the two mechanisms (protection and restoration) can be combined together in order to achieve speed (from protection) and efficiency in resource allocation (from restoration).  
You can find some restoration schemas in RFC 4427.
The analysis of mechanisms is in RFC 4428.
These originated RFC 4872 and RFC 4873.
Note that GMPLS restoration is in field in our transport networks since at least 10 years even if the RFCs are more recent.

How is this connected to the two mechanism:

In the case of all H-LSP the intermediate stages have associated an LSP and a logical interface. It is possible to re-route the  intermediate LSPs without re-signaling ODUjs. 
This feature MUST be supported in OTN networks as explicitly allowed by OTN architecture.

In the case of multi-stage label only ODUj can be rerouted.

So when using one mechanism or the other the operator is making a choice.

The first mechanism has to be used if the intermediate stage has to be restored. The fact that in some case the intermediate stage is single hop
is not meaningful.
Note that the multi-stage label mechanism also prevents setting up 1+1
protections on intermediate stages via control plane.    

Control plane simply cannot take the responsibility to operate such choices.

Hope this clarifies.

Pietro

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: giovedì 7 luglio 2011 21.31
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Sent from my iPhone

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 8 Jul 2011 11:04:07 +0200

Hello John

Snip: " Bandwidth accounting is the same with either method.  Per Section 6.3 of RFC 4206 and as I stated in my previous email, the intermediate switching stages inherit the holding priority of the ODUj service LSP.  More importantly, the containing hierarchical ODUk transport LSP also inherits the ODUj holding priority."

I did not remember that section. The bandwidth accounting point is closed.

Pietro

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: giovedì 7 luglio 2011 21.31
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 06:04:22 -0700

Pietro,

I actually had a faint hope that you would tell me something I did not already know.

You assert that when an intermediate switching stage LSP fails at one of its endpoints, re-signaling that LSP will facilitate that endpoint's re-establishment of that LSP.  You haven't said how and I don't believe this makes any sense.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 08, 2011 12:08 AM
> To: John E Drake; 'CCAMP'
> " JD:  Would you please give me a brief description of what you mean by
> 'restoration' in the above text and how you think it will be
> accomplished using GMPLS signaling?  We have gone around on this
> multiple times and I think either one or both of us is confused."
>
> Protection is always based on data-plane mechanisms. An example is 1+1
> protection where CP signals protection set-up and changes of states
> Note that the two mechanisms (protection and restoration) can be
> combined together in order to achieve speed (from protection) and
> efficiency in resource allocation (from restoration).
> Note that GMPLS restoration is in field in our transport networks since
> at least 10 years even if the RFCs are more recent.
>
> In the case of all H-LSP the intermediate stages have associated an LSP
> and a logical interface. It is possible to re-route the  intermediate
> LSPs without re-signaling ODUjs.
> The first mechanism has to be used if the intermediate stage has to be
> restored. The fact that in some case the intermediate stage is single
> hop
> is not meaningful.
> > is the intermediate stage to be allocated. This independently from
> the
> > way
> JD:  The capabilities are exactly the same whether the intermediate
> switching stages are established with a set of sequential Path messages
> (method 1) or with multi-stage labels (method 2)
>
> > So the operator must have an explicit way to choose not to make use
> of
> > multi-stage label.
> >
>
> JD:  Would you please give me a brief description of what you mean by
> 'restoration' in the above text and how you think it will be
> accomplished using GMPLS signaling?  We have gone around on this
> multiple times and I think either one or both of us is confused.
>
> >
> JD:  Bandwidth accounting is the same with either method.  Per Section
> 6.3 of RFC 4206 and as I stated in my previous email,
> the intermediate switching stages inherit the holding priority of the
> ODUj service LSP.  More importantly, the containing hierarchical ODUk
> transport LSP also inherits the ODUj holding priority.
>
> >
> JD:  For your example, above, we would advertise the bandwidth
> available for the ODUj (= ODU1) service LSPs and the underlying ODUK (=
> ODU3) transport LSP bandwidth.  We would not be advertising the
> intermediate switching stage (= ODU2) bandwidth.  As I originally
> wrote, above, it is the ODUj LSPs that would be pre-empted.
>
> >
> JD:  The issue I with which I am most concerned is that in signaling
> the endpoint addresses of an intermediate switching stage LSP are also
> the addresses of the containing hierarchical LSP.  Even if this is
> allowed in RFC 6107, I am not sure that implementations would allow
> this.
>
> We will also need to define some new flags in the RFC 6107 objects to
> indicate that the LSP being signaled is an intermediate switching stage
> LSP.
>
> And as I mentioned, above, in my previous email, I think we also need
> to indicate that the set-up and holding priorities in the signaling
> message for an intermediate switching stage LSP are meaningless.
>
> >
> JD:  Either the node that experiences the failure can fix it
> transparently or it can't.  If it can, then nothing is externally
> visible.  If it can't, it should indicate that the affected ODUJ
> service LSPs have failed.
>
> JD:  Let me try again.  Our new construct is what I am terming a
> 'stacked hierarchical LSP' which consists of a containing hierarchical
> LSP (the ODUk transport LSP) and a set of one or more intermediate
> switching stage LSPs, where the endpoints of both the containing
> hierarchical LSP and the intermediate switching stage LSPs are
> congruent.
>

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 8 Jul 2011 15:22:23 +0200

John,
I am sorry and I am really frustrated by the fact that I cannot find a way to make you understand that having the possibility to restore via GMPLS an intermediate layer without re-signaling all clients is a OTN networks requirement. Not fulfilling it is unacceptable because forces operators to
perform choices they may not want to do.

The multi-stage label solution, while being consistent, does not solve this specific problem, because it requires that intermediate stages are not visible at all, while instead the requirement for OTN networks is that intermediate stages are visible and fully manageable.

Let me say that all of us would like to have just one mechanism, unfortunately in reality we cannot.

Pietro

P.S.
SNIP "You assert that when an intermediate switching stage LSP fails at one of its endpoints, re-signaling that LSP will facilitate that endpoint's re-establishment of that LSP.  You haven't said how and I don't believe this makes any sense."

John, I will try to explain: A transport network element is built as a set of matrixes (one per layer), this means that each layer is cross connectable in an independent way. So each intermediate layer behaves exactly as the ODUj. Consequence: Intermediate stages can be rerouted. Grooming works in this way, just to make a practical example.

Grooming is usual practice in transport networks.

Pietro

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: venerdì 8 luglio 2011 15.04
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Pietro,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 07:22:02 -0700

Pietro,

Just to be clear, are we discussing the case of a stacked hierarchical LSP in which an intermediate switching stage LSP has failed at one of its endpoints?

How does re-signaling that LSP between the two endpoints of the ODUk transport LSP help the endpoint at which the intermediate switching stage LSP has failed to re-establish that LSP?

You have asserted that re-signaling helps and I just do not see how; the re-routing that you mention in your P.S. is strictly internal to node containing the endpoint of the failed intermediate switching stage LSP and that node does not require re-signaling from the other endpoint in order to internally re-route the failed LSP.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 08, 2011 6:22 AM
> I am sorry and I am really frustrated by the fact that I cannot find a
> way to make you understand that having the possibility to restore via
> GMPLS an intermediate layer without re-signaling all clients is a OTN
> networks requirement. Not fulfilling it is unacceptable because forces
> operators to
> The multi-stage label solution, while being consistent, does not solve
> this specific problem, because it requires that intermediate stages are
> not visible at all, while instead the requirement for OTN networks is
> that intermediate stages are visible and fully manageable.
>
> SNIP "You assert that when an intermediate switching stage LSP fails at
> one of its endpoints, re-signaling that LSP will facilitate that
> endpoint's re-establishment of that LSP.  You haven't said how and I
> don't believe this makes any sense."
>
> John, I will try to explain: A transport network element is built as a
> set of matrixes (one per layer), this means that each layer is cross
> connectable in an independent way. So each intermediate layer behaves
> exactly as the ODUj. Consequence: Intermediate stages can be rerouted.
> Grooming works in this way, just to make a practical example.
>
> You assert that when an intermediate switching stage LSP fails at one
> of its endpoints, re-signaling that LSP will facilitate that endpoint's
> re-establishment of that LSP.  You haven't said how and I don't believe
> this makes any sense.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
> > This feature MUST be supported in OTN networks as explicitly allowed
> by
> > OTN architecture.
> >
> > > multi-stage label since day one. (and even no reason to implement
> it
> > > until
> > > > The second method would allow the labels for the hierarchical
> ODU2
> > > LSP
> > > > completely transparent because bandwidth accounting and
> restoration
> > > are
> > > > impacting on it.
> > >
> > > and holding priorities between the intermediate switching stage
> LSPs
> > as
> > > > which of the two methods is used to establish the sub-layer LSPs
> it
> > > has
> > > two boards, so the alarm situation is very different. The fact that
> a
> > > node
> > > > 4)  Existing network management applications do not understand
> this
> > > > construct.
> > > >
> > > multi-technology (they support PDH,WDM etc... managing them with
> SDH
> > as
> > > a whole).
> >
> > > there is no need to perform any check because they can be applied
> in
> > > any condition.
> >

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 8 Jul 2011 16:55:05 +0200

Pietro,

[[PG]] I am speaking about a functionality: grooming, not about a specific case. When grooming traffic, the ODU used for grooming has to be rerouted.
It is not important if the ODU containing groomed traffic has been created single hop or not.
An operator may be willing to protect this grooming ODU (incidentally created single hop)via for instance a 1+1 protection (implies internal protection) and in addition use also restoration in order to survive to a higher number of faults.

With multi stage label approach  how it is possible to do this functionality ?

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 08:06:06 -0700

Pietro,

I don't think you responded to my question which was regarding a 'specific problem' that you raised in your email to me, below.

Wrt to point you raised in your reply, an intermediate switching stage LSP is bound to the ODUk transport LSP in which it was established.  I don't see how it can be independently re-routed.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 08, 2011 7:55 AM
> Just to be clear, are we discussing the case of a stacked hierarchical
> LSP in which an intermediate switching stage LSP has failed at one of
> its endpoints?
>
> How does re-signaling that LSP between the two endpoints of the ODUk
> transport LSP help the endpoint at which the intermediate switching
> stage LSP has failed to re-establish that LSP?
>
> You have asserted that re-signaling helps and I just do not see how;
> the re-routing that you mention in your P.S. is strictly internal to
> node containing the endpoint of the failed intermediate switching stage
> LSP and that node does not require re-signaling from the other endpoint
> in order to internally re-route the failed LSP.
>
> [[PG]] I am speaking about a functionality: grooming, not about a
> specific case. When grooming traffic, the ODU used for grooming has to
> be rerouted.
> An operator may be willing to protect this grooming ODU (incidentally
> created single hop)via for instance a 1+1 protection (implies internal
> protection) and in addition use also restoration in order to survive to
> a higher number of faults.
>
> > I actually had a faint hope that you would tell me something I did
> not
> > already know.
> >
> > > " JD:  Would you please give me a brief description of what you
> mean
> > by
> > > For LSP reroute, either pre-computed or on the fly when detecting
> an
> > > alarm.
> > > > Personally, I do not believe that in presence of any HW
> flexibility
> > > an
> > > > > ODU2 LSP to be implicitly established during the signaling of
> an
> > > ODU1
> > > > > LSP.
> > > > >
> > > > introduces a number of error cases involving a mismatch in the
> set-
> > up
> > > > These error cases and their ramifications would need to be
> analyzed
> > > and
> > > > addressed.
> > > >
> > > > of all upper layers accordingly to the priority of the
> intermediate
> > > > stage.
> > > > So if intermediate stage is allocated at priority 5, we simply
> have
> > > to
> > > > subtract from upper layers resources from priority 1 to 4, so
> that
> > > high
> > > > changes dynamically dependently from the priorities of the
> clients
> > > and
> > > > Take the usual example of ODU1-ODU2-ODU3  when we are restoring
> an
> > > ODU2
> > > available for the ODUj (= ODU1) service LSPs and the underlying
> ODUK
> > (=
> > > > intermediate stages that are believed pre-emptable suddenly are
> no
> > > more
> > > > > just the currently standardized H-LSP with FA creation support
> (I
> > > > mean
> > > > support them both from an architecture and development
> perspective
> > is
> > > > under discussion
> > > >
> > > > [[PG]]
> > > It is congruency that is new, and as I indicated above, I have a
> few
> > > concerns about it.
> > >

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 8 Jul 2011 10:28:38 -0500

Hi John and Pietro,

I'm not certain I understand the concept of the lower-layer ODU inheriting the holding priority of the service LSP.  Let me start with some clarifying questions:

1. Holding priority is used when performing CAC to determine if an new LSP should preempt an existing LSP, correct?
2. When preemption occurs, the existing LSP is released (graceful or otherwise) by the node where the preemption occurs.  This would release the service ODU and lower-layer ODU, correct?
3. Two different service LSPs may be signaled with different holding priorities but use the same lower-layer ODU to carry the service LSP, correct?

Now, in the scenario where an lower-layer ODU data-plane link connection has been established to support two different service LSPs and the service LSPs have different holding priorities, what would be the preemption policy for the lower layer ODU?

A more concrete example:

  ---A---B---

AB = ODU2 link without direct ODU0 support

1) On AB, LSP1 requests an ODU0 with holding priority = 5.  This is satisfied by creating an ODU1 link-connection on the ODU2.  My interpretation of your statement is the holding priority of the ODU1 would be 5.  LSP1 doesn't completely allocate the ODU1, leaving an ODU0 available.
2) On AB, three LSPs (LSP2, LSP3, LSP4) request additional ODU1s, filling up the ODU2.  These LSPs are also signaled with holding priority=3.
3) On AB, LSP5 requests an ODU0.  LSP5 is signaled with holding priority = 3.

Will LSP5 be:
 a) admitted using the spare ODU0 in the ODU1 link-connection created by LSP1?
 b) admitted preempting LSP1?
 c) refused since an ODU1 created by LSP1 is for priority = 5?

If it is admitted On AB, what happens when LSP6 requests on AB an ODU1 with holding priority = 4?

Thanks,

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Friday, July 08, 2011 4:04 AM
To: John E Drake; 'CCAMP'
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Hello John

Pietro

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: giovedì 7 luglio 2011 21.31
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 08:59:42 -0700

Jonathan,

Comments inline.

John

Sent from my iPhone

> Sent: Friday, July 08, 2011 8:29 AM
> To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); John E Drake; 'CCAMP'
> I'm not certain I understand the concept of the lower-layer ODU
> inheriting the holding priority of the service LSP.

JD:

"6.3.  FA-LSP Holding Priority

   The value of the holding priority of an FA-LSP must be the minimum of
   the configured holding priority of the FA-LSP and the holding
   priorities of the LSPs tunneling through the FA-LSP (note that
   smaller priority values denote higher priority).  Thus, if an LSP of
   higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
   LSP is itself promoted to the higher priority.  However, if the
   tunneled LSP is torn down, the FA-LSP need not drop its priority to
   its old value right away; it may be advisable to apply hysteresis in
   this case.

   If the holding priority of an FA-LSP is configured, this document
   restricts it to 0."

> Let me start with
> some clarifying questions:
>
> 1. Holding priority is used when performing CAC to determine if an new
> LSP should preempt an existing LSP, correct?

JD:  Correct

> 2. When preemption occurs, the existing LSP is released (graceful or
> otherwise) by the node where the preemption occurs.  This would release
> the service ODU and lower-layer ODU, correct?

JD:  The lower layer ODU would not necessarily be released

> 3. Two different service LSPs may be signaled with different holding
> priorities but use the same lower-layer ODU to carry the service LSP,
> correct?

JD:  Correct

>
> Now, in the scenario where an lower-layer ODU data-plane link
> connection has been established to support two different service LSPs
> and the service LSPs have different holding priorities, what would be
> the preemption policy for the lower layer ODU?
>
> A more concrete example:
>
>   ---A---B---
>
> 1) On AB, LSP1 requests an ODU0 with holding priority = 5.  This is
> satisfied by creating an ODU1 link-connection on the ODU2.  My
> interpretation of your statement is the holding priority of the ODU1
> would be 5.  LSP1 doesn't completely allocate the ODU1, leaving an ODU0
> available.

JD:  Let's call this ODU1 LSP0

> 2) On AB, three LSPs (LSP2, LSP3, LSP4) request additional ODU1s,
> filling up the ODU2.  These LSPs are also signaled with holding
> priority=3.

JD:  So we have four ODU1s, LSP0 at priority 5, and LSP2, 3, & 4 at priority 3

>  c) refused since an ODU1 created by LSP1 is for priority = 5?

JD:  LSP5 can be signaled in LSP0, 2, 3, or 4.  If it is signaled in LSP0, LSP1 would not be pre-empted since there is capacity for LSP5 within it, and LSP0's priority jumps to 3

> with holding priority = 4?

JD: Which of the four ODU1 LSPs is specified in the signaling of LSP6?

> Snip: " Bandwidth accounting is the same with either method.  Per
> Section 6.3 of RFC 4206 and as I stated in my previous email, the
> intermediate switching stages inherit the holding priority of the ODUj
> service LSP.  More importantly, the containing hierarchical ODUk
> transport LSP also inherits the ODUj holding priority."
>

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 09:13:40 -0700

Jonathan,

Oops, I misread your last question.  If LSP5 was signaled in LSP0, then LSP0's priority is 3 and LSP 6 would be rejected. If LSP5 was signaled in LSP 2, 3, or 4, then LSP0's priority is 5 and LSP6 would pre-empt it.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 08, 2011 9:00 AM
> To: 'Sadler, Jonathan B.'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
> 'CCAMP'
> JD:  LSP5 can be signaled in LSP0, 2, 3, or 4.  If it is signaled in
> LSP0, LSP1 would not be pre-empted since there is capacity for LSP5
> within it, and LSP0's priority jumps to 3
>
> >
> > If it is admitted On AB, what happens when LSP6 requests on AB an
> ODU1
> > with holding priority = 4?
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Jul 2011 12:54:25 -0400

John,
	Thanks for clarifying.  I propose some alternate terminology at the end
of this mail.

On 7/7/2011 4:13 PM, John E Drake wrote:
> JD:  We first signal a containing hierarchical LSP.  (I use the term
> 'containing' simply to indicate that everything else is contained
> within it.)  This is the ODUk transport LSP the endpoints of which
> have an RSVP signaling adjacency used to establish ODUj service LSPs
> which transit it.
> 

Okay.  So this is just an H-LSP, right?

Whether this H-LSP is an FA or not, it is available to higher levels of
the hierarchy/signaling as an interface/RSVP hop.

Note, you have introduced another term here "ODUk transport LSP" which I
think you are using to refer to an H-LSP which uses an ODU switching type.

> If j < k - 1, the ODUk transport LSP is performing multi-stage
> switching, e.g., ODU1 <-> ODU2 <-> ODU3 (where right arrows indicate
> multiplexing and left arrows indicate de-multiplexing), and
> hierarchical LSPs need to be established for the intermediate
> switching stages.  I use the term 'intermediate switching stage LSP'
> to describe such an LSP, which in this example is the ODU2 LSP.
> 
> 'Sequential hierarchical LSPs' is the term used to indicate that the
> intermediate switching stage LSPs are explicitly established to
> complete the OTN multi-stage switching path between the ODUj service
> LSPs and the ODUk transport LSP.  

In other words a standard hierarchy/H-LSP. Right?

Again, in this case, each lower level of the hierarchy is available to
is available to higher levels of the hierarchy/signaling as an
interface/RSVP hop.

> 'Multi-stage labels' is the term
> used to indicate that the intermediate switching stage LSPs are
> implicitly established as part of the establishment of select ODUj
> service LSPs.

Well this term implies a particular (and contentious) solution.  I think
we should avoid the 'Multi-stage label' term when discussing
requirements or general function, and not that particular solution.

How about implicit-sub-level LSP, or implicit-link LSP?

> 
> It should be noted that if the ODUk transport LSP provides switching
> of multiple types of ODUj service LSPs, then there may be multiple
> sets of intermediate switching stage LSPs, 

sigh, yet a new term 'intermediate switching stage LSPs' is this the
same as 'Sequential hierarchical LSPs' or the 'intermediate switching
stage LSPs [that] are implicitly established'?  I suspect the latter.
How about 'implicitly established H-LSPs' or 'implicit H-LSPs' for short?

> one for each different type of ODUj service LSP.

and one more 'ODUj service LSP'; which is nothing more than a standard
LSP that uses implicit sub-levels/links, or an 'implicit-link LSP'.

> 
> Finally, the term 'stacked hierarchical LSP' refers to an ODUk
> transport LSP and one or more sets of intermediate switching stage
> LSPs.  This construct has the interesting property that the endpoints
> of the ODUk transport LSP and the endpoints of the intermediate
> switching stage LSPs are congruent.
> 

so 'stacked hierarchical LSP' = 'standard H-LSPs' + 'implicit H-LSPs'

> John

How about we use the following terminology based on the existing H-LSP
and link terminology and the (new) concept of *implicit* links and H-LSPs.

1) "implicit-link"
   An implicit link is a logical entity that matches a (sup)layer
   (stage) in the data plane hierarchy, and which is established as
   result of control or management plane actions at a different layer
   (stage) in the data plane hierarchy. (Recall that a GMPLS/MPLS link
   may be a physical interface or provided by an H-LSP.)

2) "implicit-link LSP"
   This is an LSP that uses an implicit-link.  Note that the
   implicit-link might not exist before the LSP is signaled.

3) "implicit H-LSP" (or implicitly established H-LSP)
   The H-LSP that is not directly signaled/managed and corresponds to
   an implicit-link.  Such an H-LSP is created as a result of the
   signaling/managment of an LSP that uses an implicit link.

Comments?

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 14:21:30 -0700

Snipped, comments inline

Sent from my iPhone

JD:  Correct

> think you are using to refer to an H-LSP which uses an ODU switching

JD: Correct, it seemed that some folks liked this term better

> In other words a standard hierarchy/H-LSP. Right?

JD:  It's one proposed method of establishing the intermediate LSPs

> requirements or general function, and not that particular solution.

JD:  It's the other proposed method of establishing the intermediate LSPs

> How about implicit-sub-level LSP, or implicit-link LSP?

JD:  I started with the term 'sub-layer LSP' but this perturbed some of the folks that attend the ITU

> How about 'implicitly established H-LSPs' or 'implicit H-LSPs' for

JD:  'Intermediate switching stage LSP' is one of the intermediate hierarchical LSPs between the ODUk transport LSP and the ODUj service LSP.
> LSP that uses implicit sub-levels/links, or an 'implicit-link LSP'.

JD: For example, let's have an ODUk transport LSP which is an ODU4 which supports ODU0 <-> ODU1 <-> ODU2 <-> ODU4 and ODU1 <-> ODU3 <-> ODU4.  

The two types of ODUj service LSPs are ODU0 and ODU1.  The set of intermediate switching stage LSPs for the former type would be [ODU1, ODU2] and the set of intermediate switching stage LSPs for the latter type would be {ODU3]

JD:  Correct

>    signaling/managment of an LSP that uses an implicit link.

JD:  1) is what I was calling an intermediate switching stage LSP and 2) is what I was calling an OUDj service LSP?

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Jul 2011 20:27:32 -0400

On 7/8/2011 5:21 PM, John E Drake wrote:
...
> JD: 1) is what I was calling an intermediate switching stage LSP and
Given that 1 is a "logical entity", I suspect you mean (and I agree)
that 3) is whay you were calling an intermediate switching stage LSP.

> 2) is what I was calling an OUDj service LSP?

agreed.

So this leaves us with 4 types of LSPs.

(old) LSPs
      LSPs that use explicit links
(old) H-LSPs
      LSPs that provide links to higher layers and are
      explicitly controlled

(new) Implicit H-LSP
      LSPs that provide links to higher layers and are
      controlled via implicit mechanisms
(new) implicit-link LSP
      LSPs that use / trigger Implicit H-LSPs

Comments?

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 11 Jul 2011 14:36:41 +0800

Hi John,

What is the answer to Igor's question?

Thanks
 
Fatai

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

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
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,

Thanks,

John

Sent from my iPhone

> > m.cn

---

From: John E Drake <[email-masked]>
Date: Mon, 11 Jul 2011 04:04:10 -0700

Igor,

Comments inline.

Thanks,

John

Sent from my iPhone

JD:  Certainly not

Sent from my iPhone

> Sent: Sunday, July 10, 2011 11:37 PM
> To: 'Igor Bryskin'; John E Drake; 'Sadler, Jonathan B.'; 'Lou Berger'
> Cc: 'CCAMP'
> Of Igor Bryskin

---

From: [email-masked]
Date: Mon, 11 Jul 2011 20:59:38 +0800

Hi John, 

When we are talking about the preemption, we should refer to rfc3209
"
      Setup Priority

         The priority of the session with respect to taking resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         The Setup Priority is used in deciding whether this session can
         preempt another session.

      Holding Priority

         The priority of the session with respect to holding resources,
         in the range of 0 to 7.  The value 0 is the highest priority.
         Holding Priority is used in deciding whether this session can
         be preempted by another session.
"
Suppose LSP5 (i.e., ODU0 LSP) has been over LSP2, LSP3 or LSP4.
When LSP6 requests on AB an ODU1, we should compare the set up priority of 
LSP6 (i.e., set up priority = 4 ) with the holding priority of LSP0 (i.e., 
holding priority = 5). So LSP6 can preempt LSP0.

Xihua

John E Drake <[email-masked]> 
发件人:  [email-masked]
2011-07-09 上午 12:13

收件人
John E Drake <[email-masked]>, "Sadler, Jonathan B." 
<[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
<[email-masked]>, 'CCAMP' <[email-masked]>
抄送

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

Jonathan,

Oops, I misread your last question.  If LSP5 was signaled in LSP0, then 
LSP0's priority is 3 and LSP 6 would be rejected. If LSP5 was signaled in 
LSP 2, 3, or 4, then LSP0's priority is 5 and LSP6 would pre-empt it.

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 11 Jul 2011 06:35:51 -0700

Is this not exactly what I said in my third sentence?

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 11, 2011 6:00 AM
To: John E Drake
Cc: 'CCAMP'; [email-masked]; John E Drake; Sadler, Jonathan B.; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: Re: [CCAMP] RSVP OTN single stage vs multi stage

Hi John,

      Holding Priority

When LSP6 requests on AB an ODU1, we should compare the set up priority of LSP6 (i.e., set up priority = 4 ) with the holding priority of LSP0 (i.e., holding priority = 5). So LSP6 can preempt LSP0.

Xihua

2011-07-09 上午 12:13

收件人

John E Drake <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>, 'CCAMP' <[email-masked]>

抄送

主题

Jonathan,

Thanks,

John

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 12 Jul 2011 14:02:45 +0800

Hi John,

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

JD:  Certainly not

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

> of these ODU1s can reference that ODU2.

Sent from my iPhone

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

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

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

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

> > intermediate stage switching LSPs?

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

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

> > past

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

> discussion

> > > >> On Jul 3, 2011, at 11:49 AM, "Lou Berger" <[email-masked]>

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

> > paragraph.

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

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

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

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

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

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

> LSP).

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

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

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

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

> > unified

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

> > > >>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>> [mailto:[email-masked]]>

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

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

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

> > links,

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

> > multipl

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

> > > because

> > > >>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>> [mailto:[email-masked]]>

> > > >>>> From: Fatai Zhang [mailto:[email-masked]]<mailto:

> > > >>>> [mailto:[email-masked]]>

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

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

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

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

> > you

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

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

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

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

> > thought.

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

> holds

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

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

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

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

> > > >>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>> [mailto:[email-masked]]>

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

> > > >>>> ode B

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

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

> > > >>>> From: Fatai Zhang [mailto:[email-masked]]<mailto:

> > > >>>> [mailto:[email-masked]]>

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

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

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

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

> > LSPs,

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

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

> > certainly

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

> > would

> > > >>>>> From: Igor Bryskin [mailto:[email-masked]]<mailto:

> > > >>>>> [mailto:[email-masked]]>

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

> > > >>>>> sufficient a

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

> > > >>>>> control the

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

> > > >>>>> private

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

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

> > > >>>>> deliberate

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

> > > >>>>> motivation as

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

> > LSP,

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

> > > found

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

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

> > minute.

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

> > > Jonathan

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

> Kunjidhapatham;

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

> > Ceccarelli

> > > >>>>>> From: Fatai Zhang [mailto:[email-masked]]<mailto:

> > > >>>>>> [mailto:[email-masked]]>

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

> > > >>>>>> Jonathan

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

> Kunjidhapatham;

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

> > Ceccarelli

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

> > > >>>>> think the

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

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

> > blue

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

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

> > > >>>>>> and D

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

> > > simply

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

> <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]

> > > t

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

> > > ericsson.com

> <<mailto:[email-masked]>[email-masked]<mailto:zhangfatai@

> > > huawei.com

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

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

> > > >>>>>> lucent.com<mailto:[email-masked]>>;

> "Ashok

> ailto:[email-masked]>[email-masked]<mailto:

> > > [email-masked]

> ailto:[email-masked]>[email-masked]<mailto:di

> > > [email-masked]

> <<mailto:[email-masked]>[email-masked]<mailto:S

> > > [email-masked]

> <<mailto:[email-masked]>[email-masked]<mailto:cyril.mar

> > > [email-masked]

> metaswitch.com>[email-masked]<mailto:Jonathan.Hardwic

> > > [email-masked]

> ailto:[email-masked]>[email-masked]<mailto:jo

> > > [email-masked]

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

> > establishment

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

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

> established

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

> > ODUj.

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

> > > >>>>>> signaling is

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

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

> > Caviglia;

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

> > something

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

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

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

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

> > > minute.

> > > >>>>>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>>>>> [mailto:[email-masked]]>

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

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

> > Caviglia;

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

> > ill-

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

> > > signaling

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

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

> > > lucent.com

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

> > > >>>>>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>>>>> [mailto:[email-masked]]>

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

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

> Jonathan

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

> > means

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

> Zhang;

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

> > Diego

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

> Jonathan

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

> > > >>>>>>> implicit

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

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

> lucent.com>

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

> > > lucent.com

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

> > > minute.

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

> > VITTORIO

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

> > Ong';

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

> Jonathan

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

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

> > > told

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

> > backward

> > > >>>>>>> From: John E Drake [mailto:[email-masked]]<mailto:

> > > >>>>>>> [mailto:[email-masked]]>

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

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

> > > Caviglia;

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

> Jonathan

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

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

> > > >>>>>>> From: Rajan Rao [mailto:[email-masked]]<mailto:

> > > >>>>>>> [mailto:[email-masked]]>

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

> > > Caviglia;

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

> Jonathan

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

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

> > indicate

---

From: John E Drake <[email-masked]>
Date: Tue, 12 Jul 2011 11:43:30 -0700

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.

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.

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

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

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
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,

JD:  Certainly not

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 13 Jul 2011 10:00:14 +0800

Hi John,

Please see in-line.

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

Thanks
 
Fatai

Sent: 2011年7月13日 2:44

Fatai,

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

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

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

[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

Hi John,

JD:  Certainly not

 

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Tue, 12 Jul 2011 20:13:36 -0700

Snipped, comments inline

Sent from my iPhone

JD:  That’s always an option

===============================================================================================================================

JD:  There have been repeated assertions that this is necessary, but no one has defined what this means or how GMPLS would be used to accomplish it.

I.e., how can you re-route an LSP whose endpoints and path are fixed?

===============================================================================================================================

JD:  There are only two cases, multistage switching across links and multistage switching across hierarchical LSPs.  I thought we had all agreed the former was unlikely in real deployments.  If you are now going to tell me it will be common, then the case for multi-stage labels becomes stronger because having a plethora  of hierarchical one hop LSPs has really bad scaling properties.

================================================================================================================================

JD:  This is all fine but what does it have to do with multi-stage switching?

================================================================================================================================

JD:  Transient endpoint failure/restoration of an intermediate LSP was  the specific failure condition that Pietro brought up last week.  I don’t understand what your second sentence has to do with this.

---

From: [email-masked]
Date: Wed, 13 Jul 2011 11:17:06 +0800

Hi John,

What you have said is correct.
I am wondering if it is enough for us to just use holding priority to 
describe the example.
I may prefer following description of example from Jonathan.
Note that the value of set up priority could be identical to holding 
priority.

"
...

A more concrete example:

---A---B---

1) On AB, LSP1 requests an ODU0 with holding priority = 5.  This is
satisfied by creating an ODU1 link-connection on the ODU2.  My
interpretation of your statement is the holding priority of the ODU1
would be 5.  LSP1 doesn't completely allocate the ODU1, leaving an
ODU0 available.

JD:  So we have four ODU1s, LSP0 at priority 5, and LSP2, 3, & 4 at
priority 3

3) On AB, LSP5 requests an ODU0.  LSP5 is signaled with holding priority = 
3.

Will LSP5 be:
a) admitted using the spare ODU0 in the ODU1 link-connection created by 
LSP1?
b) admitted preempting LSP1?
c) refused since an ODU1 created by LSP1 is for priority = 5?

If it is admitted On AB, what happens when LSP6 requests on AB an ODU1
with set up priority = 4?
"

Suppose LSP5 (i.e., ODU0) is over LSP2, LSP3 or LSP4 (i.e., ODU1), the 
holding priority value of LSP0 is still 5.

So when LSP6 requests on AB an ODU1 with set up priority = 4, it could 
preempt LSP0 because the set up priority of LSP6 is larger than the 
holding priority of LSP0.

Xihua

2011-07-11 下午 09:35

收件人
"[email-masked]" <[email-masked]>
抄送
'CCAMP' <[email-masked]>, "[email-masked]" 
<[email-masked]>, "Sadler, Jonathan B." 
<[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
<[email-masked]>
主题
RE: Re: [CCAMP] RSVP OTN single stage vs multi stage

Sent from my iPhone
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 11, 2011 6:00 AM
To: John E Drake
Cc: 'CCAMP'; [email-masked]; John E Drake; Sadler, Jonathan B.; 
GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: Re: [CCAMP] RSVP OTN single stage vs multi stage

Hi John, 

      Holding Priority 

Xihua 

收件人

主题

Jonathan,

Thanks,

John

Sent from my iPhone

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 13 Jul 2011 12:20:47 +0200

John,

during the last 80th IETF in Prague, we had a lot of discussion ,particularly with Rao and Khuzema , about the need to advertise BW also for intermediate level of an OTN multiplexing hierarchy.
At the end they convinced me and Daniele of the need to have the possibility to provide information on how many FAs can be setup. I remember some scenarios in which these FAs are used not only specifically in a single pont to point link (for as you named containing LSP scope) but also by potentially other LSPs .
We in fact ad a note in the actual uploaded routing draft to mention the need for intermediate BW adevertisement.

So , unless scenarios are changed , what Fatai is trying to make understandable (and Pietro as well) is the fact that these intermediate layer exists in data plane , and must exist also at CP level .
Implicit option as you want does not permit any choice to use these FAs to be used only iin the containing LSP context but for example not use by another service to re-route traffic using them.

Thanks

Besr Regards

Sergio

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 12 luglio 2011 20.44
A: Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Cc: 'CCAMP'
Oggetto: Re: [CCAMP] RSVP OTN single stage vs multi stage

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

JD:  Certainly not

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: Rajan Rao <[email-masked]>
Date: Wed, 13 Jul 2011 13:22:20 +0000

Lou,

The 4th LSP type (implicit-link LSP) is not very clear. This seems to represent the service-LSP which induces implicit H-LSPs (type #3).  In which case this should be a regular LSP (type#1) capable of inducing type#3.

We would like to retain "implicit-link" definition you had in your email earlier. To clarify, the "implicit-link" can have data plane representation with or without control plane representation (LSP).
In case of no control plane representation, the bandwidth of implicit-link is managed on the parent Te-Link.

The definition of "implicit-link" is same as you had before as follows:

"
1) "implicit-link"
   An implicit link is a logical entity that matches a (sup)layer
   (stage) in the data plane hierarchy, and which is established as
   result of control or management plane actions at a different layer
   (stage) in the data plane hierarchy. (Recall that a GMPLS/MPLS link may be a physical interface or provided by an H-LSP.)
"

To clarify, the multi-stage label proposed in draft-khuzema refers to "implicit-link" creation without implicit H-LSPs.

Thanks
Rajan, Ashok & Khuzema.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, July 09, 2011 5:58 AM
To: John E Drake
Cc: CCAMP
Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi stage)

agreed.

(old) LSPs

(new) Implicit H-LSP

Comments?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Jul 2011 07:54:41 -0700

Rajan,
	See below for in-line responses.

On 7/13/2011 6:22 AM, Rajan Rao wrote:
> Lou,
> 
> The 4th LSP type (implicit-link LSP) is not very clear. This seems
> to represent the service-LSP which induces implicit H-LSPs (type #3). In
> which case this should be a regular LSP (type#1) capable of inducing type#3.

Well, in *theory* I agree there should be minimal difference between a
regular LSP and an implicit (link) LSP.  I think the degree of
difference will come down to the specific mechanism we define.

At this stage, where we are still don't have consensus on requirements,
I think we need to differentiate the two.

> 
> We would like to retain "implicit-link" definition you had in your
> email earlier. To clarify, the "implicit-link" can have data plane
> representation with or without control plane representation (LSP).

If there is a one-to-one correspondence between the control plane and
the link, it is a standard H-LSP.

> In case of no control plane representation, the bandwidth of
> implicit-link is managed on the parent Te-Link.

And I was referring to the lower-level of the hierarchy in the
data-plane as an "implicit H-LSP"

Also, as has been highlighted by the other discussions, there's more to
consider than just bandwidth.

> To clarify, the multi-stage label proposed in draft-khuzema refers
> to "implicit-link" creation without implicit H-LSPs.
> 

I must not have been clear in my previous mail.  An "implicit-link" (as
defined) is just a logical entity, i.e., a concept. An "implicit H-LSP"
(as defined) refers to the level of the hierarchy in the data-plane that
instantiates an implicit-link.  So, using these terms, draft-khuzema
refers to implicit-links that result in implicit H-LSPs.

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Jul 2011 10:26:12 -0700

Sergio,

This capability and associated bandwidth should be advertised explicitly as a separate ODUj service LSP capability.

Thanks,

John

Sent from my iPhone

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 3:21 AM
To: John E Drake
Cc: 'CCAMP'; Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Subject: R: [CCAMP] RSVP OTN single stage vs multi stage

John,

Thanks

Besr Regards

Sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

JD:  Certainly not

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 13 Jul 2011 19:37:40 +0200

John,

could you clarify your statement  more explicitly ?  “This capability and associated bandwidth should be advertised explicitly as a separate ODUj service LSP capability”  this is not what is addressed now in the draft neither it  seems to me answering my question .

Thanks

sergio

________________________________
Da: John E Drake [mailto:[email-masked]]
Inviato: mercoledì 13 luglio 2011 19.26
A: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'; Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Oggetto: RE: [CCAMP] RSVP OTN single stage vs multi stage

Sergio,

Thanks,

John

Sent from my iPhone

John,

Thanks

Besr Regards

Sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

JD:  Certainly not

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Jul 2011 10:50:19 -0700

Sergio,

I may have misunderstood your email.

If we have an interface that supports ODU1 <-> ODU2 <-> ODU3, I thought you were saying that the ODU2 switching capability needed to be advertised so that ODU2 LSPs could be established using this interface.  What I was saying was that in addition to advertising the OD1 <-> ODU2 <-> ODU3 switching capability,  an ODU2 <-> ODU3 switching capability should also be advertised.

Thanks,

John

Sent from my iPhone

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 10:38 AM
To: John E Drake
Cc: 'CCAMP'; Fatai Zhang; 'Igor Bryskin'; 'Sadler, Jonathan B.'; 'Lou Berger'
Subject: R: [CCAMP] RSVP OTN single stage vs multi stage

John,

Thanks

sergio

Sergio,

Thanks,

John

Sent from my iPhone

John,

Thanks

Besr Regards

Sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

JD:  Certainly not

Thanks

Fatai

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

JD:  Certainly not

Sent from my iPhone

---

From: Rajan Rao <[email-masked]>
Date: Fri, 22 Jul 2011 00:45:34 +0000

Hi,

The use of "implicit H-LSP" could be problematic as far as use of explicit routing is concerned.  In explicit routing case we need a way to specify  origination point of implicit-HLSP(s), i.e. the ODU layer(s) and the time slots.

One way to specify the origination point in explicit route is to use a new label format which captures hierarchy details including time slots.  

The multi-stage label can be used to instantiate "implicit H-LSP(s)" optionally and to  address the above case.

Thanks
Rajan & Khuzema

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2011 7:55 AM
To: Rajan Rao
Cc: John E Drake; CCAMP; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Mohit Misra
Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi stage)

Rajan,

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Jul 2011 10:13:03 -0400

Guys,
	I'm sorry, I don't understand the point of your mail.

Is it:
1) definition related: to make a comment on the definition of "implicit
H-LSP"
2) requirements related: to highlight a new requirement/challenge
related to the control of "implicit H-LSPs" via "implicit-link LSPs"
3) solution related: to state a solution to a new requirement/challenge
related to the control of "implicit H-LSPs"
4) something else

BTW my intent on this particular thread was to keep the discussion
focused on definitions and requirements, not solutions.  We can move
onto solutions once we have agreement on terms and requirements.

Lou

On 7/21/2011 8:45 PM, Rajan Rao wrote:
> Hi,
> 
> The use of "implicit H-LSP" could be problematic as far as use of
> explicit routing is concerned.  In explicit routing case we need a
> way to specify  origination point of implicit-HLSP(s), i.e. the ODU
> layer(s) and the time slots.
> 
> One way to specify the origination point in explicit route is to use
> a new label format which captures hierarchy details including time
> slots.
> 
> The multi-stage label can be used to instantiate "implicit H-LSP(s)"
> optionally and to  address the above case.
> 
> Thanks
> Rajan & Khuzema
>

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 22 Jul 2011 23:22:06 +0000

Hi Lou,

We do want to highlight a new requirement (and a possible solution) regarding "how to control the origination point of implicit H-LSP" through ERO. Service layer LSP request should have an option to contain enough information to identify where the implicit LSP originating from and where it is terminating. This detail should include, for each layer, the Interface ID and OPU time slot  to complete the specification.

Thanks
Khuzema & Rajan

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, July 22, 2011 7:13 AM
To: Rajan Rao
Cc: John E Drake; CCAMP; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Mohit Misra
Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi stage)

Guys,

Is it:
1) definition related: to make a comment on the definition of "implicit H-LSP"
2) requirements related: to highlight a new requirement/challenge related to the control of "implicit H-LSPs" via "implicit-link LSPs"
3) solution related: to state a solution to a new requirement/challenge related to the control of "implicit H-LSPs"
4) something else

BTW my intent on this particular thread was to keep the discussion focused on definitions and requirements, not solutions.  We can move onto solutions once we have agreement on terms and requirements.

Lou

On 7/21/2011 8:45 PM, Rajan Rao wrote:
> explicit routing is concerned.  In explicit routing case we need a way 
> to specify  origination point of implicit-HLSP(s), i.e. the ODU
> One way to specify the origination point in explicit route is to use a 
> new label format which captures hierarchy details including time 
> slots.
> 
>> The 4th LSP type (implicit-link LSP) is not very clear. This seems to 
>> represent the service-LSP which induces implicit H-LSPs (type #3). In 
> At this stage, where we are still don't have consensus on 
> requirements, I think we need to differentiate the two.
> 
>>
> Also, as has been highlighted by the other discussions, there's more 
> to consider than just bandwidth.
> 
>>
>>
>>     may be a physical interface or provided by an H-LSP.) "
>>
>> To clarify, the multi-stage label proposed in draft-khuzema refers to 
>> "implicit-link" creation without implicit H-LSPs.
>>
> 
> (as defined) refers to the level of the hierarchy in the data-plane 
> that instantiates an implicit-link.  So, using these terms, 
> draft-khuzema refers to implicit-links that result in implicit H-LSPs.
> 
> Lou
> 
>> Thanks
>> Rajan, Ashok & Khuzema.
>>
>> Behalf Of Lou Berger
>>>> How about we use the following terminology based on the existing 
>>>> H-LSP and link terminology and the (new) concept of *implicit* 
>>>> links and H- LSPs.
>>>>
>>>> 1) "implicit-link"

---

From: [email-masked]
Date: Mon, 25 Jul 2011 07:03:50 +0800

Hi Khuzema,

For your idea, the requirement and solution have been described in our 
draft 
http://tools.ietf.org/html/draft-fuxh-ccamp-boundary-explicit-control-ext-03.
It isn't a new requirement. It has been raised for several meeting times.

Xihua

Khuzema Pithewan <[email-masked]> 
发件人:  [email-masked]
2011-07-23 上午 07:22

收件人
Lou Berger <[email-masked]>, Rajan Rao <[email-masked]>
抄送
CCAMP <[email-masked]>, Mohit Misra <[email-masked]>
主题
Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi 
stage)

Hi Lou,

We do want to highlight a new requirement (and a possible solution) 
regarding "how to control the origination point of implicit H-LSP" through 
ERO. Service layer LSP request should have an option to contain enough 
information to identify where the implicit LSP originating from and where 
it is terminating. This detail should include, for each layer, the 
Interface ID and OPU time slot  to complete the specification.

Thanks
Khuzema & Rajan

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, July 22, 2011 7:13 AM
To: Rajan Rao
Cc: John E Drake; CCAMP; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; 
Mohit Misra
Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs 
multi stage)

Guys,

Is it:
1) definition related: to make a comment on the definition of "implicit 
H-LSP"
2) requirements related: to highlight a new requirement/challenge related 
to the control of "implicit H-LSPs" via "implicit-link LSPs"
3) solution related: to state a solution to a new requirement/challenge 
related to the control of "implicit H-LSPs"
4) something else

BTW my intent on this particular thread was to keep the discussion focused 
on definitions and requirements, not solutions.  We can move onto 
solutions once we have agreement on terms and requirements.

Lou