Subject: RE: Last Call on LDP Fault Tolerance

From: [email-masked]
Date: Tue, 3 Apr 2001 21:45:45 -0400

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
[email-masked]

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 3:07 PM
> To: George Swallow; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call on LDP Fault Tollerance 
> 
> 
> 
> In message <[email-masked]>, 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Apr 2001 19:05:41 -0400

In message <[email-masked]
> card and continue forwarding data with only a very short (10s of ms) break.

When a line card fails, that line card will still be in the box for at
least a few minutes, more likely the better part of an hour, maybe
longer.  I don't know of any technician that can swap a line card in
10 msec.  I also don't know of any line card that can reboot in 10
msec.  When a line card fails if there is a TE tunnel and
local-protect on the TE tunnel, then the switch over is very fast.  If
it is LDP without TE or TE without local protect, the 10s of msec is
very likely not acheived.  That has absolutely nothing to do with
LDP-FT so I don't see why you brought it up.

At issue with LDP-FT is when the route processor fails and the line
card does not fail.  That is when the forwarding entries remain intact
and the LDP adjacency will be back shortly.  That is the case if the
route processor's software is reloaded for software upgrade.

As I said, I'll leave it up to the authors whether they want to make
any change to the document.  It sounds like you don't.  That's fine.

Curtis

---

From: "Philip Matthews" <[email-masked]>
Date: Wed, 04 Apr 2001 23:12:54 -0400

I would be happy to include a paragraph or two about the interaction with
a significant IGP change. I can see that mentioning this issue would help
people understand the implications of Fault Tolerance better. However, 
I would prefer to say that an implementor MAY wish to abort the session recovery
effort in this case, rather than saying that the implementor SHOULD implement an option
to enable this on a per-peer basis. I don't think we understand this issue
well enough yet to recommend such an option.

But I am strongly against limiting (or even suggesting limiting) 
the use of fault tolerance to midnight software upgrades. I think other uses
are quite valid. Adrian's redundant line cards are one good example.
Another one is redundant control planes.

- Philip Matthews
  Nortel Networks Corporation

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 05 Apr 2001 13:00:05 -0400

>   Nortel Networks Corporation

The redundant control plane was the reason I had suggested that a per
peer option would be good.  The assumption is that if the peer had a
redundant control plane the timer would not be prematurely expired
since the expectation is for the peer to recover faster than the IGP
would converge or at least in the same order of magnitude.  For the
peer that had a single control plane, the timer would be expired
prematurely under the assumption that it could be a long timer (in
terms of tolerable outage) before the peer came back.

The per peer option also gives the operator the chance to decide if
this feature is better off enabled or disabled.  I'm assuming network
operators have fairly high intellegence and that is better to give
them this control (along with hints regarding any accumulated
experience in the field in the event someone else had experience).

Curtis