The MPLS WG Archive

[Anna Charny <acharny@cisco.com>]

HI Vishal,

Please see  in-line....

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

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.

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

yes, this seems to be the preferable option

Anna