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

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

Sent from my iPhone

-----Original Message-----
From: John E Drake 
Sent: Friday, June 24, 2011 5:39 PM
To: '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; Fatai Zhang; Ashok Kunjidhapatham; Khuzema Pithewan; Rajan Rao; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO)
Subject: RE: RSVP OTN single stage vs multi stage

Snipped...

Sent from my iPhone

> 
> JD:  As I said before, a multi-stage hierarchical LSP is a new
> construct, and one that has never been modeled before.  In particular,
> the sub-layer LSPs do not have an existence outside the containing
> hierarchical LSP and are there simply to provide context for each
> stage.  I think this renders any discussion of independent sub-layer
> LSP protection switching effectively moot.  I.e., the containing
> hierarchical LSP may be protection switched but not the sub-layer LSPs
> within it, and this would be the *same regardless* of which of the two
> schemes is employed.
> 
> Wrt OAM, again, the data plane instantiated by *either* of the two
> schemes would be the same.
> 
> [SBPG] There is no need for a new "Multi-stage hierarchical LSP"
> construct
> for the reason that H-LSP as specified in RFC 6107 completely solves
> the
> problem of nesting LSPs belonging to different layers.

JD:  That's incorrect.  As I indicated previously, the logic to send and receive multiple sequential sub-layer LSPs between the endpoints of a containing hierarchical LSP is new.

> 
> We remind that in field NMS already deal with multi-layer technologies
> and that the adopt way of working is "per layer" from server to client.
> The introduction of a multi-stage label with a consequent new model
> of intermediate layer creation would force the NMS to be modified in
> order to support this new mode when there is no need at all, being the
> problem solved by H-LSP in a clean way.

JD:  That's incorrect.  We are dealing with multiple sub-layer LSPs between the endpoints of a containing hierarchical LSP.  This is a new construct, and regardless of which of the two methods is used to establish them, the NMS will have to be modified to understand this construct.   

> 
> Last but not least, the fact that no one wants to protect intermediate
> layer is your personal opinion.

JD:  Well, the fact that it is my opinion is a correct statement.  However, that opinion is consistent with the way MPLS/GMPLS works.  

> In case of use of H-LSPs there is no
> reason why
> an intermediate layer should not be protected or restored. And in any
> case
> it is an operator choice.

JD:  This is incorrect.  LSPs contained within a hierarchical LSP are signaled between the endpoints of that hierarchical LSP.  No other nodes see the signaling requests and the contained LSPs are completely encapsulated within the hierarchical LSP.

> 
> JD: In *either* case, one has to build the logic to instantiate the
> multistage data plane.  If one chooses multi-stage labels, one has to
> build the code to send and receive multi-stage labels.  If one chooses
> multiple sequential sub-layer LSPs, one has to build the code to send
> and receive the sequential sub-layer LSPs.
> 
> To my mind, the amount of code and testing is about the same, which is
> not surprising because we are doing the same thing in either case.
> 
> [SBPG] John, using H-LSPs only there is the need to test only one
> feature:
> Multi-stage via H-LSPs.

JD:  The logic to send and receive multiple sequential sub-layer LSPs between the endpoints of a containing hierarchical LSP is new.

> 
> With the introduction of a multi-stage label there will be to test:
> - Multi-stage with multi-label only
> - Multi-stage with H-LSP only
> - Multi-stage with H-LSPs + multi-label with mixes dependent from
> network topology and number of layer.

JD:  That is incorrect.  One would have to implement and test the logic to send and receive multi-stage labels, which is the middle case in your list above.

> 
> It is really difficult to understand how these  two efforts both for
> implementation and tests can be the same.....

JD:  See above.

> 
> JD:  We can either jury-rig an existing mechanism to solve a new
> problem, which as I indicated above is a non-zero amount of work, or we
> can invent an extension to solve a new problem.
> 
> [SBPG] Modifications can always be done, but it would be difficult to
> justify them when they are not needed because the problem is already
> solved with what we have in standard now...

JD:  That is incorrect.  As I explained above, hierarchical LSPs by themselves do not solve the multi-stage hierarchical LSP construct.

> 
> Currently our proposal is to consider the multi-stage label feature
> optional.

JD:  This is the worst possible approach.  If we want to solve the multi-stage hierarchical LSP construct using multiple sequential sub-layer LSPs, then that is the only approach that should be standardized.

---

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

Sent from my iPhone

-----Original Message-----
From: John E Drake
Sent: Friday, June 24, 2011 2:54 AM
To: 'BELOTTI, SERGIO (SERGIO)'
Cc: Vallinayakam Somasundaram; Tellabs - Jonathan Sadler; Jonathan Hardwick; Li Dan; NSN - Cyril Margaria; [email-masked]; Ciena - Lyndon Ong; Steve Balls; Diego Caviglia; Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Ashok Kunjidhapatham; Khuzema Pithewan; Rajan Rao; Daniele Ceccarelli
Subject: RE: RSVP OTN single stage vs multi stage

