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

From: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 05:13:10 -0700

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]; 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]]
> 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]; 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]>
> To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)"
> <[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]>
> 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]]
> > 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]; 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]
> > ============================================
> > 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]]
> > 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]; 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]]
> > 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]>; '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]]
> > 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]>; '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-
> > 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]]
> > 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]>; '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]]
> > 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]>; '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]]
> > 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]>; '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

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 28 Jun 2011 20:49:26 +0800

Hi John,

You did not review our slides, so we think that you did not understand the spirit of multi-stage label approach correctly.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: 2011年6月28日 20: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]; 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

> > different capabilities (inter-op).
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 06:15:03 -0700

It might be more precise to say I reviewed your slides and found them, shall we say, lacking.

Sent from my iPhone

> Sent: Tuesday, June 28, 2011 5:49 AM
> To: John E Drake; 'CCAMP'
> Subject: RE: [CCAMP] FW: RSVP OTN single stage vs multi stage
>
> Hi John,
>
> You did not review our slides, so we think that you did not understand
> the spirit of multi-stage label approach correctly.
>
>
>
>
> Thanks
>
> Fatai
>
>
> 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.
>
> >
> 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

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Tue, 28 Jun 2011 16:43:10 +0200

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

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

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Jun 2011 16:23:45 +0000

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

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

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 15:12:27 -0700

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

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2011 9:24 AM
> 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
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> 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."
>

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 15:24:59 -0700

Pietro,

Although I don't recall your appointment as list moderator, my apologies.

Forwarding the individual emails rather than synthesizing their contents was strictly an expedient but given that the private mailing list is a close approximation of the list of subscribers to the CCAMP mailing list, I didn't see the harm.

On the other topic, my emails to Fatai were preceded by the following from him:

"Hi John,

Thanks

Fatai"

This email is implicitly from you as well, and if you look up 'arrogance' in the dictionary, you might see this note.

Thanks,

John

Sent from my iPhone

> Sent: Tuesday, June 28, 2011 7:43 AM
> To: John E Drake
> Cc: CCAMP; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; GRANDI, PIETRO
> VITTORIO (PIETRO VITTORIO)
> Of John E Drake

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Wed, 29 Jun 2011 09:41:30 +0200

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.

2) Heavy impacts on transport network management systems that are currently based on "per layer management" and should work in a very different way.

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.

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,

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

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

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 29 Jun 2011 16:58:55 +0800

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

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

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

> Sit with a pretty girl for an hour, and it seems like a  minute. That's

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

> BELOTTI,

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

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

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

> Rao"

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

> <[email-masked]>;

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

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

> explicitly

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

> Path

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

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

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

> Steve

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

> Margaria;

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

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

> only

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

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

> hour.

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

> Steve

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

> Margaria;

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

> switching

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

> wrote:

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

> Lyndon

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

> different

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

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

> Khuzema

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

> and

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

> hour.

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

> BELOTTI,

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

> as

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

> not

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

> multi-

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

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

> Pithewan;

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

> multi-

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

> link

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

CCAMP mailing list

[email-masked]

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 29 Jun 2011 11:45:26 +0200

John,

The mail is co-signed, and there is no need to be a list moderator trying to bring back the discussion in a polite way.

I would avoid trying to justify a clear bad behavior mentioning mails written by other guy.
When you say "This email is implicitly from you as well" is only your assumption without any objectiveness .
Instead your arrogant comment without any technical analysis of our slides is an "explicit" insult to us since the slides were made together with Fatai.

Said that we are happy to accept your apology, and come back only to technical discussion.

Best Regards

Sergio

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]]
Inviato: mercoledì 29 giugno 2011 0.25
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Oggetto: RE: RSVP OTN single stage vs multi stage

Pietro,

"Hi John,

Thanks

Fatai"

Thanks,

John

Sent from my iPhone

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 29 Jun 2011 13:17:47 +0000

John,

