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

From: Shai Herzog <[email-masked]>
Date: Tue, 4 Dec 2001 16:02:52 -0500

Comments bellow.

>-----Original Message-----
>From: Jim Boyle [mailto:[email-masked]]

>> Given a box, how many watermelons and cherries can you fit inside it?
>
>783 for me, using bing cherries, 1328 using marascheno.

Your answer is incomplete... how many watermelons?
I must know (since I'm packing the box right now).

>> Since different OAs are disjoint, and draw from different pools,
>> how do you propose we split the single BW parameters among 
>>the multiple
>> OAs?
>
>it's application specific, if you even can.  Of course if your 
>application
>doesn't fit this mold, then use L-LSPs.  

Application specific is a good way to sweep the issue under the rug, but
you'r not going to get out of it so easily ;-)
Could you please enlighten us with one real example that does NOT involve
multiple BW parameters?

Shai

______________________________________
Shai Herzog		Tel:	(914) 654-4810
HyperChip		Cell:	(917) 209-9376

---

From: Siva Sivabalan <[email-masked]>
Date: Wed, 05 Dec 2001 12:26:32 -0500

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. When carrying 
multiple OAs, having different (per-OA) values for one set of parameters 
(e.g., bandwidth) and the same values for other set of parameters (e.g., 
affinity) makes E-LSP complicated without strong incentives.

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: [email-masked]
>>From: Francois Le Faucheur <[email-masked]>
>>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:                 [email-masked]
>_________________________________________________________
>Cisco Systems
>Domaine Green Side
>400, Avenue de Roumanille
>06 410  Biot - Sophia Antipolis
>FRANCE
>_________________________________________________________

---

From: [email-masked]
Date: Thu, 6 Dec 2001 11:09:06 -0000

The key thing that is missing from this debate is the relationship between:
-	public services
-	private services, ie VPNs

SPs would like to integrate their 'Internet' and 'VPN' networks but
currently this is proving difficult....so IMO all future work in this area
ought to recognise/address this issue.

I can see a good solution for the former by aggregation in internal
public-VPNs using L-LSPs (per PHB).

I can't see any good solution for private VPNs when LDP is used (or indeed
unification of private/public VPNs)....I have explained several times why
this is true, so I won't bore you all again.

I can see a potential good solution for private VPN based on E-LSPs....and
again I have provided the reasons on previous mails....and its seems this
could be the unifying solution too.

regards, Neil

> From: Shai Herzog [mailto:[email-masked]]
> Sent: 04 December 2001 18:31
> To: 'Francois Le Faucheur'; [email-masked]'
> Subject: Re: What we disagree on RE: TE Requirements Draft-ELSP
> 
> 
> At 1010 AM 04/12/2001, Francois Le Faucheur wrote
> >Nabil and Shahram,
> >
> >The one option we disagree on is
> >(iiia) Using E-LSPs with traffic from multiple OAs with 
> multiple BW and 
> I for one disagree that E-LSPs with Multiple OAs and single BW are
> technically (or theoretically) sound. Not to use the cliche of apples
> and oranges, pretty much it is equivalent to:
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 06 Dec 2001 15:17:57 +0100

Shai,

At 16:04 05/12/2001 -0500, Shai Herzog wrote:

> >From: [email-masked] [mailto:[email-masked]]On
> >Behalf Of Siva Sivabalan
> >Francois,
> >
> >parameters with E-LSP, regardless of how many OAs it carries.
>
>I fully agree. Multiple BW and other parameters
>is a BADDDDD thing.
>
> >When carrying
>Agree.

Great. I think this is the most important issue.
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.

>But do you support multiple OAs with a single BW parameters?
>
>My point is that this doesn't make sense either because one can't split the
>BW between the different OAs.

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)
         - 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. Another way to look 
at this is to say that no matter what we say on this, a router could then 
perfectly decide to do that without needing any protocol extensions and 
without compromising interoperability of DSTE with other routers that don't 
do this.

So, could you agree to the following refined approach for (ii) in next 
version of DSTE-REQTS:
         - option (ii) is not identified as a "Requirement" for the DSTE 
solution
         - option (ii) is identified as something that MAY be supported by 
the DSTE solution as something which MAY be useful in some situations.

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

---

From: Shai Herzog <[email-masked]>
Date: Thu, 6 Dec 2001 09:23:29 -0500

>Behalf Of Sudhakar Ganti
>Sent: December 5, 2001 11:27 PM
>To: [email-masked]
>Subject: RE: What we disagree on RE: TE Requirements Draft-ELSP
>
>
>Shai,
>
>If multiple BW signaling is a bad thing and yet
>we want a separation (or control) of BW between
>OAs of E-LSP, we can statically map the BW
>ratios of OAs in the whole network (say
>AF1/AF2=1/10 in your example) to solve the
>equation.

???

Are we in the DiffServ or the MPLS-TE WG?

Are we playing a game of "how many ways can we do BW encoding?"

What's the difference between signaling two BW numbers and signalling
one BW with a ratio split. It is only an encoding difference, but has
the same implementation/implications.

1. A fixed ratio around the network? How does that relate to
   End-to-End tunnel BW? (I hope you at least recognize that).

   Saying AF1 to AF2 is 1/10 in BW is no different than saying
   that all AF1 in the network get X BW, and AF2 get Y BW. Both
   have nothing to do with Traffic Engineering because the provide
   NO per tunnel QoS guarantees.

>The fun part is,

I not sure if find it funny hearing different "BW encoding" proposals 
that have no analysis of their implications. I wish we could take
a step backwards from the "What/how can we signal" but rather 
"What's the implications of a certain set of signalled constraints".

At some point one may ask him/her self what's the added benefits
vs. complexity. I will try to later today or tomorrow send out a 
more or less "methodical" analysis of implications of the different 
options of E-LSP and OAs. At least hoping to show the complexity side 
(not arguing the benefits side). 
 
The fun part would be arguing for/against it in the WG ;-)

Shai

>-Sudhakar
>> Behalf Of Shai Herzog
>> Sent: Wednesday, December 05, 2001 4:05 PM
>> To: 'Siva Sivabalan'; [email-masked]'
>> Subject: RE: What we disagree on RE: TE Requirements Draft-ELSP
>>
>>
>>
>>
>> Agree. But do you support multiple OAs with a single BW parameters?
>>

---

From: Shai Herzog <[email-masked]>
Date: Thu, 6 Dec 2001 09:43:40 -0500

Neil,

I would second your proposal that TE and VPN work would be tightly coupled
(as VPNs are really just a form of TE, externally facing customers).

I would also agree that I see the usefullness of L-LSPs as well as E-LSPs
with single OA. 

In fact, I would rather drop the E/L LSP name completely and instead use
only one name: DS-LSP. Since any DS LSP needs a mapping between 8 EXP bits
and 64 DSCP space, we can either define a global mapping (pre-configured
identically for all LSR in the domain), or signal it at LSP creation (a la
L-LSP). 

So, we'll have only a single type of DS-LSP, with global pre-configured
setting, and per-LSP signalled override. Simple to implement and effective.

BTW: we haven't discussed it really, but I believe Best Effort (BE) is
included in any OA and can be considered as part of the OA (BE+AF1) would be
considered a single OA. I can justify it by saying that BE has no
constraints, so it will never "take away" or "conflict" with any other QoS
mechanism. 

Does anyone see a problem with that?

shai

>From: [email-masked] [mailto:[email-masked]]
>Sent: December 6, 2001 6:09 AM
>To: Shai Herzog; [email-masked]; [email-masked]

---

From: Shai Herzog <[email-masked]>
Date: Thu, 6 Dec 2001 10:27:29 -0500

>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

>for now, and with the argument to not include (iiia) for now either.

Yes.

>have same preemption/same everything AND a stable enough 

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.

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

>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

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 06 Dec 2001 18:01:32 +0100

Shai,

> >have same preemption/same everything AND a stable enough

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.

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

>have to do is to continue walking when we reach water, nothing more is

Gee, you like analogies...

>rule out that in the future OTHER drafts may find ways of extending it (ie.

Please, let's try conclude. Can you agree with the wording above or not?

thanks

Francois

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Thu, 6 Dec 2001 18:54:11 +0100

Hi Shai/all,

please see my comments below...

> Sent: Thursday, December 06, 2001 3:23 PM
> To: 'Sudhakar Ganti'; [email-masked]'

I perfectly agree with your observation. Even if we preconfigure network nodes according to a fixed ratio (let's say 20%EF-80%BE), we are not sure that the limitation of EF ingress traffic to 20% is enough to avoid EF congestion in internal nodes. This is a well known problem for DiffServ people, and is related to how traffic aggregates/disaggregates into the network.

>    NO per tunnel QoS guarantees.

Again I perfectly agree with you, and I also agree with the observation you made in your previous mail, concerning the usefulness of E-LSP for TE purposes. You explicitly stated:

This is exactly my opinion. My original concern is that E-LSP carrying multiple OAs according to the current standard is nothing (or very little) more than pure DiffServ. It's not really a form of Traffic Engineering.

Now the choice is twofold:

(1) drop E/L-LSP as you propose and use just one single type of LSP (let's call it DS LSP as you do)
(2) keep the original distinction between E-LSP and L-LSP, but add the E-LSP with some limited TE capabilities

Option 1) is very radical. It requires a dramatic change in the current MPLS-DIFF architecture. Option 2), instead, is quite soft from this point of view, even if implies some minor protocol extensions. Anyway, following Nabil's mail I'd like to outline that this extensions are OPTIONAL. If a SP doesn't want to exploit these capabilities (i.e. if it uses L-LSP, single OA E-LSP, multiple OA E-LSP with a single bw parameter, atc.), it does'nt have to do nothing more than what is currently requested by the DS-TE draft.

Regards
Roberto

---

From: Shai Herzog <[email-masked]>
Date: Thu, 6 Dec 2001 12:55:18 -0500

Nabil,

>Behalf Of Nabil Seddigh
>Sent: December 6, 2001 11:43 AM
>To: Francois Le Faucheur
>Cc: [email-masked]
>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.

First, "religion" means blind faith without proof, this isn't the case. In
fact, what I hear from Francois sounds more like a religios argument: I want
it, therefore it exists.
My claim is that it doesn't matter how much you'll want it, it doesn't
exist.

I'm very confused about the role of the IETF and optional stuff. Have we
gotten to the point where we allow bad mechanisms as optional ones? There is
no documentation that this is a bad thing and someone reading the draft a
year from now (or even today) will think it is a neat thing, implement it,
and BOOM.

The fact that someone is implementing it today, on a small scale and
controlled environment doesn't prove much. I can solve any "NP complete" or
"Exponential" altorithm without a computer if N=3. Try doing it for N=1000
;-)

I promised a document that will explain in details why I think this is a bad
thing,
and I'll send it soon. I have no problem if you want to leave the door open
for
future stuff, or non-standard/proprietery extensions, but please lets not
sanction
it as an IETF standard, or even claim it may be usefull as an option.

Alternatively, if we decide to to include it, it can only be done if it is
accompanied with analysis and WARNING as to the potential hazards of going
down this slippery slope.

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

Yap. we work by majority (or at least humming volume), so I don't expect to
coorse anyone (nor do I think I would want to do it). I do expect us to have
a real technical discussion and be responsible about the mechanisms we allow
as options.

I think it is well established at the IETF that OPTIONAL means something
that's complicated to implement and not necessarily worth it for everyone. I
don't believe it means something that may be hazardous to your health but
we'll let you hang yourself if you're foolish enough to take that option. Or
am I wrong about the IETF approach to Options?

Shai

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

---

From: Shai Herzog <[email-masked]>
Date: Thu, 6 Dec 2001 13:13:57 -0500

Nabil,

>I suspect most network operators would rather have a more stable
>network - one where most LSPs are not continually pre-empted due
>to a large number of pre-emption priorities. Thus, the argument
>for using a single pre-emption attribute for the E-LSP with 
>multiple BW.

Here Here. In a capitalist world, more LSP means slightly more hardware (and
slightly more expensive LSR). Compare that to cheaper LSR that may
unpredictedly melt down your network...
It will make it much harder to get to 99.999% availability, a number we all
look up to.

And an analogy: It's like trying to get the cheapest brain surgent operate
on you ;-)
Good luck!

>I understand that there are various folks interested in using
>the pre-emption attributes primarily for the case where links go
>down etc.
>
>> 3) 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.
>
>It would be a shame to limit the protocol extensions and DS-TE
>framework because of limitations in vendor equipment path 
>computation schemes. If this argument was used, OSPF would never
>have been deployed.

Yap. How about other forms of aggregation. I also fail to understand the
scalability argument. You are talking about factor of 2-3 only on a small
subset of LSPs. 

As we all know mathematically O(multiple OA) = O(Single OA). Since they
scale the same way the efficiency and scalability argument is simply false.
If on the other hand Francois can show improvement of an order of magnitud
at least I'll understand the motivation for this weird solution.

BTW: there are other, more efficient ways of dealing with this built into
MPLS already... Why don't these SP use hierarchical MPLS tunnel aggregation?
I can show several order of magnitude improvement there (x1000?).

Shai

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 07 Dec 2001 13:31:55 +0100

Shai,

>scale the same way the efficiency and scalability argument is simply false.

all agreed.

>at least I'll understand the motivation for this weird solution.

You lost me here. Did you really mean "Francois" above?
In case it isn't clear, Francois is arguing ,like you, that there is a very 
little gain in scalability in (iiia) and therefore that we shouldn't create 
yet another protocol option for this...

>I can show several order of magnitude improvement there (x1000?).

Agreed.

Francois

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Fri, 7 Dec 2001 14:12:47 +0100

Francois,

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 6:02 PM
> To: Shai Herzog
> Cc: 'Francois Le Faucheur'; 'Siva Sivabalan'; [email-masked]'

This point is very good. My question is: "What does aggregate TE really means?". The only definition I have been able to find is reported in appendix A3 of the MPLS-DIFF draft, quoted below:

	A Service Provider running 8 (or fewer) BAs over MPLS, performing aggregate Traffic 	Engineering (i.e. performing a single common path selection for all BAs), using 	aggregate MPLS protection (i.e. restoring service to all PSCs jointly)........

Based on the previous lines, we can define "aggregate TE" as the form of Traffic Engineering that is constrained by common path selection among different service classes, independently from any other factor (such as the relative proportion of traffic across
classes).

This definition could also include scenarios in which a routing algorithm calculates a SINGLE path for all service classes given N bw costraints. Of course, the N constraints could be implicitly known by all nodes, in the form of preconfigured proportion of traffic across classes, without being signaled across network nodes. However, in my opinion this doesn't really allow Traffic Engineering in the network, and as Shai was trying to point out it is not really TE, but simply DiffServ (I quote Shai's words below):

So now it seems to me that there is something that is conflicting. We say that:

(A) E-LSP carrying multiple OAs are useful for aggregate TE (without specifying in detail what aggregate TE really means)

	AND

(B) if we use multiple OAs in an E-LSP (without per OA bw constraints), then we simply provide DiffServ, not really TE

It seems to me that (B) contradicts (A), unless there is something that I'm missing. The original idea of signaling per OA bw constraints within an E-LSP was motivated by the need to solve this contradiction.

/Roberto

---

From: Shai Herzog <[email-masked]>
Date: Fri, 7 Dec 2001 18:18:14 -0500

Francois,

>Sent: December 7, 2001 7:32 AM

OOPS. I guess I lost track (with so much email) of who said what ;-)
My appologies.

Shai

---

From: Shai Herzog <[email-masked]>
Date: Fri, 7 Dec 2001 18:36:24 -0500

Francois,

>If I understand correctly, this is where we stand :
>         - Nabil is saying, let's allow (ii) and (iiia)
>         - Shai is saying, let's not allow (ii) nor (iiia)
>         - Francois is saying, let's allow (ii) but not (iiia).

Your correct regarding my position. I think the "Single BW or CSPF" doesn't
exist and has no meaning (other than random or arbitrary). Multiple BW/CSPF
exist, but pose horrendous danger to network stability (one that can be
lurking and not obvious before dissaster strikes). 
However, I believe in democracy, so I would correct the "not allow" to "not
sanction and warn against". If someone wants to drive into the wall, at
least he/she won't be able to come back and blame us for designing a faulty
and dangerous standard.

>At least, my religion is more middle-of-the-ground than either
>of yours. '^)

Let me see. Lets think religion... So, I believe in evolution, you believe
in a combination of evolution and creationism, and Nabil believes in pure
creationism. In this case, I like being on the extreme side ;-)

Shai

---

From: Shai Herzog <[email-masked]>
Date: Fri, 7 Dec 2001 18:39:36 -0500

>Sent: December 7, 2001 8:08 AM
>
>This would also help avoiding the above fascinating situation 
>where, in two 
>consecutive paragraphs , I am simultaneously :
>         - accused of being religious because I am too closed 
>to adding 
>options [ie arguing against (iiia) because of its protocol extensions]
>         - accused of being religious because I am too open to adding 
>options [ie arguing that it is OK to allow option (ii) since 
>it doesn't 
>require any protocol extension].
>Funny world.
>

Your right, it is funny. They say that if your proposal gets heat equally
from all directions it must be the right and balanced one...

Well,... not in this case ;-)

Shai

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 11 Dec 2001 07:03:33 +0100

Shai,

This message focuses on otion (ii).

Based on the conversation we had Yesterday in SLC, my understanding is that:
         - there was one operating assumption that I had not made clear for 
when (ii) would be used which is that option (ii) would not be mixed with 
option (iv) [aka L-LSPs] for the same OAs.
         - with this assumption being made explicit you agree that option 
(ii) is viable and would not create any "meltdown"
         - you would now not have an objection to the DS-TE REQST draft 
stating that :
                 * there is currently no established clear requirement for 
option (ii)
                 * but that a DSTE solution may support option (ii)  [since 
this comes for free]
                 * clarifying that option (ii) is not a "general" solution 
but may be useful and viable provided a number of "operational" assumptions 
are met (eg. assumption clarified above).

Is this right?

thanks

Francois

---

From: Shai Herzog <[email-masked]>
Date: Tue, 11 Dec 2001 20:15:49 -0500

Francois,

Here's a proof that one lunch does more to advance things than hundreds of
email messages!

Yes. If all the OAs that are included in the E-LSP are never used in any
other LSP (L-LSP), and are never used in E-LSP in any other combination (or
BW ratio) and if they are drawing from a single BW pool, then they are
virtually ONE individible class (that happen to be made of two OAs).

In this case, there should be no chance for conflicting results between the
two OAs, and therefore, not a problem in my view.

It is important for folks to understand (and we should acknowledge) that
breaking these constraints (such as suddenly adding L-LSP that use some of
these OA) will cause serious problems, and is highly discouraged.

Shai

>Sent: December 11, 2001 1:04 AM
>To: Shai Herzog
>Cc: 'Francois Le Faucheur'; 'Nabil Seddigh'; [email-masked]'

---

From: Shai Herzog <[email-masked]>
Date: Tue, 11 Dec 2001 20:30:54 -0500

Just to clarify, 

My acceptance of the limited case of (ii) as described by Francois, doesn't
extend to case (iii). I'm very much opposed to it.

I've sent a document to the list yesterday, but I don't see it echoing back
to me, so perhaps it went into the good email black hole. I'm re-sending it
attached to this email after removing all the stuff related to case (ii)
based on my discussion with Francois. So the document right now is limited
to case (iii).

Shai

>Behalf Of Francois Le Faucheur
>Sent: December 11, 2001 1:20 AM
>To: Nabil Seddigh
>Cc: Francois Le Faucheur; [email-masked]
>At 12:04 06/12/2001 -0500, Nabil Seddigh wrote:
>>Francois,
>>
>> > 1) this brings absolutely NO new functionality: absolutely anything
>> > you can do with (iiia) can be done with L-LSPs already.
>>
>>So should we mandate that the SPs use only L-LSPs?
>
>I thought my recommendation was clear by now:
>         - allow (i)
>         - allow (ii)
>         - allow (iv) aka L-LSP
>
>You can achieve all teh functional goals with this set of options.
>
>
>> > 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
>>
>>IS this really only a few cases?
>>I wonder how many SPs today have a network where LSPs keep getting
>>bumped and rerouted due to pre-emption when new LSPs are setup?
>>
>You have made similar claims about somehow (iiia) bringing 
>some stability 
>benefits which make no technical sense to me.
>Is it clear to you that if you put the two OAs on differnet 
>L-LSPs you can 
>give them the same preemption priority which results in NO 
>preemption among 
>them.
>
>Who talked about any vendor equipment limitations?
>I don't see the connection between my statement above and your 
>response.
>The only valid technical argument in favor of (iiia) is that 
>it reduces the 
>number of LSPs. This has been initially presented as an improvement in 
>scalability . Above, I am clarifying that it helps only in one 
>aspects of 
>scalability which is pure number of LSPs but that from an SP 
>point of view 
>a big part of the DSTE scalability burden is to do measurement 
>on a per OA 
>basis and decide per-OA bandwidth based on that, configure those on a 
>per-OA basis etc ... this is the more important aspect of 
>scalability , and 
>option (iiia) makes no difference on that aspects compared to 
>option (iv) 
>[aka L-LSPs].
>So in brief, I am saying that (iiia) woudl only help on the 
>less important 
>aspect of operational scalability (from an SP perspective). BTW, in a 
>separate point, I was also explaining why I think that it 
>woudln't help 
>that much anyway , even on that less important point because 
>it couldn't be 
>used for most OAs (eg because they may have different CTs)
>
>
>cheers
>
>Nabil.
>
>>
>>Best,
>>Nabil
>
>My Mobile Phone number has changed to +33 (0)6 19 98 50 90
>Mobile :               +33 6 19 98 50 90
>Fax:                   +33 4 97 23 26 26