Subject: RE: BFD on LAG requirements (was Re: Multicast vs. Unicast (was BFD on LAG interfaces))

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jan 2012 18:18:03 +0200

Jeff hi,
Your "buggy implementation stories" sound quite realistic.
However I am not sure that BFD can provide a workaround for those.
E.g., consider an implementation that first of all looks up the Destination IP address of a received packet in a short list of "special" IP addresses (ingress interface addresses, non-routable unicast and multicast addresses etc.), sends matching packets to the appropriate entities and only then begins the longest prefix match lookup in a suitable FIB (potentially holding hundreds of K of prefixes). 

Bugs or HW failures in such an implementation could easily result in OSPF adjacency and 1-hop IPv4 BFD session monitoring this adjacency coming (and staying) UP while transit IP traffic (or part thereof) would be lost. 

In other words, I am not sure whether your "one step further into the box" adds substantial value.

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jeffrey Haas
> Sent: Thursday, January 12, 2012 4:49 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was
> BFD on LAG interfaces))
> 
> On Thu, Jan 12, 2012 at 05:02:38AM +0530, Bhatia, Manav (Manav) wrote:
> > IS-IS packets don't follow the exact data path as the IP packets (since IS-IS
> uses L2 encap) and yet once the IS-IS adjacency goes up we trust that we can
> use that link for IP forwarding. Even OSPF for that matter does not follow
> the exact same data path as IP unicast packets since OSPF packets are
> multicast (except for DDs which are unicast). In both cases the protocols
> don't follow the same data path as IP unicast and yet we conclude that the
> IP routes are reachable based on the information provided by these
> protocols.
> 
> I'm going to pick on the OSPF case for a second.
> 
> There have been about three incidences I can remember over the years
> where
> OSPF was failing to work right for me that were eventually diagnosed to be
> multicast vs. unicast reachability issues on the exact same link.  In these
> cases, the issue was outright buggy implementation.  (And in 2/3 of the
> cases, resetting the interface cleared the problem.)
> 
> While I can agree with Pablo that we're not testing traffic *through* the
> box but only *to* the box (a very shallow test for a box we probably want to
> use as a transit router), I still think testing to the layer 3 is one step
> better than not.  Bugs such as the ones discussed above make me leery of
> doing otherwise.
> 
> (And we're not going to even talk about IS-IS bugs where IP wasn't up...)
> 
> -- Jeff

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.