Subject: RE: link bundling in MPLS TE

From: Shahram Davari <[email-masked]>
Date: Fri, 3 Mar 2000 12:19:17 -0800

Hi Kireeti,

1) I can't figure out how advertising bundle UB(p), can help a node compute
multiple LSPs without waiting for the IGP update of bundle MLB(p). The
reason is that there is no relationship between these two values except
that:

bundle MLB(p)<= bundle UB(p)

But this bound is so loose that it is of no practical use. Am I missing
something here?

2) There seems to be some problem with your LSP set up logic. In your
example, let's add another LSP of priority 0 and b/w 100M to the top link.
This LSP will be accepted because for priority 0 in the top link you have:

         top link
      ---------------
      max-LSP    Unres
prio
0      100        100

Therefore we now have 2 LSPs of priority 0, each 100M passing through the
top link. Now if instead of these 2 LSPs you had tried to setup a single LSP
of priority 0 and b/w 200M for the top link it would have failed, because
max-LSP= 100M. Right?

Regards,
Shahram

>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Sunday, February 27, 2000 3:58 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: link bundling in MPLS TE
>
>
>Hi Rahul,
>
>Thanks very much for the comments, to you and others.  Yes, there are
>several things that should be clarified.  Let me run the following by
>you, and once we get feedback, we'll make the changes in the draft.
>
>Advertised bandwidth quantities:
>1) Max LSP bandwidth (per priority p)	 [MLB(p)]
>2) Reservable link bandwidth		 [RLB]
>3) Unreserved bandwidth (per priority p) [UB(p)]
>4) Maximum link bandwidth (to be deprecated? not discussed below)
>
>For a simple (unbundled) link, the initial values are:
>1) MLB(p): either assigned by the administrator, or set to the
>           link capacity.  Call the initial value IMLB(p).
>2) RLB: assigned by administrator; defaults to link capacity.
>3) UB(p): is set to RLB.
>
>As LSPs come and go, the values change as follows:
>1) MLB(p): min of {IMLB(p), UB(p)}
>2) RLB: doesn't change.
>3) UB(p) decreases by B if an LSP of holding priority <= p and b/w B
>   is set up throught this link; increases by B if an LSP of holding
>   priority <= p is torn down.  (Note: smaller p means higher 
>priority.)
>
>Extending this to bundled links:
>1) MLB(p) of a bundled link is  max {MLB(p) of component links}.
>2) RLB of a bundled link is     sum {RLB    of component links}.
>3) UB(p) of a bundled link is   sum {UB(p)  of component links}.
>
>As mentioned in the draft, RSVP must keep state per component link;
>but RSVP only needs to tell the IGP the 'bundled' values.
>
>As far as CSPF/RSVP is concerned, a link (bundled or otherwise) has
>enough b/w for an LSP with setup priority p and b/w B iff MLB(p) >= B.
>
>Advertising unreserved b/w allows an LSR to compute multiple successive
>LSPs without receiving IGP updates by locally tracking the UB for each
>link.  Of course, there are several potential holes in such a scheme;
>bundled links add the further problem that there may in fact be
>sufficient unreserved bandwidth but max LSP b/w is too small.
>
>Unreserved b/w and reservable b/w are also useful for 
>tie-breaking purposes.
>
>Comments and suggestions are very welcome.
>
>Example: consider the three links from A->B as a bundle.  Note: only
>the 'bundled link' values are advertised; the others are local state
>maintained by RSVP.
>
>            -------->
>          A --------> B
>            -------->
>
>Top link is 100Mbps (reservable 200M), middle one is 50M 
>(reservable 150M)
>and bottom is also 50M (reservable 100M).  Let's consider just 
>3 priority
>levels.
>
>Initially:
>
>           bundled link        top link     middle link     bottom link
>         --------------   -------------   -------------   -------------
>prio     max-LSP  unres   max-LSP unres   max-LSP unres   max-LSP unres
>   0        100M   450M      100M  200M       50M  150M       50M  100M
>   1        100M   450M      100M  200M       50M  150M       50M  100M
>   2        100M   450M      100M  200M       50M  150M       50M  100M
>
>An LSP with priority 1 and b/w 50M is set up on the middle link.  Now,
>the b/w picture is:
>
>           bundled link        top link     middle link     bottom link
>         --------------   -------------   -------------   -------------
>prio     max-LSP  unres   max-LSP unres   max-LSP unres   max-LSP unres
>   0        100M   450M      100M  200M       50M  150M       50M  100M
>   1        100M   400M      100M  200M       50M  100M       50M  100M
>   2        100M   400M      100M  200M       50M  100M       50M  100M
>
>An LSP with priority 2 and b/w 100M is set up on the top link.  Now,
>the b/w picture is:
>
>           bundled link        top link     middle link     bottom link
>         --------------   -------------   -------------   -------------
>prio     max-LSP  unres   max-LSP unres   max-LSP unres   max-LSP unres
>   0        100M   450M      100M  200M       50M  150M       50M  100M
>   1        100M   400M      100M  200M       50M  100M       50M  100M
>   2        100M   300M      100M  100M       50M  100M       50M  100M
>
>An LSP with priority 0 and b/w 100M is set up on the top link.  Now,
>the b/w picture is:
>
>           bundled link        top link     middle link     bottom link
>         --------------   -------------   -------------   -------------
>prio     max-LSP  unres   max-LSP unres   max-LSP unres   max-LSP unres
>   0        100M   350M      100M  100M       50M  150M       50M  100M
>   1        100M   300M      100M  100M       50M  100M       50M  100M
>   2         50M   200M        0M    0M       50M  100M       50M  100M
>
>An LSP with priority 1 and b/w 80M is set up on the top link.  To
>do this, the 100M LSP at priority 2 has to be preempted.  Now, the
>b/w picture is:
>
>           bundled link        top link     middle link     bottom link
>         --------------   -------------   -------------   -------------
>prio     max-LSP  unres   max-LSP unres   max-LSP unres   max-LSP unres
>   0        100M   350M      100M  100M       50M  150M       50M  100M
>   1         50M   220M       20M   20M       50M  100M       50M  100M
>   2         50M   220M       20M   20M       50M  100M       50M  100M
>
>etc.
>
>Kireeti.
>

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 3 Mar 2000 12:46:36 -0800 (PST)

