[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: What we disagree on RE: TE Requirements Draft-ELSP
Francois,
> 1) (iiia) brings absolutely no new functionality
No, (iii a) brings absolute new functionality of transporting
together traffic belonging to different classes of a service
of a customer on the same LSP that is not defined in the DS-TE
requirements documents. It is definitely not the same way that
you can do with other things.
> 2) (iiia) may only be used in limited situations
> 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.
>
Class type should not be in this picture. No one ever said
all of the OAs will be mapped to the same CT. That would be
wrong. We were only saying about same pre-emption attributes.
CT is not brought into this picture as this is outside the
scope of mechanism and not a necessary means to do DS-TE.
SPs may want to do classes instead of CT. If it is a absolute
must, then along with OA bandwidth parameters, you would also
indicate it's class type, in a very simple way by adding two
bits. This would complete the CT functionality.
> 3) the only benefit is debatable in practical networks
I don't think so. Path protection is one of the important
aspects of MPLS. One would want to guarantee faster restoration
times at the path level on an end-to-end basis (and to provide
availability SLAs). Carrying all OAs of a customer on a single
E-LSP would bring such faster restoration times besides reducing
the LSP scalability issue for the whole customer traffic.
Therefore the benefit is not just LSP scalability issue but
is also tied to provide better availability SLAs in a
multi-OA case.
> 4) it requires protocol extensions and options , which
> we already have a lot of
You need protocol extensions that are useful and this one is such.
This is a completely missed out functionality. In order to do
E-LSP and L-LSP co-existence meaningfully, these "minor" protocol
extensions are needed.
> 5) these protocol extensions have been explicitely discussed and
> rejected earlier
May be the MPLS application aspects might have changed from
when you considered last. Even the group of people who are looking
at this problem now could be different.
> 6) we still don't know whether there are SPs which may really
> benefit from this
I thought some of the other posts are from SPs who are arguing the
benefits of this.
-Sudhakar
> -----Original Message-----
> From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> Behalf Of Francois Le Faucheur
> Sent: Tuesday, December 04, 2001 10:10 AM
> To: te-wg@ops.ietf.org
> 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
>
>
>
>