[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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? 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
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.
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
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.
>