The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Sep> msg00430



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Please remove (from Alias)

  • From: "Winbush, Walter" <walterw@UU.NET>
  • Date: Thu, 28 Sep 2000 06:43:45 -0400
  • Cc: mpls@UU.NET

Please remove..

-----Original Message-----
From: Adrian Farrel [mailto:AF@dataconnection.com]
Sent: Thursday, September 28, 2000 5:45 AM
To: Bora Akyol; J. Noel Chiappa
Cc: mpls@uu.net
Subject: RE: Asymmetrical Bi-directional LSPs


Bora,

I agree with your concerns about moving goal-posts, but...

>-----Original Message-----
>From: Bora Akyol [mailto:akyol@pluris.com]
>"J. Noel Chiappa" wrote:
>>     > From: Bora Akyol <akyol@pluris.com>
>>     > Although I don't like the idea, if this comes to 
>>     >happen, option 3
>>     > would be my preference.
>>
>> ??? LSP's aren't bidirectional anyway, right? (What *is* the 
>> opposite of 'merge' - 'spray'? :-) So what difference does it
>> make if someone wants the back channel to take a different 
>> path? It's not like there's a mechanism already to do 
>> bidirectional LSP's and this is breaking it.
>
>Not quite true, if we do option 3, then we will have to add 
>another object to the PATH message to indicate the reverse 
>path that we would like the reverse LSP to follow. This is 
>more work and I am getting tired of adding new stuff to our
>RSVP code almost every week ;-(

This need not be the case.  Consider that GMPLS allows a Label on a Path
message.  If we remove the requirement for a Label_Request/Suggested_Label
we are there.

>I do not want to add to RSVP-TE before it becomes an RFC. If 
>you look at MPLS WG web page, you will find that there is a 
>boatload of MPLS ID's but not many RFCs.
>This is frustrating because things keep on changing and nothing is ever
>finalized. I think MPLS WG should close its doors to new items 
>until it can clear its existing items.

Agree.  It is hard to develop to a draft that keep s changing.

I may be wrong, but I believe that RSVP-TE is quite close to stable now.
The changes I'm discussing would be for the Generalized Signaling draft,
which (I assume) will make its separate way towards RFC.

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