[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Hi Dimitri/Igor,
> beside this i welcome the serious re-writing effort provided by the
> authors compared to the previous version of this document
<AA>---> Thanks!
<snipped>
> [dp] i would simply recommend to state what an LSP segment is (as stated,
> this comparison has been used to show differences in terms of control
> plane processing and keeping it at that level is sensible) and not embark
> this document into terms and complex comparisons that are at the end of
> no real help
<AA>----> I tend to agree with this.
> 2. Why are you saying that a TE Link based on S-LSP can be used for
> exactly
> one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> (bundle, see above) and hence can accomadate several e2e LSPs.
>
> [dp] i think the purpose is to say that a "triggered" LSP segment can be
> used by a single end-to-end LSP compared to the situation occurring with
> FA, where the triggered FA-LSP can then carry multiple nested LSPs
<AA>------> As I mentioned in the email to Igor, the sentence immediately
following this does talk about the bundling case. What is missing is
probably an additional sentence which explicitly states that when such
bundling is use, more that one e2e LSP can be admitted over the LSP
segment. That can be clarified.
thanks,
-arthi
> 3. You are saying that S-LSP does not have a routing peering. Actually,
> in
> this respect it is no different from H-LSP: if it is advertised as a TE
> link
> into the same TE domain that was used for S-LSP creation (unlikely IMO
> scenario) than it does not require the routing adjacency (in other words,
> it
> is an FA according to LSP-HIER definition), otherwise, it IS NOT and FA
> and
> does require the direct routing peering in the domain it is advertised to
> make it useful as a TE link in this domain
>
> [dp] again the document correctly states that a routing adj. is not going
> to be established on the LSP segment
> Cheers,
> Igor
>
>
>
> ----- Original Message -----
> From: <Internet-Drafts@ietf.org>
> To: <i-d-announce@ietf.org>
> Cc: <ccamp@ops.ietf.org>
> Sent: Friday, July 15, 2005 3:50 PM
> Subject: 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-stitching-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.
> >
>
>
>