Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt

From: Adrian Farrel <[email-masked]>
Date: Thu, 13 Jul 2000 14:44:43 +0100

Oops.  now sending the entire message!

This appears to bring RSVP into line with CR-LDP so that only one level of
label can be signaled.  

Label stacking is not prevented by this approach, it simply narrows the
options towards the commonly implemented ways of label stacking (for example
signaling down the tunnel).

Regards,
Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: Laurel - Ganesh Murugesan 
>Sent: Thursday, July 13, 2000 2:02 PM
>To: Rahul Aggarwal; George Swallow
>Cc: [email-masked]
>Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt
>
>
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of Rahul
>> Aggarwal
>> Sent: Wednesday, July 12, 2000 5:07 PM
>> To: George Swallow
>> Cc: Rahul Aggarwal; [email-masked]
>> Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt
>> 
>> 
>> George,
>> Thanks for the comments. I have a couple of inline comments:
>> 
>> Also I just realized that the new draft has limited the contents 
>> of the label
>> object to a single label, rather than a stack of labels. What is 
>> the reason
>> for this limitation? 
>> 
>
>====> But Section 1.1 Background 2nd paragraph says 
>      "Label stacking is also supported."
>
>thanks
>ganesh
>

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Thu, 13 Jul 2000 09:54:27 -0400

Adrian,

I agree the single level label specifies that only one label can be
signaled.
My point is then RSVP-TE has nothing to do with Label Stacking and that line
of text shouldn't be there.

thanks
ganesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Adrian
> Farrel
> Sent: Thursday, July 13, 2000 9:45 AM
> To: Laurel - Ganesh Murugesan; Rahul Aggarwal; George Swallow
> Cc: [email-masked]

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 13 Jul 2000 09:56:26 -0700

> signaling down the tunnel).

There could be different ways of doing label stacking. Hence label stacking is
not prevented by this approach. However I don't seen a reason for removing the
flexibility of signaling multiple labels with RSVP in the label object. The
earlier draft stated 'For implementations that do not support a label stack,
only the top label is examined. The rest of the label stack SHOULD be passed
through unchanged'. That seems like a reasonable approach to me.

It will be nice to hear from the authors what their reasons/motivations are
for making this change.

thanks,
rahul

---

From: George Swallow <[email-masked]>
Date: Thu, 13 Jul 2000 13:20:49 -0400

Rahul -

> It will be nice to hear from the authors what their reasons/motivations are

We removed the 'PoP' operator at the time of the wg last call.  It was
not well defined and no one had a use for it.  A label stack would be
required with that.  Once that was removed the label stack became a
mechanism with no procedures or uses defined.  That seems only to be a
recipe for encouraging non-interoperability.

Further folks working on the optical extensions, particularly
forwarding adjacnecies, found that they had no need of attempting to
set up more than one level of 'labeling' at a time.  

So we removed it.  

If someone comes forward with a genuine, well defined need, it's a
very simple matter to add another C-type to allow a stack.  

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 13 Jul 2000 10:33:40 -0700

George,

> very simple matter to add another C-type to allow a stack.  

Thanks for the clarification. This seems reasonable.