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

[Shai Herzog <sherzog@hyperchip.com>]

Just to clarify, 

My acceptance of the limited case of (ii) as described by Francois, doesn't
extend to case (iii). I'm very much opposed to it.

I've sent a document to the list yesterday, but I don't see it echoing back
to me, so perhaps it went into the good email black hole. I'm re-sending it
attached to this email after removing all the stuff related to case (ii)
based on my discussion with Francois. So the document right now is limited
to case (iii).

Shai

>-----Original Message-----
>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
>Behalf Of Francois Le Faucheur
>Sent: December 11, 2001 1:20 AM
>To: Nabil Seddigh
>Cc: Francois Le Faucheur; te-wg@ops.ietf.org
>Subject: Re: What we disagree on RE: TE Requirements Draft-ELSP
>
>
>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
>_________________________________________________________ 
>
>
>

ietf 01_12_10 TE WG-2.ppt