Re: What we disagree on RE: TE Requirements Draft-ELSP

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

Francois,

> 1) this brings absolutely NO new functionality: absolutely anything 
> you can do with (iiia) can be done with L-LSPs already. 

So should we mandate that the SPs use only L-LSPs?

> 2) (iiia) may only be used in few cases. (iiia) could only be used 
> to group OAs which have different bandwidth requirements BUT have 
> the same affinity requirement, have the same preemption requirement, 
> have the same protection requirement 

IS this really only a few cases?
I wonder how many SPs today have a network where LSPs keep getting 
bumped and rerouted due to pre-emption when new LSPs are setup?

I suspect most network operators would rather have a more stable
network - one where most LSPs are not continually pre-empted due
to a large number of pre-emption priorities. Thus, the argument
for using a single pre-emption attribute for the E-LSP with 
multiple BW.

I understand that there are various folks interested in using
the pre-emption attributes primarily for the case where links go
down etc.

> 3) In particular on the operational front, they both require 
> the SP to manage things at the granularity of the OA 
> (ie monitor/compute/configure bandwidth requirements on a 
> per OA basis). I believe this is often the dominant scalability 
> burden.

It would be a shame to limit the protocol extensions and DS-TE
framework because of limitations in vendor equipment path 
computation schemes. If this argument was used, OSPF would never
have been deployed.
 
Best,
Nabil