The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <200103282300.SAA15343@pilgrim.cisco.com>, George Swallow writes:
> This message commences a workgroup last call on LDP Fault Tollerance,      
> <draft-ietf-mpls-ldp-ft-01.txt>.  The last call closes April 11, 12 pm
> GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824


Adrian, et al,

I would like to make a comment and leave it up to the authors
discression as to whether to incorporate any change into the document.

There appears to be a school of thought where it is deemed beneficial
to keep forwarding state intact in only very limited cases such as
midnight controlled reload of routers for purposes such as software
upgrade.  This case can be even further limited to maintaining
forwarding state only if network topology has not changed while
adjacency is unavailable.

The justification for retaining forwarding state is to eliminate
unnecessary forwarding state churn that may cause transient forwarding
disruptions.  The justification for not retaining forwarding state if
topology changes is to prevent persistent forwarding problems that
could occur if loops or black holes formed as a result of inconsistent
forwarding state on a router in which the means to synchronize state
was unavailable.

Stated more simply -- Its nice to avoid dumping a few packets on the
floor but if topology changes it may be better to endure some
transient route churn than to endure inconsistent routing state that
lasts for the duration of a router reloading new software and could
dump a whole lot more packets on the floor than what the transient
would cause.

If changes are made, one possible addition would be to add a section
4.4.2:

  4.4.2  Optional Reconnect Expire on Topology Change

  <add some subset of the wording above or some explanation of why
  this is needed from the authors>

   If topology change is detected through some means outside LDP such
   as change in an Interior Gateway Protocol Link State Database
   (IGP-LSDB) it may be desireable to prematurely expire the FT
   Reconnection Timer.  An option SHOULD be provided to enable such a
   feature on a per peer basis.

I leave it entirely up to the authors as to whether they would like to
add this text.  I would prefer if something to this effect were added
unless there is objection to this addition on the list.  A vendor
could always include such a feature and make it optional and disabled
by default regardless of whether it is stated in the document so there
is little sense of urgency.

Curtis