The MPLS WG Archive

[afarrel@movaz.com]

Curtis,

I can't see any reason not to point out that a "give up and run away" type
of timer can be overridden by other events.  The one you suggest
(significant IGP change) could well be applicable to LDP, although I think
it is less significant in CR-LDP.

I find...
> 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.
...odd.  When a line card fails I should like to be able to swap to a new
card and continue forwarding data with only a very short (10s of ms) break.
Adrian
--
Adrian Farrel
Movaz Networks Inc
afarrel@movaz.com


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, April 03, 2001 3:07 PM
> To: George Swallow; af@dataconnection.com; pjb@dataconnection.com;
> philipma@nortelnetworks.com; eric.gray@sandburst.com
> Cc: mpls@UU.NET
> Subject: Re: Last Call on LDP Fault Tollerance 
> 
> 
> 
> 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
>