[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: What we disagree on RE: TE Requirements Draft-ELSP
Shai,
At 10:27 06/12/2001 -0500, Shai Herzog wrote:
> >> >-----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.
> >>
> >>Agree.
> >
> >Great. I think this is the most important issue.
>
>I guess so. I believe in two things that have TE meaning in DS-LSPs
>
>1. Single OA
>2. Global mapping (per domain) EXP->DSCP with per LSP signalled mapping
>
>So far, that's the only thing that I am sure has solid results and no
>bad implications.
>
>I almost forgot, multiple OAs are fine if no BW or other constraints are
>included (i.e., No TE), but I assume this is of no significance to this WG.
>
>Shai
>
> >I take this to mean that you agree with the proposals to not
> >include (iiib)
> >for now, and with the argument to not include (iiia) for now either.
>
>Yes.
>
> >What I concluded from the earlier discussions on (ii) is that:
> > - in general it doesn't make sense to group OAs with a single
> >Bw/Single Premption/Single everything
> > - but there are a few cases where it can make sense
> >(two OAs which
> >have same preemption/same everything AND a stable enough
> >relative bandwidth
> >ratio)
>
>No such beast.
Today when doing Aggregate TE in a Diff-Serv network, network
administrators effectively group all their OAs on a single E-LSP with a
single set of attributes. It's pretty coarse but it's actually quite
appropriate in many environments. In some environments (the ones which are
interested by DSTE), this is felt a little too coarse and they'd like to
separate some OAs (typically EF). But it's not rididulous to keep some OAs
together from teh CSPF viewpoint.
It's quite conceivable that an SP wants to:
- do CSPF of EF separately
- do CSPF of BE separately
- do CSPF of (AF1+AF2) separately (but treating AF1+AF2) as an
aggregate thing from DSTE perspective. They may make rough assumptions that
they have an N:M ratio between AF1 and AF2 everywhere.
Since you seem to like analogies, it woudl be like you being the delivery
man of the grocery shop and you've noticed that Pineaples always takes
about the space of two grapefruits and you have this box that can fit 20
grapefruits. Well, if you have to deliver 10 grapefruits + 5 pineaples, you
may be quite happy to put them all in the one box rather than have to carry
two separate boxes to the customer.
I think you identified another example of such a beast in your other email
: BE+AF1 is NOT a single OA. THis is two OAs. In your example you just
wanted to transport BE for free since it may have no constraints at all.
Well that woudl be another example of two OAs that coudl be transported
together on an E-LSP with a single set of attributes (ie the ones for AF1).
As I said, I woudln't go out of my way to allow this. But it happens to
cost me nothing.
>Preemption is per BW pool. If you draw from two separate pools (AF1 and AF2)
>the "single preemption" is really two different preemption calculation that
>can at any time (unexpectedly) produce conflicting results.
>
>You (and some others) seem to imply that having a single encoding means we
>don't have multiple parameters. (i.e., Single BW with ratio, single
>preemption priority, etc.). This is simply not true. To continue with my
>Watermelons and Cherries example, a single parameter ("3") doesn't mean that
>the volume of 3 cherries and 3 watermelons is the same. This is exactly the
>case for PP and multiple OAs.
>
>If you'd like to look at it another way, compressing a number of files into
>a single
>zip file doesn't change their contents (hopefully ;-). Having a single
>encoding doesn't
>mean a thing if it is really a representative of multiple independent
>"contents" parameters.
>I would suggest that we stop concentrating on encoding and look at the
>interpretation and implications of a certain set of data.
>
> > - there isn't a well identified set of SPs requesting
> >support for this
> >So, is there a strong motivation to include it? I would say, no.
> >But the point is that it does not cost anything to allow it.
> >It requires no
> >protocol extensions, it does not change the DSTE model.
>
>??? How about router implementation? You add one little thing to the spec
>that will be one major headack to vendors (because they'll have to figure
>out how to deal with conflicting decisions for the same LSP).
There is no conficting decision. There is a single deciusion. Can you fit n
Mb/s of bandwidth of CT1. It does or it doesn't . Then you can just steer
AF1 +AF2 packets on it.
>Moreover, I'm
>not so convinced that you can simply allow it without building a mechanism
>for (1) blocking it-policy based
>(2) signalling back to the creator of the
>tunnel
you do NOT have anything to signal back to the tunnel creator. The head-end
creates a tunnel with the same attributes as today and then just decide to
send AF1+AF2 packets on it, that's it.
> (3) recovering from unexpected BAD events
Can't see any Bad events relating to the fact that you send AF1+AF2 on a
given tunnel as opposed to sending AF1.
Really I don't think it creates any complication.
As a data point, if I look at the one commercially (pre-standard)
implementation of DSTE available today that I am aware of, it was developed
for support of option (i) only (ie E-LSPs with single OA) but it just
happens to also allow option (ii). No development work required.
>It's like saying: it is easy to walk on water! Why, walking is easy, all we
>have to do is to continue walking when we reach water, nothing more is
>needed ;-)
Gee, you like analogies...
> > - option (ii) is identified as something that MAY be
> >supported by
> >the DSTE solution as something which MAY be useful in some situations.
>
>If all you do is say that at the moment only one OA seem to make sense, and
>we could not find a good way of allowing multiple OAs, but that we don't
>rule out that in the future OTHER drafts may find ways of extending it (ie.
>smarter than us).
>
>I'm fine with this.
Please, let's try conclude. Can you agree with the wording above or not?
thanks
Francois
>Basically, I don't want us to imply that this is a usefull or good thing
>unless we can prove it to ourselves first, but I have no problem leaving the
>door open to future extensibility.
>
>Shai
>
> >
> >Thanks
> >
> >Francois
> >
> >
> >>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
> >> >>_________________________________________________________
> >> >
> >> >
> >
> >