Please, see my comments in-line, we do have some disagreements. 
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 6:12 PM
To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: RE: RSVP OTN single stage vs multi stage

Igor,

IB>> Sorry to admit that I am one of these people. I disagree with you on this. For one thing, I do not like the idea of induced multi-hop H_LSPs. H_LSPs IMO should be pre-planned and provisioned in different time frame than connections they carry. Besides, multi-hop H-LSPs are links incongruent with links supported by OTUs, they will surely benefit from their own OAM. If I understand Infinera folks correctly, the idea of multi-stage provisioning is to avoid single-hop H-LSPs, and I agree with them. 

IB>> But this could be viewed as a build-up on top of the existing machinery. At any rate, as I said, I don't like the idea of induced H-LSPs in principle, however, if the H-LSPs are pre-configured, I don't see why the existing LSP hierarchy won't work as it is.

IB>> I don't see a reason why not to do both, 

Igor

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Jun 2011 08:39:03 -0700

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]]
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]] 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: John E Drake <[email-masked]>
Date: Wed, 29 Jun 2011 08:41:30 -0700

Fatai,

One important point I forgot.  With either approach, the signaling is strictly between the containing hierarchical LSP endpoints, B and D.  No other nodes see any signaling messages once the ODU3 hierarchical LSP is established.

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: John E Drake <[email-masked]>
Date: Wed, 29 Jun 2011 08:52:51 -0700

Comments inline.

Sent from my iPhone

> Sent: Wednesday, June 29, 2011 12:42 AM
> To: CCAMP
> Cc: John E Drake; Igor Bryskin; BELOTTI, SERGIO (SERGIO); GRANDI,
> PIETRO VITTORIO (PIETRO VITTORIO)
> 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.

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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 30 Jun 2011 10:24:42 +0800

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.

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.

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

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

 

Thanks
 
Fatai

From: John E Drake [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]] 
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,

 

 

Thanks

Fatai

-----Original Message-----

Igor,

Thanks,

John

Sent from my iPhone

CCAMP mailing list

[email-masked]

---

From: [email-masked]
Date: Thu, 30 Jun 2011 11:19:24 +0800

Hi Fatai

Please resend the example provided in the above mail if it is possible.

It is not displayed in my labtop.

Thanks

Fei

Fatai Zhang <[email-masked]> 
发件人:  [email-masked]
2011-06-30 10:24

收件人
'John E Drake' <[email-masked]>, 'Igor Bryskin' 
<[email-masked]>, "'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'" 
<[email-masked]>
抄送
'CCAMP' <[email-masked]>
主题
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.

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

 
Thanks
 
Fatai
 
From: John E Drake [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

Hi John,
 
Agree with Igor that let emotions aside if there was some improper 
wording. Let’s discuss tech.

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

 
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.

Thanks,
 
John
 
Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Jun 2011 20:36:38 -0700

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [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.

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

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: John E Drake <[email-masked]>
Date: Wed, 29 Jun 2011 21:12:41 -0700

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

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.

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 30 Jun 2011 15:13:14 +0800

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

Sent: 2011年6月30日 11:37

Fatai,

Comments inline.

Thanks,

John

Sent from my iPhone

Hi John,

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* 

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

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.

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

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

 

 

Thanks

Fatai

-----Original Message-----

Igor,

Thanks,

John

Sent from my iPhone

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

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

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

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

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

CCAMP mailing list

[email-masked]

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:12:39 +0200

Hello John,

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

-----Original Message-----
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)
Subject: RE: RSVP OTN single stage vs multi stage

Comments inline.

Sent from my iPhone

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 30 Jun 2011 13:44:49 +0000

Snipped....

KP:: This is true that multi-stage replaces only single hop H-LSPs and not multi-hop H-LSPs. Having said that, the multi-stage label can be applied on top of H-LSP treating the already setup H-LSP as just another link. For example, if on an interface, mux hierarchy is ODU4-ODU3-ODU2-ODU1 and ODU3 lsp needs to be setup as H-LSP going through multiple hops, the ODU1 lsp can be setup using multi-stage construct using ODU3 H-LSP as link, if other end of the H-LSP also supports extraction and switching of ODU2-ODU1.

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 29, 2011 6:48 PM
To: John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 6:12 PM
To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: RE: RSVP OTN single stage vs multi stage

Igor,

Igor

Sent from my iPhone

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 30 Jun 2011 15:53:29 +0000

Khuzema,

Please, see in line

Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]] 
Sent: Thursday, June 30, 2011 9:45 AM
To: Igor Bryskin; John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP; Biao Lu; Ping Pan; Rajan Rao; Ashok Kunjidhapatham; Mohit Misra
Subject: RE: RSVP OTN single stage vs multi stage

