[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Hi Adrian,
See inline
> -----Message d'origine-----
> De : Adrian Farrel [mailto:olddog@clara.co.uk]
> Envoyé : samedi 30 juillet 2005 11:30
> À : LE ROUX Jean-Louis RD-CORE-LAN; Dimitri.Papadimitriou@alcatel.be
> Cc : arthi@juniper.net; ccamp@ops.ietf.org; jpv@cisco.com;
> zzx-adrian@olddog.co.uk
> 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: <Dimitri.Papadimitriou@alcatel.be>
> To: "LE ROUX Jean-Louis RD-CORE-LAN"
> <jeanlouis.leroux@francetelecom.com>
> Cc: "Arthi Ayyangar" <arthi@juniper.net>;
> <ccamp@ops.ietf.org>; <jpv@cisco.com>
> 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 : 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.
> > > > >
> > > >
> > >
> >
>
>