Re: make-before-break in Gmpls

[Curtis Villamizar <curtis@fictitious.org>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <3DEF76C1.E6A29D03@lucent.com>, Yangguang Xu writes:
> Curtis,
> 
> > The ingress would need to know if bandwidth was shareable when doing a
> > reroute.  Otherwise, it may pick a path for which the RSVP signaling
> > always fails for no apparent reason.  That the RSVP signaling would
> > fail would not be apparent from the TE-LSDB before the signaling.
> > Reroute by trial and error is not a good option.
> > 
> > Is there a way for the ingress to know on which "links" bandwidth is
> > shareable?  Should it simply be assumed that bandwidth is not
> > shareable on any TDM, LSC, and FSC links?
> > 
> 
> You raised some good points here. For TDM, LSC and FSC, external resources
> (link/port) can be in two states. If a internal cross connection is performed
> ,
> the associated external resource is committed and thus not sharable anymore.
> Otherwise, it is sharable. So we can treat any non-committed resource as
> sharable. The rest are not sharable.
> 
> Then the complication is when a non-committed resource gets committed, the re
> st
> paths sharing the resource need to be re-arranged in order to guarantee the S
> LA
> in case of double failures. How does FRR handle this?

The answer to your question "How does FRR handle this?" is "not very
well at the moment but there is potential to do better".  While
seemingly flipant its an accurate answer.  I'll provide detail below.

There are two uses for SE, make-before-break and FRR.  I don't mean to
dodge your question, but I'd like to discuss make-before-break first,
then FRR.

Unlike FRR, make-before-break reroute from the ingress is done with
full bandwidth reservations (reserved and commited) and results in no
excess bandwidth being reserved and then wasted.  The new LSP is
reserved on a slightly different path but is able to share bandwidth
with the LSP it is replacing on any links in common in order to
accomplish a smooth transition.  It is important for the ingress to
know if this type of sharing is possible at all links for which both
the old and new LSP have in common and for which not enough bandwidth
is available for both the old and new without sharing.

Currently FRR cannot accurately account for bandwidth that can be
shared among backups that are not expected to fail at the same time
(do not protect any common SRLG).  This leaves two options for
deployment, reserve/commit full bandwidth on the backups or don't
reserve/commit full bandwidth on the backups.  In the former case far
more bandwidth is reserved than will ever be needed.  This might be OK
on a network that was massively overprovisioned.  In the latter case,
there is a chance that when the failures occur, the backups paths will
be congested (for packet links) or if the reservation must be
increased to "commit" the resource, then that operation will fail.

Practitioners seem to be opting for zero bandwidth reservations which
are increased to a full bandwidth reservations when the PLR puts the
backup into use.  This is not a good solution for packet networks.  It
is even less attractive for TDM, LSC and FSC.

Various methods to provide bandwidth reservation sharing have been
made going back as for as 1999 (afaik, maybe earlier as well).  Some
involve signaling the link, node, or set of SRLGs that a backup will
be using, and puts the intellegence to determine the potential for
sharing at each link.  One involves simply advertising the amount of
shareable bandwidth and sharable bandwidth used and puts the
intellegence at each PLR.

The issue of how backup bandwidth is shared, and therefore your
question of "How does FRR handle this?" is tangential to the issue of
whether TDM, LSC and FSC can share resources that are reserved and
committed by more than one LSP for which only one of those LSPs will
use the resource at one time and will use the entire resource to the
exclusion of the others.  It is "in principle" possible for TDM, LSC
and FSC (with the prior caveat regarding same-color or wavelegth
conversion).  If the ingress (or PLR for FRR) is to make an accurate
decision, then it needs to either know whether the sharing is possible
before attempting to setup an LSP, or it must assume that TDM, LSC and
FSC cannot support sharing.  IMHO traffic layout by trial and error is
not an option.

Curtis


> Thanks,
> 
> Yangguang