[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TE Requirements Draft - ELSP
>.. 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
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?