it is "no" to all the below a), b) and c) - as
logical consequence of the current GMPLS architecture
note: to clarify one of my note here below
(where it seems you were not in agreement) about PSC LSP bandwidth and segment
stitching i.e. larger bandwidth reservation for the segment than for the
end-to-end LSP does not mean different PSC level (note: PSC-1, -2, -3 and -4
are not "layers" they should simply be referred to as levels but this is
another discussion) so i wanted to clarify that the default admission control
rules for the packet case - within the same PSC level - could be relaxed
compared to the other switching technologies without stretching the stitching
concept
IB>> My question c) was:
c) Is it possible
(should we allow) to stitch PSC1 e2e LSP by a PSC2 LSP segment
?
If you say NO to this question, than the answer
contradicts to what you said above in your note.
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 -