Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt

From: [email-masked]
Date: Fri, 23 Sep 2005 15:50:01 -0400

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-02.txt
	Pages		: 19
	Date		: 2005-9-23
	
In certain scenarios, there may be a need to combine together
   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 realized 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 may 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-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-02.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.

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 26 Sep 2005 15:16:35 -0400

Hi.

I'd like to recognize the good effort by the authors to bring the document
into its current shape.

I have a few minor comments.

1. forwarding adjacency.

The term is used in a sense of a data plane adjacency between  two nodes
that could be used to send data directly to each other, which literally
means "forwarding adjacency" :=). Unfortunately the term is widely used in a
different sense - as a certain control plane quality of a TE link. I'd
recommend to use term "data plane adjacency" instead of "forwarding
adjacency" in this document.

2. regular, basic TE link

These terms are not clear and not defined anywhere. I'd suggest to use term
" TE link associated with statically configured data link(s)"

3.

"
E.g. one suggested usage in case of P2MP RSVP
   LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to
   an LSP segment between P2MP capable LSRs in the network.  The LSP
   segment would traverse legacy LSRs that may be incapable of acting as
   P2MP branch points, thereby shielding them from the P2MP control and
   data path.This statement is not quite accurate. Stitching segments as
well as H-LSPs help to use legacy non-P2MP capable (not branch incapable)
nodes as intermediate nodes of P2MP tunnels. This is not about branching
capability that legacy LSRs lack - this is about P2MP signaling capability.
Igor

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 27 Sep 2005 10:33:40 -0700 (PDT)

Hi Igor,

Thanks for your comments. See my replies inline. <AA>

> adjacency" in this document.
<AA>-----> I agree with your comment and in fact we started with the term 
data plane adjacency. But changed it to the well-established term of 
"forwarding adjacency". As you point out it also has a 
"well-established" control plane connotation...so to avoid any confusion 
we'll change this to data plane adjacency, where applicable.

> " TE link associated with statically configured data link(s)"
<AA>----> Okay.

> capability that legacy LSRs lack - this is about P2MP signaling capability.
<AA>---> Yes, this needs to be cleaned up. It was meant to deal with LSRs 
lacking P2MP control plane (signaling) capability.

thanks,
-arthi