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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 1 Aug 2005 10:08:17 +0200

Hi Adrian,

See inline

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : samedi 30 juillet 2005 11:30
> À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Objet : Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> 
> Hi, 
> 
> Time for me to speak out about the omission of hitherto 
> mandatory objects from signaling messages. 
> 
> I would MUCH prefer that you keep the objects (Upstream Label 
> or Path, Label on Resv) and use a special label value 
> (implicit null? some new reserved label value?) to mean 
> "stitch this". 

I agree with you. 
Actually this is what I suggested in the previous email, see below

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

Regards,

JL

> 
> For me this is more natural and is less of a significant 
> change to the existing protocol and implementation. 
> 
> It also solves the bidirection problem. 
> 
> Opinions? 
> 
> Cheers,
> Adrian 
> 
> 
>  ----- Original Message -----
> From: <[email-masked]>
> To: "LE ROUX Jean-Louis RD-CORE-LAN" 
> <[email-masked]>
> Cc: "Arthi Ayyangar" <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Sent: Friday, July 29, 2005 9:39 PM
> Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
> 
> 
> >
> > hi j-l, arthi
> >
> >
> > > > -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... 
> >
> >
> > DP: the other issue is having two methods for indicating the same 
> > thing
> is also not advisable
> > 
> >
> > > 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...
> > 
> >
> > DP: assuming an information has to be passed for the indicating this
> capability i do also think a method like passing an implicit 
> indication in the upstream label value would be more 
> appropriated (note that the initial issue is due to the fact 
> one would allow for unidirectional e2e LSP making use of 
> bidirectional LSP segments - see comment from J-L here below 
> - and not maintaining a 1:1 relationship for the 
> directionality between the e2e LSP and the LSP segment that 
> can be retrieved with the procedure described in section 
> 4.2.4 - and so the first question is it worth allowing 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 
> > > AA---> teardown
> > > sentence occurs few paragraphs before, but not in the 
> right context. 
> > > So we will clarify the above.
> >
> >
> > DP: i am not sure to understand the comment, the sentence 
> speaks about
> deletion of the LSP segment due to failure/maintenance should 
> be treated as a failure event for the e2e LSP, so i don't 
> think the initial sentence was meant to translated the 
> initial comment, anyway it would be of interest that you 
> detail the error code
> >
> > DP: note also that section 4.2.5 indicates that for stitched LSPs
> Graceful deletion can be used - i perfectly agree - but the 
> sequence should be detailed as part of this section
> > 
> >
> > > > Hope this helps,
> > > AA--->  Sure does.
> > >
> > >
> > > Thanks!
> > >
> > > -arthi
> > >
> > > >
> > > >
> > > > > -----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.
> > > > >
> > > >
> > > 
> >
> 
>