The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] 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 |
|