Hi Shahram,

> But this bound is so loose that it is of no practical use. Am I missing

There are no guarantees that an LSP setup will work: a node sees that
100M is available on some link, and sets up an LSP through it, only to
find that another node got there first.  Or, thanks to IGP holding down
updates, the link-state database could be stale.

That said, one does one's best with the info available.  If MLB and UB
are both advertised (say 100M and 1000M respectively), a node can say
"maybe setting up 10 100M LSPs will work".  If the actual link bundle
consists of 10 100M links, that works.  If the bundle was 5 100M links
and 10 50M links, only 5 of the LSPs work.  etc.

If only MLB was advertised, a node has no info as to whether a link with
MLB 100M can accommodate 1 or 100 100M LSPs.

Of course, the whole point of bundling is reducing information -- in
the process you lose some useful info, but you gain scalability.  If
the above bundle of 5 100M links and 10 50M links were individually
advertised (not bundled), you would have 'perfect' info, for some notion
of perfect.  However, your IGP state would be 15 times as large.

> This LSP will be accepted because for priority 0 in the top link you have:

Right.  Where is the problem?

Kireeti.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 3 Mar 2000 12:54:44 -0800

Hi Kireeti,

>Sent: Friday, March 03, 2000 3:47 PM
>To: [email-masked]; [email-masked]; [email-masked]
>Subject: RE: link bundling in MPLS TE
>
>
>Hi Shahram,
>

Fine. Thanks for the explanation.

>Right.  Where is the problem?

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. But in fact you are routing the same traffic
through that component. This is rather odd? isn't it?

Regards,
-Shahram

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 3 Mar 2000 13:04:23 -0800 (PST)

Hi Shahram,

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

---

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

Juha,

----Original Message-----
>From: Juha Heinanen [mailto:[email-masked]]
>Sent: Monday, March 06, 2000 11:20 AM
>To: Shahram Davari
>Cc: [email-masked]'; 'Kireeti Kompella'; [email-masked]
>Shahram Davari writes:
> > 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?
>
>i don't think that it is either.  the rate tells how much of the link
>bandwidth should be allocated for this lsp.
>

But according  to this draft the Sigma of the BW of all admitted LSPs can
have a higher BW than the link BW. That is why max-LSP-BW and Unreserved-BW
are introduced separately for a link. Max-LSP-BW does not necessarily reduce
when an LSP is admitted, but unreserved-BW does!!! In other words
unreserved-BW ,which includes an oversubscription factor, is mainly used for
Admission control. So when an LSP of rate "r" wants to be admitted then "r"
should also include an oversubscription factor. Right?

-Shahram

>-- juha