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

From: [email-masked]
Date: Sun, 17 Jul 2005 22:36:06 +0200

igor - see in-line

beside this i welcome the serious re-writing effort provided by the authors compared to the previous version of this document

"Igor Bryskin" <[email-masked]>
Sent by: [email-masked]
07/17/2005 13:18 AST

To: <[email-masked]>, <[email-masked]>
cc: <[email-masked]>
bcc:
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

Arthi && JP.

I have a couple of questions.

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

[dp] purpose is imho on the control plane mechanism and from this perspective only point 4) remains - the effect of having a "logical" TE link -

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

[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

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

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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
> [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: Mon, 18 Jul 2005 08:06:19 -0400

Dimitri,

Thanks for the comments. However, I still want to hear from the authors, especially wrt purposes and intentions of this draft. I didn't see the stament that LSP stitching is purely control plane feature( which is NOT IMO, just like LSP Hierarchy it has control and data plane sides). Neither I read that the intention of this draft is to describe only the control plane side. 

Furthermore, I suggest not to use terms "FA-LSP" and "FA" in this draft. It is surely the intention (:=) to cover inter-domain scenario ( I can't imagine a practical reason for using stitching in a single TE domain). Recall, that according to LSP-HIER and according to discussions that we had (initiated, by the way, by you), LSP is FA-LSP *only* if it is advertised into the same domain where it was created, which is not the case in the TE inter-domain context.

See also comments in-line.

Igor  
  ----- Original Message ----- 
  From: [email-masked] 
  To: Igor Bryskin 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Sunday, July 17, 2005 4:36 PM
  Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

  igor - see in-line

  IB>> Agree, this a signifficant step in the right direction

  Arthi && JP.

  IB>> It is possible to imagine that a single e2e LSP triggers several parallel S-LSPs which could be advertised as a single TE link. Besides, it is even more easy to imagine that S-LSPs are pre-provisioned in one TE domain and advertised as bundles into other domains

  IB>> This is not true. If an S-LSP is advertised in a different domain, there needs to be a routing peering between the ends of the S-LSP in the domain it is advertised in order for the S-LSP to be used as a TE link. There is no difference here compared to Hierarchical LSP (H-LSP)

  Cheers,
  Igor

  ----- Original Message -----
  From: <[email-masked]>
  To: <[email-masked]>
  Cc: <[email-masked]>
  Sent: Friday, July 15, 2005 3:50 PM
  Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

  directories.
  Engineering
  message.
  username

---

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

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.

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

---

From: Arthi Ayyangar <[email-masked]>
Date: Mon, 18 Jul 2005 12:20:01 -0700 (PDT)

Igor,

> Thanks for the comments. However, I still want to hear from the authors,
> especially wrt purposes and intentions of this draft.
                ^^^^^^^^^^^^^^^^^^^^^^^^
<AA>----> You among other folks in the WG very strongly requested that
such an ID be written and hence this portion was removed from the
inter-domain ID and written as a separate ID given that it has broader
scope. The way you are posing the question, it appears as if you have
some doubts now. :-)

I didn't see the
> stament that LSP stitching is purely control plane feature( which is NOT
> IMO, just like LSP Hierarchy it has control and data plane sides).
> Neither I read that the intention of this draft is to describe only the
> control plane side.
<AA>-----> I don't think Dimitri made a statement which said "LSP
stitching is a purely control plane feature". I believe his point was that
the "special case of lsp hierarchy" applies to the control plane aspect.

Anyway, LSP stitching involves both control and data plane aspects
(label related procedures) and the draft explains both the aspects, where
applicable. Is there a problem ?

> Furthermore, I suggest not to use terms "FA-LSP" and "FA" in this draft.
<AA>----> Good suggestion. The draft atleast to my knowledge does not use
these terms in the context of LSP stitching. If you find any specific
cases of this usage, please point them out to me and I will be happy to
address them.

thanks,
-arthi

> It is surely the intention (:=) to cover inter-domain scenario ( I can't
> imagine a practical reason for using stitching in a single TE domain).
> Recall, that according to LSP-HIER and according to discussions that we
> had (initiated, by the way, by you), LSP is FA-LSP *only* if it is
> advertised into the same domain where it was created, which is not the
> case in the TE inter-domain context.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 Jul 2005 22:23:17 +0100

Hi,

[[email-masked] and [email-masked] omitted from the cc
list]

[SNIP]

> <AA>----> I tend to agree with this.

Yes. If there is a need to compare the two techniques or to do
applicbality then that is another I-D. I am not sure that there is a need.

I would like to see this I-D restricted, as Arthi said, to a description
of what Stitching is and how it works.

> segment. That can be clarified.

Say rather, "can be admitted over a TE link supported by LSP segments".
That is, a segment can only admit one LSP, but a bundle of segments
advertised as a TE link, can admit multiple LSPs.

A

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 19 Jul 2005 11:41:39 -0700 (PDT)

> advertised as a TE link, can admit multiple LSPs.
-----> Yes, this more accurate.

thanks,
-arthi