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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 28 Jul 2005 10:00:25 +0200

Hi Arthi, JP

Thanks for this new revision that sounds really good

I have two commments:

-In section 4.1.2 you partially describe bidirectional LSP stitching procedure.
You mention that an Upstream Label MUST NOT be allocated by the end-to-end LSP on the LSP segment, which is OK.
But then how the LSP-Segment Egress will now that the end-to-end LSP is bidirectional? What about defining a flag in the Attributes Flags TLV of the LSP_ATTRIBUTE object so as to indicate that the LSP is bidirectional?
Also the selection of the LSP segment in case of bidirectional LSP should be detailed (e.g. If the end-to-end LSP is bidirecitonal then 
the LSP-segment MUST be bidirectional. Also shall we allow that two unidrectional end-to-end LSP use the same bidirectional LSP segment (one in each direction)?

-At the end of section 4.2.5 you mention that LSP-Segment failure or maintenance SHOULD be treated as a failure event for the end-to-end LSP. I agree for LSP-Segment failure but not for LSP-Segment maintenance. LSP-Segment maintenance should be treated as TE-link maintenance for the end-to-end LSP, and procedures defined in GMPLS graceful TE-link shutdown draft may be useful (Specific RSVP error code and TE-link attribute)...

Hope this helps,

Best Regards

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : vendredi 15 juillet 2005 21:50
> À : [email-masked]
> Cc : [email-masked]
> Objet : 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-stitc
hing-01.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-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:
> 	[email-masked].
> 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.
>

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 28 Jul 2005 09:16:56 -0700 (PDT)

Hi JL,

Thanks for the comments.

> -In section 4.1.2 you partially describe bidirectional LSP stitching
> procedure. You mention that an Upstream Label MUST NOT be allocated by
> the end-to-end LSP on the LSP segment, which is OK. But then how the
> LSP-Segment Egress will now that the end-to-end LSP is bidirectional?
AA--------> Excellent point.

> What about defining a flag in the Attributes Flags TLV of the
> LSP_ATTRIBUTE object so as to indicate that the LSP is bidirectional?
AA------> That would be a change to the processing that GMPLS nodes use to
detect bidirectionality, isn't it ? Normally nodes look for the Upstream
Label object to detect bidirectionality.

So let us say that an LSP is bidirectional if a) an Upstream Label is
present or b) no Upstream Label, but bit set in LSP_ATTRIBUTE or c) both
However, reliance on an e2e attributes bit set by head end, means existing
head ends will not be setting this bit, so that will be an issue (wrt
compatibility).

Could be nice if this signaling was just between the node doing the
stitching and the end point of the LSP segment, since this is the hop that
the bidirectionality information is lost. Let me think about this.

> Also the selection of the LSP segment in case of bidirectional LSP
> should be detailed (e.g. If the end-to-end LSP is bidirecitonal then the
> LSP-segment MUST be bidirectional. Also shall we allow that two
> unidrectional end-to-end LSP use the same bidirectional LSP segment (one
> in each direction)?
AA----> Yes, this should be okay. IMO.

> -At the end of section 4.2.5 you mention that LSP-Segment failure or
> maintenance SHOULD be treated as a failure event for the end-to-end LSP.
> I agree for LSP-Segment failure but not for LSP-Segment maintenance.
> LSP-Segment maintenance should be treated as TE-link maintenance for the
> end-to-end LSP, and procedures defined in GMPLS graceful TE-link
> shutdown draft may be useful (Specific RSVP error code and TE-link
> attribute)...
AA---> Yes, I agree; we will mention this. Actually the graceful teardown
sentence occurs few paragraphs before, but not in the right context. So we
will clarify the above.

> Hope this helps,
AA--->  Sure does.

Thanks!

-arthi

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2005 11:08:19 +0200

Hi Jean-Louis,

Thanks for the useful comments. We plan to submit a new revision  
(including answer to Adrian's comments also) right after this IETF.

Cheers

JP.

On Jul 28, 2005, at 10:00 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> You mention that an Upstream Label MUST NOT be allocated by the end- 
> to-end LSP on the LSP segment, which is OK.
> But then how the LSP-Segment Egress will now that the end-to-end  
> LSP is bidirectional? What about defining a flag in the Attributes  
> Flags TLV of the LSP_ATTRIBUTE object so as to indicate that the  
> LSP is bidirectional?
> should be detailed (e.g. If the end-to-end LSP is bidirecitonal then
> the LSP-segment MUST be bidirectional. Also shall we allow that two  
> unidrectional end-to-end LSP use the same bidirectional LSP segment  
> (one in each direction)?
>
> -At the end of section 4.2.5 you mention that LSP-Segment failure  
> or maintenance SHOULD be treated as a failure event for the end-to- 
> end LSP. I agree for LSP-Segment failure but not for LSP-Segment  
> maintenance. LSP-Segment maintenance should be treated as TE-link  
> maintenance for the end-to-end LSP, and procedures defined in GMPLS  
> graceful TE-link shutdown draft may be useful (Specific RSVP error  
> code and TE-link attribute)...
>
> Hope this helps,
>
> Best Regards
>
> JL
>
>
>