Subject: Re: LSP stitching questions for discussion

From: [email-masked]
Date: Wed, 20 Jul 2005 10:46:49 +0200

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 -

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)

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)

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

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Jul 2005 12:28:48 +0100

Hi all,

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

I partially agree.
I would say that stitching was first introduced in the context of
per-domain control of end-to-end LSPs, but that it quickly became apparent
that stitching was an entity in its own right. That is, stitching is a
control plane and data plane technique.
I wanted to separate the function from the applicability, and in
particular I wanted to make sure that the function was not burried inside
an inter-domain I-D that would hide the function and potentially limit its
applicability.
Thus, the chairs insisted that the work was pulled out into a separate I-D
that, as you say, has 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 -

Well, you'll note that I did not quite agree with your initial working
assumption. I am one of those people that fit into the category that Igor
outlined: I believe that it is technically possible to stitch a segment of
a lower layer between two segments of a higher layer. This is *far* from
saying that I can see a good reason to do this.
Indeed, it seems that the mechanisms we are developing say that when
domains exist in distinct layers we would normally use hierarchical LSPs,
and when domains exist in the same layer we would use stitched LSPs.
We should think carefully, however, before specifying in the control plane
that a specific hardware dpleoyment is illegal.

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

I must ask "why not?"
If the answer is that it cannot be done in hardware, I think this is
incorrect.
If the answer is that it does not need to be done because hierarchical
LSPs exist, then I can buy that argument, but only because I cannot think
of a reason to use stitched segments in this way.

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

I don't see any difference between questions 3 and 4 notwithstanding the
explanatory paragraph below.

Please note that, given the appropriate adaptation capabilities I can
advertise an LSP that crosses a lower layer as a TE link in a higher
layer. When I do this, I advertise the switching capabilities of the TE
link as those of the higher layer, not the lower layer.

The same technique could be applied for stitching segments (provided
suitable adaptation exists). Agreed this might represent a waste of
bandwidth in the lower layer. Agreed there appears to be no reason to do
this when hierarchical LSPs can be created.

I just want to separate requirements/desires from technical possibilities.

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

Yes. It is worth noting that if you create a hierarchical LSP *within* a
domain, you have necessarily created a layer (or region) boundary.
If you create a stitching segment within a domain, you do not do this.

Layer boundaries may not be important in PSC networks since PSC1 and PSC2
are very similar. But layer boundaries are really important in TDM, LSC
and FSC networks. In these cases stitching segments within the layer may
play an important role for domain sub-division.

Adrian

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 20 Jul 2005 13:25:19 -0400

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: [email-masked] 
  To: Arthi Ayyangar 
  Cc: Igor Bryskin ; [email-masked] 
  Sent: Wednesday, July 20, 2005 4:46 AM
  Subject: Re: LSP stitching questions for discussion

  arthi, 

  IB>> Agree

  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.

  IB>> Agree

  IB>> Agree

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios

  Cheers,

  Igor