Daniele,

Comments inline.

Thanks,

John

Sent from my iPhone

> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
> lucent.com]
> Sent: Friday, June 24, 2011 2:06 AM
> To: 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; Fatai Zhang; GRANDI, PIETRO
> VITTORIO (PIETRO VITTORIO); Ashok Kunjidhapatham; Khuzema Pithewan;
> Rajan Rao; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO)
> Subject: R: RSVP OTN single stage vs multi stage
>
> Hello John,
>
> We think that these arguments have to be considered in this context:
>
> 1) what Jonathan correctly pointed out is a real transport problem ,
> impacting also the NMS coordination with CP, in order to manage a CP
> managed network. As already said in a previous mail , NMS is used to
> operate "per layer" considering OAM and alarms of all layers. In order
> to do this intermediate layers of a multistage multiplexing have to be
> explicitly modeled. Currently NMS systems solves the problem with
> bottom-up approach modeling layers from server to clients. NMS in field
> expects server layer is created before any clients . In this case
> having a CP creating all layers together in an "implicit way" is
> disruptive with respect to NMS way of working.

JD:  As I said before, a multi-stage hierarchical LSP is a new construct, and one that has never been modeled before.  In particular, the sub-layer LSPs do not have an existence outside the containing hierarchical LSP and are there simply to provide context for each stage.  I think this renders any discussion of independent sub-layer LSP protection switching effectively moot.  I.e., the containing hierarchical LSP may be protection switched but not the sub-layer LSPs within it, and this would be the *same regardless* of which of the two schemes is employed.

Wrt OAM, again, the data plane instantiated by *either* of the two schemes would be the same.

>
> 2) You're saying that multi stage label approach is applicable in two
> cases:
>   a) single-hop case that you admit as very corner case with no
> interest.
>   b) as an enhancement to setup a multi hop LSP, in which you have to
> use an H-LSP to setup an FA-LSP in order to recreate over the FA-LSP
> the same condition of case a). Then your proposal is to go on with
> multistage label approach . Doing so you are implementing two
> mechanisms to make the same thing. What is the reason for which we have
> to force every implementation to pay this additional cost?

JD: In *either* case, one has to build the logic to instantiate the multistage data plane.  If one chooses multi-stage labels, one has to build the code to send and receive multi-stage labels.  If one chooses multiple sequential sub-layer LSPs, one has to build the code to send and receive the sequential sub-layer LSPs.

To my mind, the amount of code and testing is about the same, which is not surprising because we are doing the same thing in either case.

>
> 3) From your reasoning also it is quite clear that multistage label "
> can be used to improve wrt latency and control plane overhead, the
> establishment of ODUj LSPs within multi-stage hierarchical LSPs". This
> , if true, it is in any case a "nice to have" that cannot be imposed by
> a standard implementation.

JD:  We can either jury-rig an existing mechanism to solve a new problem, which as I indicated above is a non-zero amount of work, or we can invent an extension to solve a new problem.

>
> Best Regards
>
> Sergio, Pietro, Daniele.
>
> 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: venerdì 24 giugno 2011 0.56
> A: 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
> Oggetto: RE: RSVP OTN single stage vs multi stage
>
> Fatai,
>
> Comments inline.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
> > 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
> > 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
> >
> >
> > > 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)
> > > 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)
> > >
> > >
> > > 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
> > > 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
> > > 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: John E Drake <[email-masked]>
Date: Tue, 28 Jun 2011 05:12:53 -0700

Sent from my iPhone

-----Original Message-----
From: John E Drake
Sent: Thursday, June 23, 2011 9:39 PM
To: Sadler, Jonathan B.
Cc: Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Vallinayakam Somasundaram; 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

Jonathan,

It doesn't seem that you saw my last email to you and it doesn't seem
that you understood my email to Fatai.  Before posturing, please read
them and see if you can understand them.

Thanks,

John

Sent from my iPhone

On Jun 24, 2011, at 10:48 AM, "Sadler, Jonathan B." <[email-masked]

