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

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

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. 

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.

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
>