[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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