[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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".
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.
> > >
> >
>