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

[Shai Herzog <sherzog@hyperchip.com>]

>-----Original Message-----
>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
>Behalf Of Siva Sivabalan
>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. 

I fully agree. Multiple BW and other parameters
is a BADDDDD thing.

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

Agree. But do you support multiple OAs with a single BW parameters?

My point is that this doesn't make sense either because one can't split the
BW between the different OAs.

So, basically, if you use multiple OAs in an E-LSP, many other parameters
(like BW, CSPF) become useless (and not permitted). This means such E-LSPs
are only good for vanilla DiffServ (no signalled BW, no constraint routes,
etc.). I'm not sure how usefull this could be for TE purposes.

So, we're left with only the case of an E-LSP with a single OA as a
meaningfull TE approach. (which sounds awfully close if not identical to
L-LSP).

The fact that it is on someone's wish list doesn't cure the problem at all.
It is computationally impossible to solve. (i.e., my example of "How many
watermelons and cherries can you fit together into a given size box).

If you disagree, please solve the following problem given only the following
information:

AF1+AF2=200Mb/s; how much BW is allocated to AF1? 
(for admission control computation and queueing).

Shai


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