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

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



Hi Arthi,

Please see inline 

> -----Message d'origine-----
> De : Arthi Ayyangar [mailto:arthi@juniper.net] 
> Envoyé : jeudi 28 juillet 2005 18:17
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : ccamp@ops.ietf.org; jpv@cisco.com
> Objet : RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
> 
> 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 
> AA------> 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).

JLLR: I agree this may raise some backward compatibility issues.
This would require that head-ends be upgraded...

> 
> 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.

JLLR: Yes, and what about defining a new MPLS label value, let say label 4 = "No label assigned", with a semantic distinct from label 3 semantic (=label pop). The UPSTREAM label object with this new label value  would be included in the end-to-end Path message over the LSP-Segment...

Let discuss this point during Paris meeting,

Regards,

JL

> 
> 
> > 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 
> AA---> 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
> 
> >
> >
> > > -----Message d'origine-----
> > > De : owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] De la part de 
> > > Internet-Drafts@ietf.org Envoyé : vendredi 15 juillet 
> 2005 21:50 À : 
> > > i-d-announce@ietf.org Cc : ccamp@ops.ietf.org 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 
> > > 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.
> > >
> >
>