RE: TE Requirements Draft - ELSP

["Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>]

Joel,

> what it does.  What I still don't understand is what problem it 
> solves.  Label utlization?  Recovery time?

we are probably approaching this issue from two different point of views. I'm not pushing E-LSP against L-LSP in order to solve a specific problem. As Nabil correctly told in his mail, the same debate could be done for RSVP-TE against CR-LDP. From a functional perspective they are equivalent, so why should we define two protocols when just one is enough? What kind of problem can be solved by CR-LDP that RSVP-TE is not able to cope with (or vice versa)? No one... there are no problems to solve; simply an operator could prefer CR-LDP, while another could choose RSVP-TE.

I perfectly agree with you when you say that is better to avoid unnecessary features... from my point of view, if a SP hasn't got at least some limited TE capabilities by using DiffServ over MPLS with E-LSP, then E-LSP is an unnecessary feature. You can do almost everything with L-LSP, no doubt on that, so why do we keep E-LSP?
The point is that if you don't allow some limited aggregate TE functionality when using E-LSP and use it as in a pure DiffServ scenario (as the example in one of your mails seems to suggest), then which is the added value of having E-LSP? If you give the operator the possibility to choose, you should give him two real alternatives, not just one.

So, there are two possible choices:
(1) keep using E-LSP with some aggregate TE functionality and give the provider the possibility to choose it (if it is suitable for its purposes). In this case there is a gap in the standard and the draft pointed in my previous mail is just an attempt to fill it (probably not the best solution possible, and we can discuss about that, but at least tries to address the problem).
(2) discard E-LSP since it is not a necessary feature.

The draft suggested in my previous mail is REALLY a slight addition: it is NOT a new object, but simply an extension of the existing FlowSpec object; it is completely backward compatible and can be incrementally deployed and finally, requires about 100 lines of code, that inserted in a software of more than 10000 lines, represent a minor change.

Regards
Roberto

> 
> Yours,
> Joel M. Halpern
> 
> At 11:09 AM 11/21/01 +0100, Roberto Mameli (ERI) wrote:
> >So, only a slight addition to the protocol, with minor impact and 
> >preserving backward compatibility. Why not?
>