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