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

[Igor Bryskin <i_bryskin@yahoo.com>]

Thanks, sounds like a good idea.

 

Igor

Arthi Ayyangar <arthi@juniper.net> wrote:

Hi Igor,

> One more comment. I think the draft should give a clear and unambiguous
> answer to how e2e LSP and a stitching LSP (S-LSP) relate from the switching
> capability point of view. Specifically, should they belong to the same
> network layer, should they share the same switching type or maybe there are
> no limitations at all, and you can stitch your e2e LSP pretty much with
> anything you got, provided that this "anything" has enough bandwidth.
>
> Let me give you a specific example. Is it possible to stitch a PSC1 e2e LSP
> with a PSC2 S-LSP? You probably remember our discussion with Kireeti in
> Minneapolis (and you were also part of it), and he said (and I 100% agree
> with him) that although it is doable (you can do anything you want with the
> label stack), it is not right and this should be logically prohibited. What
> you should do in this case is to nest the e2e LSP within the PSC2 LSP (that
> is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.
---> I do remember this discussion.


> It is more clear in non-PSC cases. Although it is possible to "stitch" an
> e2e VC12 LSP with a VC4 S-LSP, I could not imagine that a network operator
> would ever agree with such solution. He is likely to say " What ? If the
> service is supposed to stay for 12 month, than for entire year I pretty much
> burry my 62 VC12 channels - I cannot use them even conceptually in case
> when, say, on the next day I'll have to provide another 62 VC12 services
> that could've used these wasted resources"
>
> On the other hand I know plenty GMPLS people who would say: "Sure, no
> problem. Of course we can stitch a PSC e2e LSP with lambda S-LSP: If
> somebody wants to do a trick stupid as it is, why should we prevent him from
> doing so?"
----> I know some of these people too. :-)

> The bottom line is that a discussion like this in the draft and consensus
> on how we see the stitching IMO would be extremely valuable for the GMPLS
> multi-layer story, and I don't see a reason why this could not be achieved
> in the frame of this work.
------> I agree that we should have a discussion on this, but I would
like folks to have this discussion on the list first, which I thank
you for initiating.

Yes, the draft has to state clearly whether LSP stitching between
different switching capabilities is allowed or not. But it's more than
that. Currently, the draft talks about this under sections 3.1 and 4.1
and 4.1.2.

But, let us have this discussion on the list and we will be glad to add
what's missing (with required details) to the ID, depending on the
consensus reached. I will send out the questions to start the discussion
in the next email.

thanks,
-arthi

>
> ----- Original Message -----
> From: "Arthi Ayyangar"
> To: "Igor Bryskin"
> Cc: ; ;
>
> Sent: Monday, July 18, 2005 2:51 PM
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
> > Hi Igor,
> >
> > Please see inline.
> >
> > > 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
> >
> > > there is more differences than similarities:
> > > The differences are:
> > > 1) In case of H-LSP there is a data plane adjacency, while in case of
> S-LSP
> > > there is none (as you correctly pointed out);
> > > 2) In case of H-LSP there is an adaptation in data plane (label push/pop
> for
> > > PSC), while in case of S-LSP there is none - just simple
> cross-connecting
> > > ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> > > 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> > > exactly one e2e LSP
> > > 4) Signaling is different - there is no label negotiation in stitching
> > > 5) H-LSP is used as a "true" data link, specifically there is a resource
> > > allocation on the H-LSP edges, while in case of S-LSP there is none
> > > 6) From MLN point of view, H-LSP is created in a server (lower) layer,
> while
> > > the S-LSP is created in the client (same as e2e LSP) layer.
> > >
> > > There are two similarities that I can think of:
> > > 1) There is a signaling and possibly routing (see below) adjacencies
> between
> > > the ends;
> > > 2) Both H-LSP and S-LSP could be advertised as separate TE links or as
> TE
> > > bundles
> > >
> > > I would recommend to dedicate a paragraph and enlist there similarities
> and
> > > differencies
> > -------> Based on the discussions on the list over the last revision, the
> > message that the authors received was that we do not want to go about such
> > a lengthy discussion of similarities and differences (NOTE that the draft
> > already does clearly highlight them where applicable). Instead we want
> > this ID to simply explain how LSP stitching functions. In other words the
> > idea was to make this ID a complete document by itself. But since it does
> > borrow concepts from the LSP hierarchy ID, just state the concepts that
> > are applicable or inapplicable.
> >
> > > 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.
> > ----> Igor, the draft does talk about this Bundling case.
> >
> > > 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
> > -----> I am sorry, but I am missing your point here completely. Are you
> > saying that the statement "the end points of an LSP segment do not have a
> > routing adjacency", is incorrect or are you saying that "this is
> > obvious" ? It is unclear to me what exactly your argument is. Please
> > clarify.
> >
> > thanks,
> > -arthi
> >
> > >
> > > Cheers,
> > > Igor
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From:
> > > To:
> > > Cc:
> > > 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.
> > > >
> > >
> >
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com