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

[Shai Herzog <sherzog@hyperchip.com>]

Nabil,

>-----Original Message-----
>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
>Behalf Of Nabil Seddigh
>Sent: December 6, 2001 11:43 AM
>To: Francois Le Faucheur
>Cc: te-wg@ops.ietf.org
>Subject: Re: What we disagree on RE: TE Requirements Draft-ELSP
>
>
>Francois,
>
>What is being proposed regarding multiple OAs on an E-LSP are
>protocol extensions that are OPTIONAL. If certain folks religiously
>believe that L-LSPs or E-LSPs with a single class are the way
>to go, they do not have to do this nor do the protocols have
>to signal or advertise any extra information beyond what is 
>mandated in the DS-TE REQ today.

First, "religion" means blind faith without proof, this isn't the case. In
fact, what I hear from Francois sounds more like a religios argument: I want
it, therefore it exists.
My claim is that it doesn't matter how much you'll want it, it doesn't
exist.

I'm very confused about the role of the IETF and optional stuff. Have we
gotten to the point where we allow bad mechanisms as optional ones? There is
no documentation that this is a bad thing and someone reading the draft a
year from now (or even today) will think it is a neat thing, implement it,
and BOOM.

The fact that someone is implementing it today, on a small scale and
controlled environment doesn't prove much. I can solve any "NP complete" or
"Exponential" altorithm without a computer if N=3. Try doing it for N=1000
;-)

I promised a document that will explain in details why I think this is a bad
thing,
and I'll send it soon. I have no problem if you want to leave the door open
for
future stuff, or non-standard/proprietery extensions, but please lets not
sanction
it as an IETF standard, or even claim it may be usefull as an option.

Alternatively, if we decide to to include it, it can only be done if it is
accompanied with analysis and WARNING as to the potential hazards of going
down this slippery slope.

>However, you shouldn't prevent others who wish to use this feature
>from doing so - assuming there are enough folks who express interest.
>The protocol extensions are OPTIONAL. The IETF has words like
>SHOULD and MUST for precisely this purpose.

Yap. we work by majority (or at least humming volume), so I don't expect to
coorse anyone (nor do I think I would want to do it). I do expect us to have
a real technical discussion and be responsible about the mechanisms we allow
as options.

I think it is well established at the IETF that OPTIONAL means something
that's complicated to implement and not necessarily worth it for everyone. I
don't believe it means something that may be hazardous to your health but
we'll let you hang yourself if you're foolish enough to take that option. Or
am I wrong about the IETF approach to Options?

Shai

>
>In the most recent discussion on this list, I think you have heard
>from a number of people. Seems to me that of the people who have
>emailed the list, there are more in favour than against. 
>
>Best,
>Nabil
>
>
>
>
>
>> 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...).
>> 
>> 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
>>
>