[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TE Requirements Draft - ELSP



Joel

>.. it seems equally likely that you will get cases where the 
>composite LSPs do not take the right path, and you need separate ones.  
>Forcing them together strikes me as bad advice to the service provider.

You've made a valid point. However, there is no intention to FORCE 
the SP to ALWAYS put the 2 classes on the same LSP. The point is
that in certain cases (refer Jim's & Roberto's emails), an SP may 
CHOOSE to do this. By restricting the standard, you ensure this 
option is NOT at the disposal of the SP. 

> IETF experience is that options (particularly very similar 
> but not identical options that meet the same goals) are 
> dangerous and counter-productive.  If we really need this option, 
> there ought to be a clear reason that is not met by the 
> existing tools.

Point taken! I think this example is commonly given for RSVP-TE
vs CR-LDP. 

However, you appear to have already pre-supposed that we must 
have 2 different technology solutions (protocol extension) to 
satisfy the requirements for single-OA E-LSP and multiple-OA 
E-LSP. What if a single technology solution can satisfy both 
requirements without undue complexity?

Best,
Nabil Seddigh
nseddigh@tropicnetworks.com