Re: OTN signalling drafts status

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: OTN signalling drafts status

Hi Xihua,

 

The problem I have with the multi-stage (sic) label is it neglects the other signaling details necessary for multiple layers.

 

Right now, the other signaling objects (protection, notify, etc.) are all associated with a single layer.  Making the label multiple layers requires these other objects to also need to be able to specify detail for multiple layers.

 

This is consistent with your statement pIt depends on m OAM configurationq

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: RSVP OTN single stage vs multi stage

Fatai,

 

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

 

As John mentioned in a previous email, how to handle multi-layer in a single signaling session has not been done before.  A solution will address more than just the label format

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: RSVP OTN single stage vs multi stage

Pietro,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> [mailto:pietro_vittorio.grandi <at> alcatel-lucent.com]
> Sent: Thursday, June 30, 2011 3:13 AM
> To: John E Drake; CCAMP
> Cc: Igor Bryskin; BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO
> (PIETRO VITTORIO)
> Subject: RE: RSVP OTN single stage vs multi stage
>
> 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:jdrake <at> juniper.net]
> 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
>
> > -----Original Message-----
> > From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > [mailto:pietro_vittorio.grandi <at> alcatel-lucent.com]
> > Sent: Wednesday, June 29, 2011 12:42 AM
> > To: CCAMP
> > Cc: John E Drake; Igor Bryskin; BELOTTI, SERGIO (SERGIO); GRANDI,
> > PIETRO VITTORIO (PIETRO VITTORIO)
> > Subject: RE: RSVP OTN single stage vs multi stage
> >
> >
> > Hello Igor,
> >
> > The discussion is all in deciding whether to consider the
> > support of multi-stage label as optional or mandatory.
> >
> > Support of multi-stage labels have consequences that include:
> > 1) the fact that it is not possible to protect intermediate layers
> > either via protection or restoration. This restricts the application
> > field of the concept in such a way that it can be considered an
> > optimization applicable to specific cases.
>
> JD:  As I have said before, for the new construct we are dealing with,
> viz, a containing hierarchical LSP with one or more sub-layer LSPs
> between the same two endpoints, it is not possible to protect the
> individual sub-layer LSPs outside the context of the containing
> hierarchical LSP.
>
> >
> > 2) Heavy impacts on transport network management systems that are
> > currently based on "per layer management" and should work in a very
> > different way.
>
> JD:  The construct defined above is new and management systems will
> have to be modified to understand it.
>
> > Last but not least, the OTN architecture allows explicitly the "per
> > layer"
> > management, that is the reference for transport networks. Every GMPLS
> > implementation has to be consistent with this reference.
>
> JD:  The containing hierarchical LSP with multiple sub-layer LSPs,
> regardless of which of the two proposals being discussed for
> establishing the sub-layer LSPs, has nothing whatever to do with layer
> management.
>
> >
> > In conclusion, the usage of the multi-stage label  should be
> considered
> > as optional and the support should be clearly stated via an
> appropriate
> > advertising.
> >
> > Unfortunately, contrary to  point 3), someone insists in forcing the
> > usage and support of multi-stage labels as mandatory.
> >
> > The point in discussion is all here.
> >
> > Best Regards
> > Pietro & Sergio
> >
> >
> > Hi Pietro,
> >
> > 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.
> >
> >
> > -----Original Message-----
> > From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On
> Behalf
> > Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > Sent: Tuesday, June 28, 2011 10:43 AM
> > To: John E Drake
> > Cc: CCAMP
> > Subject: Re: [CCAMP] RSVP OTN single stage vs multi stage
> >
> > Hello John,
> >
> > 1) You have forwarded to the CCamp mailing list a number of private
> > mails without asking the permission to the involved people. This is
> > impolite and unprofessional.
> >
> > 2) You are creating spam on the mailing list forwarding four threads
> > that are each hundreds of lines long and very complicated to follow
> for
> > people not involved in the discussion since the beginning. Moreover,
> > this happened after a discussion from scratch was already started in
> > the mailing list.
> >
> > 3) You moved from a technical discussion to arrogant and deliberate
> > personal offenses not supported by any sound technical motivation as
> > reported in your mails and snipped below:
> >
> > "This shows a complete lack of understanding of hierarchical LSP,
> > multi-stage labels, and GMPLS in general.  It is so bad it is not
> even
> > wrong."
> >
> > " It might be more precise to say I reviewed your slides and found
> > them, shall we say, lacking."
> >
> > We hope that from now on the discussion can be continued from a
> purely
> > technical point of view.
> >
> > Pietro, Sergio and Daniele
> >
> > ============================================
> > Pietro Vittorio Grandi
> > Terrestrial Optics Portfolio Evolution
> > Alcatel-Lucent Vimercate (Italy)
> > Tel: +39 039 686 4930
> > Mail: pietro_vittorio.grandi <at> alcatel-lucent.com
> > ============================================
> > Put your hand on a hot stove for a minute, and it seems like an hour.
> > Sit with a pretty girl for an hour, and it seems like a  minute.
> That's
> > relativity.
> > (A. Einstein)
> >
> > -----Original Message-----
> > From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On
> Behalf
> > Of John E Drake
> > Sent: martedì 28 giugno 2011 14.13
> > To: CCAMP
> > Subject: [CCAMP] FW: RSVP OTN single stage vs multi stage
> >
> >
> >
> > Sent from my iPhone
> >
> >
> > -----Original Message-----
> > From: John E Drake
> > Sent: Thursday, June 23, 2011 3:56 PM
> > To: 'Fatai Zhang'; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > Cc: Vallinayakam Somasundaram; Tellabs - Jonathan Sadler; Jonathan
> > Hardwick; Li Dan; NSN - Cyril Margaria; fu.xihua <at> zte.com.cn; Ciena -
> > Lyndon Ong; Steve Balls; Diego Caviglia; Ashok Kunjidhapatham;
> BELOTTI,
> > SERGIO (SERGIO); Khuzema Pithewan; Rajan Rao; Daniele Ceccarelli
> > Subject: RE: RSVP OTN single stage vs multi stage
> >
> > Fatai,
> >
> > Comments inline.
> >
> > Thanks,
> >
> > John
> >
> > Sent from my iPhone
> >
> >
> > > -----Original Message-----
> > > From: Fatai Zhang [mailto:zhangfatai <at> huawei.com]
> > > Sent: Thursday, June 23, 2011 9:45 AM
> > > To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); John E Drake
> > > Cc: Vallinayakam Somasundaram; Tellabs - Jonathan Sadler; Jonathan
> > > Hardwick; Li Dan; NSN - Cyril Margaria; fu.xihua <at> zte.com.cn; Ciena
> -
> > > Lyndon Ong; Steve Balls; Diego Caviglia; Ashok Kunjidhapatham;
> > BELOTTI,
> > > SERGIO (SERGIO); Khuzema Pithewan; Rajan Rao; Daniele Ceccarelli
> > > Subject: Re: RSVP OTN single stage vs multi stage
> > >
> > > Hi John,
> > >
> > > I guess that you did not review our slides carefully.
> >
> > JD:  I will let this pass.
> >
> > >
> > > You just see the only advantage for the corner case (i.e.,
> establish
> > > multi-layers LSP concurrently), but you did not see the issues that
> > we
> > > described in the slides and the issues that Jonathan mentioned
> (eg.,
> > > OAM/protection issues).
> >
> > JD:  I'm sorry that I didn't provide enough context.  I don't think
> the
> > one-hop hierarchical LSP case, w/ or w/o multi-stage labels is either
> > interesting or common and it was not the case to which I was
> addressing
> > my comments.  Rather, I was describing two ways of establishing
> multi-
> > hop multi-stage hierarchical LSPs.  As far as I can tell the issues
> > Jonathan raised in this context are red herrings rather than blue
> > whales.  Furthermore, regardless of which of the two approaches I
> > described is used, the issues, if any, would be exactly the same.
> >
> > >
> > > In addition, we have repeated many times that LSP hierarchy must be
> > > used in many cases, even though we have multi-stage label approach.
> > > E.g., an ODU0 connection request from A to E through B, C and D,
> but
> > B,
> > > C and  D (or one of them ) can not support ODU0 switching, the HO
> > ODUj
> > > (ODU1 or ODU2 or ODU3 or ODU4) LSP must be created between B and D
> > > through LSP hierarchy. This example is very simple and there are
> lots
> > > of transforms for this example to use LSP hierarchy.
> >
> > JD:  Please see above.  I completely agree with you and was simply
> > pointing out that multi-stage labels can be used to improve wrt
> latency
> > and control plane overhead, the establishment of ODUj LSPs within
> > multi-stage hierarchical LSPs.
> >
> > >
> > >
> > >
> > >
> > > Fatai
> > >
> > > Thanks
> > > ----- Original Message -----
> > > From: "John E Drake" <jdrake <at> juniper.net>
> > > To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)"
> > > <pietro_vittorio.grandi <at> alcatel-lucent.com>
> > > Cc: "Daniele Ceccarelli" <daniele.ceccarelli <at> ericsson.com>; "Rajan
> > Rao"
> > > <rrao <at> infinera.com>; "Fatai Zhang" <zhangfatai <at> huawei.com>;
> "Khuzema
> > > Pithewan" <kpithewan <at> infinera.com>; "BELOTTI, SERGIO (SERGIO)"
> > > <sergio.belotti <at> alcatel-lucent.com>; "Ashok Kunjidhapatham"
> > > <akunjidhapatham <at> infinera.com>; "Diego Caviglia"
> > > <diego.caviglia <at> ericsson.com>; "Steve Balls"
> > > <Steve.Balls <at> metaswitch.com>; "Ciena - Lyndon Ong"
> <LyOng <at> Ciena.com>;
> > > <fu.xihua <at> zte.com.cn>; "NSN - Cyril Margaria"
> > <cyril.margaria <at> nsn.com>;
> > > "Li Dan" <huawei.danli <at> huawei.com>; "Jonathan Hardwick"
> > > <Jonathan.Hardwick <at> metaswitch.com>; "Tellabs - Jonathan Sadler"
> > > <jonathan.sadler <at> tellabs.com>; "Vallinayakam Somasundaram"
> > > <valli <at> juniper.net>
> > > Sent: Thursday, June 23, 2011 7:21 PM
> > > Subject: RE: RSVP OTN single stage vs multi stage
> > >
> > >
> > > Pietro,
> > >
> > > If we are talking about the establishment of LSPs using single-
> stage
> > > muxing, I think the only thing necessary is a new label format,
> which
> > I
> > > believe is a bit map of tributary slots; i.e., LSP establishment
> > using
> > > single-stage muxing is done.
> > >
> > > We have never had a situation such as multi-stage muxing before so
> we
> > > are breaking new ground and we have two choices, either use LSP
> > > hierarchy to establish multiple single-stage sub-layer LSPs
> > explicitly
> > > and sequentially, or include the sub-layer information within the
> > Path
> > > message for the ODUj such that the sub-layers are established
> > > implicitly and concurrently with the establishment of the ODUj.
> > >
> > > Either will work, but it seems to me that the latter is more
> > efficient
> > > wrt latency and control plane overhead.  The one thing I do not
> want
> > to
> > > do is to say that both are supported.  If we can agree that we will
> > > only use one method to establish multi-stage LSPs, then when a node
> > > advertises multi-stage support in routing, we know how signaling is
> > to
> > > be accomplished.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > Sent from my iPhone
> > >
> > >
> > > > -----Original Message-----
> > > > From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > > > [mailto:pietro_vittorio.grandi <at> alcatel-lucent.com]
> > > > Sent: Monday, June 20, 2011 1:31 AM
> > > > To: John E Drake
> > > > Cc: Daniele Ceccarelli; Rajan Rao; Fatai Zhang; Khuzema Pithewan;
> > > > BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham; Diego Caviglia;
> > Steve
> > > > Balls; Ciena - Lyndon Ong; fu.xihua <at> zte.com.cn; NSN - Cyril
> > Margaria;
> > > > Li Dan; Jonathan Hardwick; Tellabs - Jonathan Sadler;
> Vallinayakam
> > > > Somasundaram; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > > > Subject: RE: RSVP OTN single stage vs multi stage
> > > >
> > > > John,
> > > >
> > > > It seems as though you consider on the same level something (H-
> LSP
> > > > concept) already used in CP managing multi-layer with something
> > that
> > > > does not exist at all.
> > > > Operators are used to managed their CP network together with NMS.
> > > > Most of the NMS work per-layer. The utilization of a multi-stage
> > > label
> > > > would force NMS to work in another manner with heavy
> implementation
> > > > consequences.
> > > >
> > > > We should also keep in mind that multi-stage label approach can
> > only
> > > be
> > > > used in some cases (not for all the one-hop multi-stage muxing)
> and
> > > it
> > > > will bring some management issues. Please see the slides that
> Fatai
> > > > sent a few days ago.
> > > >
> > > > For both these reasons the "optional" condition of multi-stage
> > label
> > > > concept is absolutely mandatory for us.
> > > >
> > > > Pietro, Sergio, Fatai & Daniele
> > > >
> > > > ============================================
> > > > Pietro Vittorio Grandi
> > > > Terrestrial Optics Portfolio Evolution
> > > > Alcatel-Lucent Vimercate (Italy)
> > > > Tel: +39 039 686 4930
> > > > Mail: pietro_vittorio.grandi <at> alcatel-lucent.com
> > > > ============================================
> > > > Put your hand on a hot stove for a minute, and it seems like an
> > hour.
> > > > Sit with a pretty girl for an hour, and it seems like a  minute.
> > > That's
> > > > relativity.
> > > > (A. Einstein)
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John E Drake [mailto:jdrake <at> juniper.net]
> > > > Sent: sabato 18 giugno 2011 2.40
> > > > To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > > > Cc: Daniele Ceccarelli; Rajan Rao; Fatai Zhang; Khuzema Pithewan;
> > > > BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham; Diego Caviglia;
> > Steve
> > > > Balls; Ciena - Lyndon Ong; fu.xihua <at> zte.com.cn; NSN - Cyril
> > Margaria;
> > > > Li Dan; Jonathan Hardwick; Tellabs - Jonathan Sadler;
> Vallinayakam
> > > > Somasundaram
> > > > Subject: Re: RSVP OTN single stage vs multi stage
> > > >
> > > > Pietro,
> > > >
> > > > We can certainly say that a node that advertises multistage
> > switching
> > > > support in routing MUST support multistage signaling.
> > > >
> > > > As I said before, using mutiple RSVP exchanges between the same
> LSP
> > > > endpoints to establish intermediate switching stages seems ill-
> > > > considered and forcing everyone to support two ways of signaling
> > > > multistage LSPs seems like a really Bad Idea.
> > > >
> > > > John
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On Jun 17, 2011, at 2:55 AM, "GRANDI, PIETRO VITTORIO (PIETRO
> > > > VITTORIO)" <pietro_vittorio.grandi <at> alcatel-
> > > > lucent.com<mailto:pietro_vittorio.grandi <at> alcatel-lucent.com>>
> > wrote:
> > > >
> > > > Hello John,
> > > >
> > > > I understand that you think that the new switching type in
> routing
> > > > should also convey implicitly the information that a
> > > > multi-stage label is supported.
> > > >
> > > > I do not agree with this statement.
> > > > Implementations using H-LSPs plus single stage labels are
> possible
> > > (and
> > > > already standard) and the fact the a node supports
> > > > the new switching type is not enough to clearly tell what is
> > > supported.
> > > >
> > > > Pietro
> > > >
> > > > ________________________________
> > > > From: John E Drake [mailto:jdrake <at> juniper.net]
> > > > Sent: venerdì 17 giugno 2011 2.09
> > > > To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele
> Ceccarelli;
> > > > Rajan Rao; Fatai Zhang; Khuzema Pithewan; BELOTTI, SERGIO
> (SERGIO);
> > > > Ashok Kunjidhapatham; Diego Caviglia; 'Steve Balls'; 'Ciena -
> > Lyndon
> > > > Ong'; fu.xihua <at> zte.com.cn<mailto:fu.xihua <at> zte.com.cn>; 'NSN -
> Cyril
> > > > Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs - Jonathan
> > > Sadler';
> > > > Vallinayakam Somasundaram
> > > > Subject: RE: RSVP OTN single stage vs multi stage
> > > >
> > > > Pietro,
> > > >
> > > > Actually we are already covered.   Our advertisements use a
> > different
> > > > switching type, which is also carried in signaling.  This means
> > that
> > > we
> > > > get to define the signaling used for this switching type, and I
> am
> > > > proposing that we use multistage.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > Sent from my iPhone
> > > >
> > > > From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> > > > [mailto:pietro_vittorio.grandi <at> alcatel-lucent.com]
> > > > Sent: Thursday, June 16, 2011 6:52 AM
> > > > To: Daniele Ceccarelli; John E Drake; Rajan Rao; Fatai Zhang;
> > Khuzema
> > > > Pithewan; BELOTTI, SERGIO (SERGIO); Ashok Kunjidhapatham; Diego
> > > > Caviglia; 'Steve Balls'; 'Ciena - Lyndon Ong';
> > > > fu.xihua <at> zte.com.cn<mailto:fu.xihua <at> zte.com.cn>; 'NSN - Cyril
> > > > Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs - Jonathan
> > > Sadler';
> > > > Vallinayakam Somasundaram
> > > > Subject: RE: RSVP OTN single stage vs multi stage
> > > >
> > > > Hi all,
> > > >
> > > > I  agree with Daniele' statement.
> > > >
> > > > in my mind this means that single stage label support is implicit
> > and
> > > > that
> > > > multi-stage labels should not be used unless a machine explicitly
> > > > declares the support.
> > > >
> > > > Pietro
> > > >
> > > >
> > > > ============================================
> > > > Pietro Vittorio Grandi
> > > > Terrestrial Optics Portfolio Evolution
> > > > Alcatel-Lucent Vimercate (Italy)
> > > > Tel: +39 039 686 4930
> > > > Mail: <mailto:pietro_vittorio.grandi <at> alcatel-lucent.com>
> > > > pietro_vittorio.grandi <at> alcatel-
> > > > lucent.com<mailto:pietro_vittorio.grandi <at> alcatel-lucent.com>
> > > > ============================================
> > > > Put your hand on a hot stove for a minute, and it seems like an
> > hour.
> > > > Sit with a pretty girl for an hour, and it seems like a  minute.
> > > That's
> > > > relativity.
> > > > (A. Einstein)
> > > >
> > > > ________________________________
> > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli <at> ericsson.com]
> > > > Sent: giovedì 16 giugno 2011 15.48
> > > > To: John E Drake; Rajan Rao; Fatai Zhang; Khuzema Pithewan;
> > BELOTTI,
> > > > SERGIO (SERGIO); Ashok Kunjidhapatham; GRANDI, PIETRO VITTORIO
> > > (PIETRO
> > > > VITTORIO); Diego Caviglia; 'Steve Balls'; 'Ciena - Lyndon Ong';
> > > > fu.xihua <at> zte.com.cn<mailto:fu.xihua <at> zte.com.cn>; 'NSN - Cyril
> > > > Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs - Jonathan
> > > Sadler';
> > > > Vallinayakam Somasundaram
> > > > Subject: RSVP OTN single stage vs multi stage
> > > >
> > > > Starting a new thread as we're now moving to signaling...
> > > >
> > > > Assuming we still have not decided whether we're going to support
> > > > single stage only, multi stage only or both of them i believe
> that
> > as
> > > > per OSPF we need to consider backward compatibility.
> > > >
> > > > An implementation RFC4328 based (that we've explicitly been told
> > not
> > > to
> > > > deprecate) is single stage based, so in case of multi stage only
> or
> > > > multi-stage + single stage we should be able to cover backward
> > > > compatibility issues somehow.
> > > >
> > > > BR
> > > > Daniele
> > > >
> > > > ________________________________
> > > > From: John E Drake [mailto:jdrake <at> juniper.net]
> > > > Sent: giovedì 16 giugno 2011 8.53
> > > > To: Rajan Rao; Daniele Ceccarelli; Fatai Zhang; Khuzema Pithewan;
> > > > 'BELOTTI, SERGIO (SERGIO)'; Ashok Kunjidhapatham
> > > > Cc: 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'; Diego Caviglia;
> > > 'Steve
> > > > Balls'; 'Ciena - Lyndon Ong';
> > > > fu.xihua <at> zte.com.cn<mailto:fu.xihua <at> zte.com.cn>; 'NSN - Cyril
> > > > Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs - Jonathan
> > > Sadler';
> > > > Vallinayakam Somasundaram
> > > > Subject: RE: Latest version of the OTN OSPF draft (support for
> > multi-
> > > > stage Vs Single Stage labels)
> > > > Rajan,
> > > >
> > > > I didn't want to allow interoperability options.  I much
> preferred
> > to
> > > > say that we do signaling in one way only, using multistage
> labels.
> > > > These are also needed for signaling within  hierarchical LSPs.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > Sent from my iPhone
> > > >
> > > > From: Rajan Rao [mailto:rrao <at> infinera.com]
> > > > Sent: Wednesday, June 15, 2011 10:46 PM
> > > > To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Khuzema
> > Pithewan;
> > > > 'BELOTTI, SERGIO (SERGIO)'; Ashok Kunjidhapatham
> > > > Cc: 'GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)'; Diego Caviglia;
> > > 'Steve
> > > > Balls'; 'Ciena - Lyndon Ong';
> > > > fu.xihua <at> zte.com.cn<mailto:fu.xihua <at> zte.com.cn>; 'NSN - Cyril
> > > > Margaria'; 'Li Dan'; 'Jonathan Hardwick'; 'Tellabs - Jonathan
> > > Sadler';
> > > > Vallinayakam Somasundaram
> > > > Subject: RE: Latest version of the OTN OSPF draft (support for
> > multi-
> > > > stage Vs Single Stage labels)
> > > >
> > > > Hi,
> > > >
> > > > While we are making updates, let us discuss support required in
> > link
> > > > advertisement for single/multi-stage label options:
> > > >
> > > > Given that there is interest in both multi-stage label and
> single-
> > > stage
> > > > with H-LSPs, we should consider inclusion of a FLAG to indicate
> > what
> > > > the link is capable of.  This will address some of the issues we
> > have
> > > > discussed in the past relating to path computation involving NEs
> > with
> > > > different capabilities (inter-op).
> > > >
> > > > Thanks
> > > > Rajan
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: RSVP OTN single stage vs multi stage

Jonathan,

 

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

 

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

 

Thanks,

 

John

 

Sent from my iPhone

 

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

 

Fatai,

 

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

 

As John mentioned in a previous email, how to handle multi-layer in a single signaling session has not been done before.  A solution will address more than just the label format

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: RSVP OTN single stage vs multi stage

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: RSVP OTN single stage vs multi stage

What do folks think of the term nstacked hierarchical LSPso?  I think it is pretty evocative.

 

Sent from my iPhone

 

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

 

Jonathan,

 

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

 

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

 

Thanks,

 

John

 

Sent from my iPhone

 

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

 

Fatai,

 

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

 

As John mentioned in a previous email, how to handle multi-layer in a single signaling session has not been done before.  A solution will address more than just the label format

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp