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

From: [email-masked]
Date: Fri, 15 Jul 2005 15:50:03 -0400

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Sun, 17 Jul 2005 13:18:24 -0400

Arthi && JP.

I have a couple of questions.

1. Why are saying that LSP Stitching is a private case of LSP Hierarchy? IMO
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

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.

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

Cheers,
Igor

---

From: Arthi Ayyangar <[email-masked]>
Date: Mon, 18 Jul 2005 11:51:57 -0700 (PDT)

Hi Igor,

Please see inline.

> 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?

> I would recommend to dedicate a paragraph and enlist there similarities and
-------> 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.

> (bundle, see above) and hence can accomadate several e2e LSPs.
----> Igor, the draft does talk about this Bundling case.

> 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

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 18 Jul 2005 17:47:37 -0400

Arthi,

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 18, 2005 2:51 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

> are applicable or inapplicable.

IB>> I see a problem here. Since we do not have another draft providing the
tight definition of LSP stitching, it is not good enough to describe it in
some light narrative manner. In section 1 you are saying:

1.  Introduction

LSP stitching is a special case of LSP hierarchy.  In case of LSP
   stitching, instead of an FA LSP, an "LSP segment" is created between
   two GMPLS nodes ....

I don't think  that "LSP stitching is a special case of LSP hierarchy". The
two mechanism have some remote IMO resemblance in control plane and have
nothing in common in the data plane. The biggest difference is that the
stitching happens within the same network layer and hence in sharp contrast
to LSP hierarchy does not require reconfigurations in lower (fat pipe)
layer(s). Just because of that the stitching could be much more attractive
mechanism for control plane. At least there will be no questions like " Who
is going to pay for unused bandwidth?"
Anyway, all I asked was for a small paragraph summarizing similarities and
differences of both planes. That IMO would help.

One more point. You use terms FAs and FA-LSPs everywhere in the draft. This
is confusing because what you really mean hear is Hierarchical LSPs (H-LSPs)
and TE links enabled by H-LSPs.  As I mentioned earlier, there is no place
for these terms in your draft because it mostly concerns about TE
inter-domain scenarios, while [LSP-HIER] has a focus on a single domain and
strictly mandates the LSP to be advertised into the *same* domain to be
considered as FA-LSP

> ----> Igor, the draft does talk about this Bundling case.

IB>> My problem here is with the statement from section 2:

"An LSP segment TE link SHOULD NOT admit more than one e2e LSP into
  it. "  You do describe the bundling, which contradicts the statement
above. It may accept as many e2e LSPs as it has component links

> obvious" ? It is unclear to me  what exactly your argument is. Please

IB>> To be more clear I should say the following. If an LSP segment is
advertised into a different TE domain it SHOULD have a routing peering
between the ends in the domain it is advertised, otherwise, it could not be
used as a TE link in this domain. This is because generally speaking the
data plane connectivity does not guarantee control plane connectivity in the
domain the link is advertised, and in GMPLS a connection could not be used
as a TE link without control channel connecting nodes handling the link. The
same applies to hierarchical LSPs as well. The exception is LSP (stitching
or hierarchy) advertised into the same domain, in this case it is FA-LSP and
does not need direct routing peering to be used as a TE link.

Cheers,
Igor

> > > [email-masked] with the word unsubscribe in the body of
the
> > message.

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 19 Jul 2005 10:24:35 -0400

Arthi,

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.

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?"

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.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>

the

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 19 Jul 2005 16:07:49 -0700 (PDT)

Hi Igor,

> is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.
<AA>---> I do remember this discussion.

> somebody wants to do a trick stupid as it is, why should we prevent him from
<AA>----> I know some of these people too. :-)

> in the frame of this work.
<AA>------> 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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 20 Jul 2005 11:18:37 -0700 (PDT)

Thanks, sounds like a good idea.
 
Igor

Arthi Ayyangar <[email-masked]> wrote:
Hi Igor,

> is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.
---> I do remember this discussion.

> somebody wants to do a trick stupid as it is, why should we prevent him from
----> I know some of these people too. :-)

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

thanks,
-arthi

> From: "Arthi Ayyangar" 
> To: "Igor Bryskin" 
> Cc: ; ;
> > > From: 
> > > To: 
> > > Cc: 

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