Subject: RE: Comments on Backup-Computation draft

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 10 Sep 2002 10:01:30 -0400

Anna, Shahram,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Anna
> Charny
> Sent: Thursday, August 15, 2002 5:35 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: Comments on Backup-Computation draft
>
>
<<snip>

> >8) Section 6.2.1 suggests finding the backup pool, by subtracting the
> >global reservable BW from the link BW. How does a node know the
> link BW to
> >do this computation?
>
> Here is an example with OSPF (link TLV of the TE opaque LSA):
>
> Sub-TLV 6 - Maximum Bandwidth
>
>     The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
>     can be used on this link in this direction (from the system
>     originating the LSA to its neighbor), in IEEE floating point format.
>     This is the true link capacity.
>
> Sub-TLV 7 - Maximum Reservable Bandwidth
>
>     The Maximum Reservable Bandwidth sub-TLV specifies the maximum
>     bandwidth that may be reserved on this link in this direction, in
>     IEEE floating point format
>
> Maximum bandwidth - Maximum Reservable Bandwidth = Backup bandwidth pool.
>

I seem to recall that the maximum reservable bandwidth can, in fact, be
set to be _larger_ than the link capacity to allow for admitting
traffic/LSPs
whose cumulative b/w exceeds the maximum bandwidth, in those cases where
link oversubscription is allowed or desired.

As a result, the backup bandwidth pool may not be directly derivable from
the simple calculation above, unless there an assumption of a network-wide
policy of
using no oversubscription.

-Vishal

---

From: Anna Charny <[email-masked]>
Date: Tue, 10 Sep 2002 10:37:27 -0400

Hi Vishal,

Please see below.

>using no oversubscription.

It is correct that the maximum reservable bandwidth may indeed be larger 
than link speed.  However, in the section of the draft that Shahram cites 
we explicitly say that the above computation can be used IF max reservable 
bandwidth is configured to be less than link speed.  This is not an 
entirely unreasonable setting as the context of the discussion is strict 
bandwidth protection.  Here is the quote:

"Also, the backup pools can be implicitly derived from the routing 
information already available. This could be done by configuring max global 
reservable pool to being less than the link speed by the desired value of 
the backup pool. Every node computing its backup tunnels then can by 
default use link speed minus the max global reservable pool as the value of 
the backup pool to use in its computation of the backup tunnels placement. "

However,  if the backup pool is propagated explicitly in the IGP 
extensions, as is really the preferred option for the distributed 
computation, then the backup bandwidth can be set up explicitly, 
independently of the max reservable global.  So under a single failure 
assumption, the effective maximum overbooking  on a given link would be 
essentially defined as the sum of max reservable bandwidth plus explicitly 
defined backup pool divided by the link speed.

Finally, in the case of a centralized server the desired degree of 
overbooking (if any) can be specified in the server.

Does this make sense to you?

Thanks,
Anna

---

From: "Vishal Sharma" <[email-masked]>
Date: Wed, 11 Sep 2002 13:27:30 -0400

Hi Anna,

Thanks for your responses. Please see some comments in-line.
(I have some further comments on the draft, which I'm sending
in a separate email.)

-Vishal

> Sent: Tuesday, September 10, 2002 10:37 AM
> To: [email-masked]
> Cc: Shahram Davari; [email-masked]'
> Subject: RE: Comments on Backup-Computation draft
>
>
> Hi Vishal,
>
> Please see below.
>

I agree that under the assumption of max. reservable b/w being configured
to being less than link speed, things are ok. However, it is not
clear that a SP that has BE and protected traffic in the network
would like to do that, since this does not allow for overbooking
for BE traffic.
(In that case an option might be to use the DiffServ TE extensions
appropriately, but I need to think more about that.)

Or, as you've suggested below, have an IGP extension that advertises
the backup bandwidth pool, which decouples it from max. reservable
bandwidth.

> defined backup pool divided by the link speed.

Agreed.

> Does this make sense to you?

Yes. In the case of a centralized server, of course there is complete
freedom in what can be configured, which policies can be applied etc.,
so that is a simpler case to talk about, in this sense.

---

From: Anna Charny <[email-masked]>
Date: Wed, 11 Sep 2002 14:30:05 -0400

HI Vishal,

Please see  in-line....

<snip>

>appropriately, but I need to think more about that.)

Yes, we assumed that if you only want to protect some traffic but not all, 
then you may want to use DS-TE and specify
max reservable subpool as the primary pool you want to protect.  However, 
in a dynamic setting this would require having a system-wide understanding 
that this is what is being done, which is a risky assumption.

In general, I feel that without IGP extensions our approach has a valid but 
limited use in a dynamic setting, and that the IGP extensions are really 
going to make a difference in flexibility in the choice of how much 
bandwidth available for protection, and what the desired maximum 
overbooking is in case of failure.

>the backup bandwidth pool, which decouples it from max. reservable

yes, this seems to be the preferable option

Anna