The MPLS WG Archive

["Vishal Sharma" <v.sharma@ieee.org>]

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

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anna
> Charny
> Sent: Tuesday, September 10, 2002 10:37 AM
> To: v.sharma@ieee.org
> Cc: Shahram Davari; 'mpls@UU.net'
> Subject: RE: Comments on Backup-Computation draft
>
>
> Hi Vishal,
>
> Please see below.
>
> At 10:01 AM 9/10/2002 -0400, Vishal Sharma wrote:
> >Anna, Shahram,
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anna
> > > Charny
> > > Sent: Thursday, August 15, 2002 5:35 PM
> > > To: Shahram Davari
> > > Cc: 'mpls@UU.net'
> > > 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.
>
> 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. "

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.

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

Agreed.

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

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.