----- Original Message -----
Sent: Sunday, July 17, 2005 4:36 PM
Subject: Re: I-D
ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
igor - see in-line
beside this i welcome the serious re-writing
effort provided by the authors compared to the previous version of this
document
IB>> Agree, this a signifficant step in the
right direction
"Igor Bryskin" <ibryskin@movaz.com>
Sent by: owner-ccamp@ops.ietf.org
07/17/2005 13:18 AST
To: <i-d-announce@ietf.org>, <Internet-Drafts@ietf.org>
cc: <ccamp@ops.ietf.org>
bcc:
Subject: Re: I-D
ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Arthi && JP.
I have a couple of questions.
1. Why are saying that LSP Stitching is a private case
of LSP Hierarchy?
[dp] purpose is imho on the control plane
mechanism and from this perspective only point 4) remains - the effect of
having a "logical" TE link -
IMO there is more differences than
similarities:
The differences are:
1) In case of H-LSP there is a data
plane adjacency, while in case of S-LSP
there is none (as you correctly
pointed out);
2) In case of H-LSP there is an adaptation in data plane
(label push/pop for
PSC), while in case of S-LSP there is none - just
simple cross-connecting
( label swap) as in case of two "native " e2e LSP
adjacent segments ;
3) H-LSP could be used by many e2e LSPs, while S-LSP
could be used by
exactly one e2e LSP
4) Signaling is different - there
is no label negotiation in stitching
5) H-LSP is used as a "true" data
link, specifically there is a resource
allocation on the H-LSP edges, while
in case of S-LSP there is none
6) From MLN point of view, H-LSP is created
in a server (lower) layer, while
the S-LSP is created in the client (same
as e2e LSP) layer.
There are two
similarities that I can think of:
1) There is a signaling and possibly
routing (see below) adjacencies between
the ends;
2) Both H-LSP and
S-LSP could be advertised as separate TE links or as TE
bundles
I
would recommend to dedicate a paragraph and enlist there similarities
and
differencies
[dp] i would simply recommend to state what an
LSP segment is (as stated, this comparison has been used to show differences
in terms of control plane processing and keeping it at that level is sensible)
and not embark this document into terms and complex comparisons that are at
the end of no real help
2. Why are you saying that a TE Link based on
S-LSP can be used for exactly
one e2e LSP? Parallel S-LSPs could be
advertised as a single TE link
(bundle, see above) and hence can accomadate
several e2e LSPs.
[dp] i think the purpose is to say that a
"triggered" LSP segment can be used by a single end-to-end LSP compared to the
situation occurring with FA, where the triggered FA-LSP can then carry
multiple nested LSPs
IB>> It is possible to imagine that a
single e2e LSP triggers several parallel S-LSPs which could be advertised
as a single TE link. Besides, it is even more easy to imagine that S-LSPs are
pre-provisioned in one TE domain and advertised as bundles into other
domains
3. You are saying that S-LSP does not have a routing peering.
Actually, in
this respect it is no different from H-LSP: if it is
advertised as a TE link
into the same TE domain that was used for
S-LSP creation (unlikely IMO
scenario) than it does not require the routing
adjacency (in other words, it
is an FA according to LSP-HIER definition),
otherwise, it IS NOT and FA and
does require the direct routing
peering in the domain it is advertised to
make it useful as a TE link in
this domain
[dp] again the document correctly states that
a routing adj. is not going to be established on the LSP segment
IB>> This is not true. If an S-LSP is
advertised in a different domain, there needs to be a routing peering between
the ends of the S-LSP in the domain it is advertised in order for the S-LSP to
be used as a TE link. There is no difference here compared to Hierarchical LSP
(H-LSP)
Cheers,
Igor
----- Original Message -----
From:
<Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc:
<ccamp@ops.ietf.org>
Sent: Friday, July 15, 2005 3:50 PM
Subject:
I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> A New Internet-Draft is available from the on-line
Internet-Drafts
directories.
> This draft is a work item of the
Common Control and Measurement Plane
Working Group of the
IETF.
>
> Title : Label Switched Path Stitching with Generalized
MPLS Traffic
Engineering
> Author(s) : A. Ayyangar, J.
Vasseur
> Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> Pages
: 19
> Date : 2005-7-15
>
> In certain scenarios, there may
be a need to combine together two
> different Generalized
Multi-Protocol Label Switching (GMPLS) Label
> Switched
Paths (LSPs) such that in the data plane, a single end-to-
>
end (e2e) LSP is achieved and all traffic from one LSP is
switched
> onto the other LSP. We will refer to this
as "LSP stitching". This
> document covers cases
where: a) the node performing the stitching
> does not
require configuration of every LSP pair to be stitched
>
together b) the node performing the stitching is not the egress
of
> any of the LSPs c) LSP stitching not only results in
an end-to-end
> LSP in the data plane, but there is also a
corresponding end-to-end
> LSP (RSVP session) in the
control plane. It might be possible to
> configure a
GMPLS node to switch the traffic from an LSP for which it
>
is the egress, to another LSP for which it is the ingress,
without
> requiring any signaling or routing extensions
whatsoever, completely
> transparent to other nodes.
This will also result in LSP stitching
> in the data
plane. However, this document does not cover this
>
scenario of LSP stitching.
>
> A URL for this Internet-Draft
is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
>
>
To remove yourself from the I-D Announcement list, send a message to
>
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>
to change your subscription settings.
>
>
> Internet-Drafts
are also available by anonymous FTP. Login with the
username
>
"anonymous" and a password of your e-mail address. After logging in,
>
type "cd internet-drafts" and then
> "get
draft-ietf-ccamp-lsp-stitching-01.txt".
>
> A list of
Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
Internet-Drafts can also be obtained by e-mail.
>
> Send a message
to:
> mailserv@ietf.org.
> In the body type:
> "FILE
/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
>
> NOTE:
The mail server at ietf.org can return the document in
> MIME-encoded
form by using the "mpack" utility. To use this
> feature, insert
the command "ENCODING mime" before the "FILE"
> command. To decode
the response(s), you will need "munpack" or
> a MIME-compliant mail
reader. Different MIME-compliant mail readers
> exhibit different
behavior, especially when dealing with
> "multipart" MIME messages (i.e.
documents which have been split
> up into multiple messages), so check
your local documentation on
> how to manipulate these
messages.
>
>
> Below is the data which will enable a MIME
compliant mail reader
> implementation to automatically retrieve the
ASCII version of the
>
Internet-Draft.
>