Re: LSP stitching questions for discussion

[Arthi Ayyangar <arthi@juniper.net>]

Thanks Dimitri, Igor and Adrian for posting your answers.

There seems to be agreement that the procedures are applicable to both
PSC and non-PSC LSPs. Good.

As expected, the main disagreement is whether stitching should or should
not be allowed when region boundaries (SC based) are traversed. I
tend to agree with Dimitri and Igor on this. Just because it is possible,
doesn't mean it should be allowed, especially given that one can use
hierarchical LSPs for this purpose.

However, to Adrian's point about "declaring a specific hardware
deployment illegal in the control plane", it would be useful to understand
this scenario wrt what is done in data plane and in control plane and is
there any benefit of this behavior.

I will try to capture this discussion in the presentation at the WG
meeting.

thanks,
-arthi

> [dp] ok - last try for an end-to-end PSC-1 LSP of 2MB you could make use
> of a PSC-1 segment of 4MB
>
> Ah, Ok. I see your point and agree.
>
> Igor
>
>
> You are right: whether PSC1 and PSC2 are separate network layers or not
> is a topic of a separate (painful :=)) discussion. However, I just
> wanted to point out here that a PSC2 LSP is a provisioned as such for a
> reason: it is meant to *nest* PSC1 LSPs rather than to stitch them. From
> the VNT management point of view PSC2 and PSC1 are separate topological
> layers. that is PSC2 produces topology for PSC1, just like VC4 produces
> topology for VC12. The only difference is that in the latter case this
> relationship is forced by the hardware, and in the former case is not
> (just logical). Take for example C and C++ programming. Certain things
> you simply forced not to do in C++, whereas in C you could but
> shouldn't.
>
> See you in Paris.
> Igor
>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> Sent by: owner-ccamp@ops.ietf.org
> 07/20/2005 13:25 AST
>
> To: "Arthi Ayyangar" <arthi@juniper.net>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: <ccamp@ops.ietf.org> bcc:
> Subject: Re: LSP stitching questions for discussion
>
>
> Dimitri,
>
> It seems to me that I mostly agree(?!) with what you wrote in this mail.
> I'd still want to confirm your views on the following questions:
>
>
> a) Is it possible (should we allow) to stitch PSC1 e2e LSP by a LSC LSP
> segment ?
>
> b) Is it possible (should we allow) to stitch VC12 e2e LSP by a VC4 LSP
> segment ?  c) Is it possible (should we allow) to stitch PSC1 e2e LSP by
> a PSC2 LSP segment ?
>
> My answers are NO to all three questions. You can sticth PSC1 with PSC1,
> VC12 with VC12, etc. In all other cases you need, first, to setup a
> hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or not
> (multi-domain)) in order to create a data link of the e2e LSP switching
> capability and only after that you can also use a stitching segment on
> top of this H-LSP).
>
> See also in-line.
>
> Igor
>
>
> ----- Original Message -----
> From: Dimitri.Papadimitriou@alcatel.be
> To: Arthi Ayyangar
> Cc: Igor Bryskin ; ccamp@ops.ietf.org
> Sent: Wednesday, July 20, 2005 4:46 AM
> Subject: Re: LSP stitching questions for discussion
>
> arthi,
>
>
>
> first a recap: this item on stitching was initiated in order to allow
> per "domain" control of end-to-end (contiguous) LSP, as part of a
> separate document, and not to extend its scope (unduly, in this case,
> see below) but mainly in order to have the set of all related protocol
> mechanisms within a specific document -
>
>
>
> from this initial working assumption, it is clear that the segment must
> have the properties of the incoming end-to-end LSP which are determined
> among other by its switching type e.g. PSC-3 or TDM, the first
> requirement of LSP stitching is contiguity of the end-to-end LSP at the
> data plane level (after stitching operation) - and this by definition of
> the initial working assumption -
>
> IB>> Agree
>
> note: the only latitude which is left (for a given switching type e.g.
> PSC-2) is due to the properties of packet (PSC) networks that allows you
> stitch a segment having a larger Max Reservable Bandwidth and Unreserved
> Bandwidth (we would have equivalent latitude for other attributes but
> this is a local policy decision - which at the end is the sole purpose
> of this approach)
>
> IB>> Disagree. Conceptually PCS1 and PSC2 are different layers and the
> latter cannot stitch the former, just like in case VC12 and VC4. You
> should nest PSC1 within PSC2 instead.
>
>
>
> Here are some of the questions related to LSP stitching to start a
> discussion on the usage of LSP stitching.
>
> >1) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >packet LSPs in data plane
>
>
> -> yes (beside manual config operation)
>
> IB>> Agree
>
>
> >2) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >non-packet LSPs in data plane ?
>
>
> -> yes (beside manual config operation)
>
> IB>> Agree
>
>
> >3) If an e2e LSP crosses a region boundary (based on different TE
> >link switching capabilities), then can I use LSP stitching
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
>
> -> no, when crossing a region boundary, you simply use a document named
> "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor queue, but
> this does not prevent from creating an LSP segment on top of an FA-LSP
> (see below)
>
> IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to
> cover single and multi-domain scenarios
>
>
> >4) If the switching type of an e2e LSP is different from that of an LSP
> >segment, can I use LSP stitching
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
>
> -> no, in this case progression of the end-to-end LSP establishment,
> implies that the LSP segment must fulfil a set of constraints carried as
> part of the incoming end-to-end LSP request, in this case one has to
> create an LSP segment (with a switching type equal to the incoming
> end-to-end LSP switching type) over that FA (i.e. referred here above to
> the LSP segment with a different Switching Type)
>
>
> IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to
> cover single and multi-domain scenarios
>
> Cheers,
>
> Igor
>
> >Note that although 3) and 4) appear to be the same, the reason I have
> >them as different questions is that in one case the TE link switching
> >capability is examined and in the other case the Generalized Label Request
> >is examined.
>
>
>
> -> what it appears to me is that this discussion mixes the issue of the
> operation describing the stitching operations at the domain boundaries
> from the LSP segment creation itself i.e. an LSP segment can indeed be
> an FA link inherited from the creation of an (intra-domain) FA-LSP -
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com