Snipped....

IB>> I agree, but existing H-LSP (as long as it is pre-planned and set up in different time frame) is a link no different from, say, OUT link. So this is still a one-hop scenario. What I don't like is induced (created on the fly) H-LSPs 

Igor 

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 29, 2011 6:48 PM
To: John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 6:12 PM
To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: RE: RSVP OTN single stage vs multi stage

Igor,

Igor

Sent from my iPhone

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 30 Jun 2011 16:00:13 +0000

I agree. H-lsp is a link.

Khuzema

----- Original Message -----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 08:53 AM
To: Khuzema Pithewan; John E Drake <[email-masked]>; GRANDI, PIETRO VITTORIO (PIETRO	VITTORIO) <[email-masked]>
Cc: CCAMP <[email-masked]>; Biao Lu; Ping Pan; Rajan Rao; Ashok Kunjidhapatham; Mohit Misra
Subject: RE: RSVP OTN single stage vs multi stage

Khuzema,

Please, see in line

Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]] 
Sent: Thursday, June 30, 2011 9:45 AM
To: Igor Bryskin; John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP; Biao Lu; Ping Pan; Rajan Rao; Ashok Kunjidhapatham; Mohit Misra
Subject: RE: RSVP OTN single stage vs multi stage

Snipped....

Igor 

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 29, 2011 6:48 PM
To: John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 6:12 PM
To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: RE: RSVP OTN single stage vs multi stage

Igor,

Igor

Sent from my iPhone

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 17:57:07 +0100

Pardon me for jumping in here....but Igor makes a more fundamental and important point...one cannot create server layer topology on the fly.  A link in layer N network is created by an E2E path in a lower layer N-1 network...this is a recursive relationship down to the duct.

I think a great deal of misinformation/confusion has arisen from the flawed notion of a common CP running across all nested later networks....it plain won't work....and a fairly crass observation is that I have yet to see OSPF dig a trench and lay a duct layer network followed by its client guided EM wave layer network (metallic or optical).....and so on upwards.  And I am scratching the surface here wrt all the practical consequences...there are some very important commercial consequences of assuming one can create 'on-demand' topology in a client layer network, and of course there is the killer observation that (i) not all parties own all the layers down to the duct and (ii) the geographic span of the server topology may be much less than the client.

Aside=> If one wants to consider the issue of efficiency here one should minimise how many layer networks exist between the TOS layer network that interfaces with external message/file/stream applications and the BOS layer network that modulates an EM wave....note that both the TOS and BOS layer networks MUST be present in all networking scenarios, but there are an awful lot of other layer networks that are neither of these.  There is a hint in here as to where problems get generated and currently lie....I'll avoid giving some examples ;-)

