[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt



hi arthi and jp,

by reading this e-mail, i have several comments:

- section 3: why a TE link is to be associated to an LSP segment since at the end the segment exists only within the context of the end-to-end that triggers it, i.e. re-use of a segment is anyway not possible once created (unreserved bandwidth set to 0) so why other nodes would need to know about its existence ? other sections in this document do also refer to this but (see for inst. section 5.2) if the network sees the LSP segment as a TE link in their TE databases what does "computation of a path over this TE link." exactly means ?

- section 4: mentions "Although not adjacent in routing, the end nodes of the LSP segment will have a signaling adjacency and will exchange RSVP messages directly between each other." it would be interesting that you define what you mean by signaling adj. because imho such an adj. is based on the permanent exchange of hello msg

- section 4: the main difference between signaling an LSP over an LSP segment instead of over an FA-LSP is that no Labels are allocated and
exchanged for the e2e LSP over the LSP segment hop -> therefore there is a specific configuration/usage of the label_request object when signaling the end-to-end LSP (as well as the upstream label for bi-dir LSP) to be detailed here


- section 5.1: mentions "Similar to setup, tearing down the LSP segment may also be decided either via local configuration or due to the fact that there is no longer an e2e LSP stitched to the LSP segment." it would be interesting to detail the deletion sequence when initiated from the end-to-end LSP head-/tail-end and stitching head-/tail-end

thanks,
- dimitri.

Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title : LSP Stitching with Generalized MPLS TE Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ayyangar-ccamp-lsp-stitching-00.txt Pages : 12 Date : 2005-2-14 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-ayyangar-ccamp-lsp-stitching-00.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-ayyangar-ccamp-lsp-stitching-00.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-ayyangar-ccamp-lsp-stitching-00.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.


------------------------------------------------------------------------

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce