Subject: RE: link bundling in MPLS TE

From: Shahram Davari <[email-masked]>
Date: Mon, 6 Mar 2000 08:03:51 -0800

Hi,

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Monday, March 06, 2000 10:41 AM
>To: Shahram Davari
>Cc: 'Kireeti Kompella'; [email-masked]
>Subject: Re: link bundling in MPLS TE 
>
>
>
>In message 
><[email-masked]
>.bc.ca>, Shahram Davari writes:
>> Hi Kiteeti,
>> 
>> >-----Original Message-----
>> >From: Kireeti Kompella [mailto:[email-masked]]
>> >Sent: Friday, March 03, 2000 4:04 PM
>> >To: [email-masked]; [email-masked]; [email-masked]
>> >Subject: RE: link bundling in MPLS TE
>> >
>> >
>> >Hi Shahram,
>> >
>> >> The problem is that in both cases you want to route 200M 
>> >traffic on a single
>> >> component link. If you do it as 2*100M you will succeed, but 
>> >if you do it as
>> >> a single 200M you won't.
>> >
>> >I see your problem: the notion of oversubscription.
>> >
>> >Oversubscription is taking advantage of stat mux.  Two 100M LSPs
>> >whose instantaneous traffic never adds up to more than 100M can
>> >share a 100M link.  A 200M LSP just doesn't fit in a 100M link.
>> >
>> >Kireeti.
>> 
>> 
>> Could you also please clarify that when you say a 100M LSP, 
>are you talking
>> about the Peak rate (PIR) or Committed rate (CIR)? 
>> 
>> If in the above example we are talking about CIR then it is 
>impossible to
>> pass 2*100M LSP or a single 200M LSP through a 100M link. 
>While if we are
>> talking about PIR then you are right we can't pass a 200M 
>LSP through a 100M
>> link, but we are most likely unable to pass the 2*100M LSPs 
>either, because
>> there is no way to guarantee that the instantaneous traffic 
>of the two LSPs
>> never adds up to more than 100M. Is there any?  
>> 
>> Regards,
>> -Shahram
>
>
>There is no Committed rate (CIR) in the Tspec for the Controlled-Load
>service which most MPLS deployments (all major deployments to my
>knowledge) are using.
>

I don't think this draft is talking about CLS. Could the authors please
clarify which rate is being considered in the MPLS Admission control, CIR or
PIR?

>There is a token rate "r" in bytes per second which is a prediction of
>how much might be used and the network accepts this if the traffic has
>a sufficient probability of acceptable performance (where the vaules
>of sufficient and acceptable are intentionally vague).  Setting an
>overbooking of 200% is one way to directly specify how to apply
>constraints to meet those vague sufficient and acceptable criteria.
>
>The implementations that I have seen use only "r" and ignore the other
>parameters in the Tspec.  This is one of my reasons for suggesting
>that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can
>depricate use (misuse/abuse?) of the Controlled-Load Tspec for 
>MPLS/RSVP.
>
>Of course, if you did have two 100M flows and had two paths each of
>which had 100M available, you'd probably be better off spreading the
>load than putting both on the same path and that's exactly what many
>algorithms strive to accomplish rather than keep using the shortest
>path until it is full to its overbooking capacity.
>

Right, but my question is still valid. 

>Curtis

Regards,
-Shahram

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 6 Mar 2000 18:19:53 +0200 (EET)

> clarify which rate is being considered in the MPLS Admission control, CIR or

i don't think that it is either.  the rate tells how much of the link
bandwidth should be allocated for this lsp.

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 Mar 2000 13:31:38 -0500

In message <[email-masked]
> Right, but my question is still valid. 

The only CIR I could find was in the three color marker and
essentially describes a token bucket.  If applied to AF, the only
commitment implied is if the bucket is not exceeeded mark the packet
accordingly.  If marking green means no loss (which IMHO should be for
better service classes), respect that but if the drop probability of
green is non-zero, there still could be loss.  A marking of yellow or
red will certainly imply a non-zero loss probability.  Now the
question is whether the number in the Tspec is the amount of AF green
traffic (AFx1), or the total amount of AF traffic (AFxy for all y).

If one interprets the Tspec rate "r" to be the amount of AFx1 (which
apparenlty you do), then overbooking by 200% sounds more than a bit
risky, particularly if the service calls for lossless or near lossless
AFx1.  If one interprets the Tspec rate "r" to be the total of AFx1,
AFx2, AFx3, (as I did) then you can oversubscribe by 200% and toss
AFx3 traffic if you need to (was intended for AF).

I don't know if this answers your question but it does raise the
question as to whether interpretation of the Tspec "r" parameter is
ambiguous and should be clarified in draft-ietf-mpls-diff-ext-03.txt
if not superceded by putting rates directly in the MAP.

Curtis