A client layer routing process can only be stable/work if a server layer routing process (which can be very different in nature to the client routing process) has provided the client with a *stable* topological resource it can use.  Or as one of colleagues very nicely/tersely put it:  "One can only configure that which already exists"...quite.

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> Of Khuzema Pithewan
> Sent: 30 June 2011 17:00
> To: [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: Ping Pan; [email-masked]'; Mohit Misra
> To: Khuzema Pithewan; John E Drake <[email-masked]>; GRANDI, PIETRO
> VITTORIO (PIETRO      VITTORIO) <pietro_vittorio.grandi@alcatel-
> lucent.com>
> 1)  Multi-stage labels apply equally well to multi-hop hierarchical
> LSPs. (The is the point some people do not seem to understand.)
>
> IB>> Sorry to admit that I am one of these people. I disagree with you
> on this. For one thing, I do not like the idea of induced multi-hop
> H_LSPs. H_LSPs IMO should be pre-planned and provisioned in different
> time frame than connections they carry. Besides, multi-hop H-LSPs are
> links incongruent with links supported by OTUs, they will surely
> benefit from their own OAM. If I understand Infinera folks correctly,
> the idea of multi-stage provisioning is to avoid single-hop H-LSPs, and
> I agree with them.
>
>
>
> KP:: This is true that multi-stage replaces only single hop H-LSPs and
> not multi-hop H-LSPs. Having said that, the multi-stage label can be
> applied on top of H-LSP treating the already setup H-LSP as just
> another link. For example, if on an interface, mux hierarchy is ODU4-
> ODU3-ODU2-ODU1 and ODU3 lsp needs to be setup as H-LSP going through
> multiple hops, the ODU1 lsp can be setup using multi-stage construct
> using ODU3 H-LSP as link, if other end of the H-LSP also supports
> extraction and switching of ODU2-ODU1.
>
> IB>> I agree, but existing H-LSP (as long as it is pre-planned and set
> up in different time frame) is a link no different from, say, OUT link.
> So this is still a one-hop scenario. What I don't like is induced
> (created on the fly) H-LSPs
>
> Igor
>
> Thanks
> Khuzema
>
> Of Igor Bryskin
> 1)  Multi-stage labels apply equally well to multi-hop hierarchical
> LSPs. (The is the point some people do not seem to understand.)
>
> IB>> Sorry to admit that I am one of these people. I disagree with you
> on this. For one thing, I do not like the idea of induced multi-hop
> H_LSPs. H_LSPs IMO should be pre-planned and provisioned in different
> time frame than connections they carry. Besides, multi-hop H-LSPs are
> links incongruent with links supported by OTUs, they will surely
> benefit from their own OAM. If I understand Infinera folks correctly,
> the idea of multi-stage provisioning is to avoid single-hop H-LSPs, and
> I agree with them.
>
> 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.
>
> IB>> But this could be viewed as a build-up on top of the existing
> machinery. At any rate, as I said, I don't like the idea of induced H-
> LSPs in principle, however, if the H-LSPs are pre-configured, I don't
> see why the existing LSP hierarchy won't work as it is.
>
> 3)  I don't think we should standardize both approaches.  I would
> prefer that the working group pick one to standardize.
>

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 01 Jul 2011 08:50:27 +0800

Hi all,

Agree. That is what we are trying to convey to some people under multi-stage label context.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: 2011年7月1日 0:00
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: Ping Pan; [email-masked]'; Mohit Misra
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

Khuzema

----- Original Message -----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 08:53 AM
To: Khuzema Pithewan; John E Drake <[email-masked]>; GRANDI, PIETRO VITTORIO (PIETRO	VITTORIO) <[email-masked]>
Cc: CCAMP <[email-masked]>; Biao Lu; Ping Pan; Rajan Rao; Ashok Kunjidhapatham; Mohit Misra
Subject: RE: RSVP OTN single stage vs multi stage

Khuzema,

Please, see in line

Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]] 
Sent: Thursday, June 30, 2011 9:45 AM
To: Igor Bryskin; John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP; Biao Lu; Ping Pan; Rajan Rao; Ashok Kunjidhapatham; Mohit Misra
Subject: RE: RSVP OTN single stage vs multi stage

Snipped....

Igor 

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 29, 2011 6:48 PM
To: John E Drake; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage

John,

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 6:12 PM
To: Igor Bryskin; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: RE: RSVP OTN single stage vs multi stage

Igor,

Igor

Sent from my iPhone