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

[Francois Le Faucheur <flefauch@europe.cisco.com>]

Nabil,

At 12:04 06/12/2001 -0500, Nabil Seddigh wrote:
>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?

I thought my recommendation was clear by now:
         - allow (i)
         - allow (ii)
         - allow (iv) aka L-LSP

You can achieve all teh functional goals with this set of options.


> > 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.

You have made similar claims about somehow (iiia) bringing some stability 
benefits which make no technical sense to me.
Is it clear to you that if you put the two OAs on differnet L-LSPs you can 
give them the same preemption priority which results in NO preemption among 
them.

>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.

Who talked about any vendor equipment limitations?
I don't see the connection between my statement above and your response.
The only valid technical argument in favor of (iiia) is that it reduces the 
number of LSPs. This has been initially presented as an improvement in 
scalability . Above, I am clarifying that it helps only in one aspects of 
scalability which is pure number of LSPs but that from an SP point of view 
a big part of the DSTE scalability burden is to do measurement on a per OA 
basis and decide per-OA bandwidth based on that, configure those on a 
per-OA basis etc ... this is the more important aspect of scalability , and 
option (iiia) makes no difference on that aspects compared to option (iv) 
[aka L-LSPs].
So in brief, I am saying that (iiia) woudl only help on the less important 
aspect of operational scalability (from an SP perspective). BTW, in a 
separate point, I was also explaining why I think that it woudln't help 
that much anyway , even on that less important point because it couldn't be 
used for most OAs (eg because they may have different CTs)


cheers

Nabil.

>
>Best,
>Nabil

My Mobile Phone number has changed to +33 (0)6 19 98 50 90
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
Fax:                   +33 4 97 23 26 26
Email:                 flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________