> John -
>
> OAM and Protection are key parts of a service provider's service
> delivery architecture.  Instead of discussing fish, it would
> probably be better to discuss these issues in order to make certain
> hierarchical labels don't create architectural problems.
>
> In the hierarchical label approach you are advocating, do you plan
> to convey detail on how each layer should react to OAM indications
> (e.g. service fail, service degrade)?  Or are you expecting that
> lower layer OAM would be ignored?
>
> Jonathan Sadler
>
> Sent: Thursday, June 23, 2011 5:56 PM
> To: Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> Cc: Vallinayakam Somasundaram; Sadler, Jonathan B.; Jonathan
> BELOTTI, SERGIO (SERGIO); Khuzema Pithewan; Rajan Rao; Daniele
> Ceccarelli
> 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.
>
>>
>> E.g., an ODU0 connection request from A to E through B, C and D,
>> but B,
> 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
>> muxing, I think the only thing necessary is a new label format,
>> which I
>> wrt latency and control plane overhead.  The one thing I do not
>> want to
>>> concept) already used in CP managing multi-layer with something that
>>> does not exist at all.
>>> We should also keep in mind that multi-stage label approach can only
>> be
>>> For both these reasons the "optional" condition of multi-stage label
>>> lucent.com<mailto:[email-masked]>> wrote:
>>>
>>> Hello John,
>>>
>>> Ashok Kunjidhapatham; Diego Caviglia; 'Steve Balls'; 'Ciena - Lyndon
>>> switching type, which is also carried in signaling.  This means that
>> we
>>> To: John E Drake; Rajan Rao; Fatai Zhang; Khuzema Pithewan; BELOTTI,
>>> An implementation RFC4328 based (that we've explicitly been told not
>> to
>>> To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Khuzema Pithewan;
>>> 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 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: Tue, 28 Jun 2011 05:11:49 -0700

Sent from my iPhone

-----Original Message-----
From: John E Drake
Sent: Friday, June 24, 2011 7:24 PM
To: 'Sadler, Jonathan B.'
Cc: Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Vallinayakam Somasundaram; 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

Snipped...

Sent from my iPhone

>
> While it is true that the extent of the connections in service layer
> and the lower layer are the same, the coincidence of endpoints doesn't
> remove the OAM messaging that occurs in the lower layer, nor does it
> render it unimportant.  There are conditions where lower layer OAM
> indications can be used to trigger a proactive response before service
> layer degrade/failure is noted.  However, if the lower layer connection
> is not explicitly signaled, there is nothing that will configure how
> these indications should be handled.

JD:  That sounds suspiciously like an assertion.  Further, the only work that has been done to date on OTN OAM configuration, Attila's draft, does not seem to address the case of multiple hierarchical LSPs, the containing hierarchical LSP and the sub-layer LSPs within it, that have common endpoints.  So, regardless of which of the two proposals is adopted, there is work to be done.

Regardless of which of the two proposals is used to establish them, the only nodes with awareness of the sub-layer LSPs are the endpoints of the containing hierarchical LSP.

This has several implications:

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

2)  The sub-layer LSPs cannot be protection switched outside the context of the containing hierarchical LSP

3)  The only nodes with OAM awareness of the sub-layer LSPs are the nodes with the endpoints of the containing hierarchical LSP

Within these constraints, it might be useful to have you articulate *exactly* what functionality you think is required.  To this point I haven't seen anything concrete.

>
> It is indeed possible to load all of the lower layer configuration
> information into the same RSVP message being used to signal the service
> LSP.  However, I don't see you proposing to do this.

JD:  Initially, I also thought there might be a lot of additional parameters that would need to be added to the ODUj Path message in order to simultaneously establish the sub-layer LSPs.  However, there doesn't seem to be anything other than the labels for the sub-layer LSPs.

> If this indeed is
> your proposal, please recognize there are cases when two or more
> service LSPs could request use of the same lower layer connection but
> have different expectations of how the lower layer OAM is to be
> handled.

JD:  I would expect that whatever is required will be completely covered in the establishment of the ODUj LSP within the containing hierarchical ODUk LSP.

> This is part of the reason the architecture folk at ITU-T
> view layers as an important construct which shouldn't be dismissed out-
> of-hand.

JD:  Um, right.  However, in this case we are very clearly dealing with a set of one or more sub-layer LSPs within a containing hierarchical ODUk LSP, and the purpose for these sub-layer LSPs is strictly to provide time slot context for the ODUj LSPs that are being signaled over the containing ODUk hierarchical LSP.

> Your later message to Fatai states you see this being used in "multi-
> hop multi-stage hierarchical LSPs".  In a mapped server case (i.e.
> where only one Service LSP is carried in a lower layer LSP) this
> potentially may be useful, but the ODU multi-stage environment isn't
> mapped server - it's a multiplexed server which can carry multiple
> Service LSPs.  Hence the issue mentioned above re: OAM expectations.

JD:  I don't understand this comment.  The entire discussion, to which you are admittedly late, has been about multi-hop multi-stage hierarchical LSPs that will be used to carry a variety of ODUj client LSPs.  The only point of discussion is which of two proposals will be used to instantiate the sub-layer LSPs within the multi-hop multi-stage hierarchical LSP.

>
> Jonathan Sadler
>
> P.S. The term "sub-layer" is also used in the ITU-T, but it looks like
> you are using it with a different meaning.  Please clarify if you are
> attempting to use it as used in the ITU-T.  It certainly will help
> others understand your messages.

JD:  I think my usage is quite clear and I don't think it is necessary for me to do a canvas of the usage of terms by other SDOs.

> Sent: Thursday, June 23, 2011 11:39 PM
> To: Sadler, Jonathan B.
> Cc: Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
> Vallinayakam Somasundaram; 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