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

[Shai Herzog <sherzog@hyperchip.com>]

>> >-----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. 

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). 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 (3) recovering from unexpected BAD events

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 ;-)

>         - 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.

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
>> >>_________________________________________________________
>> >
>> >
>
>