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

[Siva Sivabalan <msiva@cisco.com>]

Francois,

I totally agree with you ....

My take is that we have to associate one and only one set of signaled 
parameters with E-LSP, regardless of how many OAs it carries. When carrying 
multiple OAs, having different (per-OA) values for one set of parameters 
(e.g., bandwidth) and the same values for other set of parameters (e.g., 
affinity) makes E-LSP complicated without strong incentives.

IMO, unless there are strong requirements, signaling multiple bandwidth 
values for a single E-LSP should not be considered an option.


Thanks,

Siva


>>Date: Tue, 04 Dec 2001 16:10:17 +0100
>>To: te-wg@ops.ietf.org
>>From: Francois Le Faucheur <flefauch@europe.cisco.com>
>>Subject: What we disagree on RE: TE Requirements Draft-ELSP
>>
>>Nabil and Shahram,
>>
>>The one option we disagree on is:
>>(iiia): Using E-LSPs with traffic from multiple OAs with multiple BW and 
>>single value for all other attributes (preemption, CT, affinity...).
>>
>>I recommend we do NOT add support for (iiia) in DSTE-REQTs at this stage. 
>>Here is why:
>>         1) (iiia) brings absolutely no new functionality
>>         2) (iiia) may only be used in limited situations
>>         3) the only benefit is debatable in practical networks
>>         4) it requires protocol extensions and options , which we 
>> already have a lot of
>>         5) these protocol extensions have been explicitely discussed and 
>> rejected earlier
>>         6) we still don't know whether there are SPs which may really 
>> benefit from this
>>
>>More details on each point:
>>
>>1) this brings absolutely NO new functionality: absolutely anything you 
>>can do with (iiia) can be done with L-LSPs already. There has been some 
>>statements along the lines of "(iiia) gives you better restoration this 
>>and that"; this is absolutely incorrect since you can achieve anything 
>>you can do with (iiia) (and more) using L-LSPs. So I'd like to make it 
>>100% clear that (iiia) is purely about doing in a different way something 
>>which can already be done .
>>
>>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 and have the same Class-Type requirements.
>>As an interesting example, let's use our Voice_signaling and 
>>voice_payload example which Nabil also mentions in his draft. Because 
>>Voice_payload and Voice_signaling have very differnet QoS requirements, I 
>>would expect those to be typically configured by SP under different 
>>Class-Types. This means that (iiia) could actually not be used to 
>>transport them on a single E-LSP. They may also have different preemption 
>>priorities because SP may want to make sure voice_payload is routed as 
>>close as possible to its SPF (because of its delay/jitter requirements) 
>>while voice_sig may afford to be routed a little further away from its 
>>SPF. Again, this would mean (iiia) could not be used.
>>So the bottom line is that the SP would sometimes happen to be able to 
>>group some OAs together with (iiia) but often won't be able to.
>>
>>3) The only arguable benefit is debatable in practical networks. First, 
>>as Joel pointed out, it must be made clear that most of the scalability 
>>aspects are actually equivalent between (iiia) and using L-LSPs. 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.
>>So the only arguable benefit is you may have less LSPs.
>>But considering the previous point you might be able to group some OAs 
>>and probably won't  be able to group others so the ballpark maybe that, 
>>if you're lucky, (iiia) will result in twice less LSPs. I am not sure a 
>>factor 2 in pure number of LSPs (when you have to manage thing at the OA 
>>level anyway) is a make or break element.
>>
>>4) (iiia) requires protocol extensions. Although we've tried to resist 
>>adding options in the "Diff-Serv over MPLS" spec, there are already 
>>(too?) many options. In my opinion, adding yet another option (to do 
>>differently what we can already do) is simply going one little step 
>>further towards making MPLS too complicated. Not a big step, but a step 
>>in the wrong direction.
>>
>>5) Signaling multiple bandwidth is an option that has been considered in 
>>the making of "Diff-Serv over MPLS" and explicitely excluded as offering 
>>too little gain over the other options which can already cover the 
>>requirement and not having clear SP requirements behind. This has been 
>>validated and revalidated and rerevalidated through the multiple last 
>>calls on the spec in the MPLS WG and Diff-Serv WG, I don't see any 
>>significant information justifying reversing that decision.
>>
>>6) We still don't know whether there are life SPs which expect to be in 
>>the precise situation where (iiia) would help i.e:
>>         - OAs have differnet bandwidth constraints but same 
>> preemption/affinity/CT/restoration
>>         - a factor of about 2 in number of LSPs makes a significant 
>> difference (when operations is done on a per-OA basis anyway).
>>
>>
>>Cheers
>>
>>Francois
>>
>>At 12:13 03/12/2001 -0500, Nabil Seddigh wrote:
>>
>>>Sorry, I guess I wasn't explicit enough.
>>>
>>>Yes, (iiib) should not be specifically added until someone expresses
>>>an interest in it.
>>>
>>>
>>>Best,
>>>Nabil Seddigh
>>>
>>>
>>> > We understand you're after (iiia). My question was about (iiib). I think
>>> > your words above implyi you're agreeing with the proposal for (iiib), but
>>> > can you be explicit about it. Let me repeat the question:
>>> > "So again, leaving aside (iiia) for now, can you agree that (iiib) should
>>> > not specifically be added to REQTS draft for now until SPs have expressed
>>> > the requirement for it?"
>>> >
>>> > thanks
>>> >
>>> > Francois
>>> >
>>> > >Best,
>>> > >Nabil
>
>_________________________________________________________
>Francois Le Faucheur
>Development Engineer, IOS Layer 3 Services
>Cisco Systems
>Office Phone:          +33 4 97 23 26 19
>Mobile :               +33 6 89 108 159
>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
>_________________________________________________________