[j-nsp] ISIS and BFD

[Richard A Steenbergen]

On Tue, Dec 29, 2009 at 08:23:23PM +0800, Mark Tinka wrote:
> On Tuesday 29 December 2009 06:29:27 pm 
> martin.mogensen at bt.com wrote:
> 
> > The feedback I've had previously from Juniper is the
> >  re-establishment of the adjacency even though BFD is
> >  filtered is intended behaviour. A BFD session isn't a
> >  requirement for re-establishing the adjacency - BFD is
> >  instead used for tearing down the adjacency in case of
> >  BFD timeout *after* the BFD session has been
> >  established.
> 
> This would make sense to me, and perhaps, something I'd 
> support if BFD decided to "go off the rails".
> 
> However, all things being equal, in most cases, failure of 
> BFD packets to be sent/received across a link would likely 
> lead to a failure of the IGP frames/packets from being 
> sent/received on the link anyway.

How would you handle the case where one side decided to unconfigure BFD
then? The current behavior allows you to configure BFD everywhere, and
if the other side doesn't support it they simply don't respond to the
packets and the session operates without BFD. If you didn't bring the
session back up without BFD coming back, you would effectively keep the
session down forever if one side needed to remove it.

Maybe it would make sense to have a configuration option where you want 
to enforce that if the other side isn't speaking BFD you don't want to 
bring the session up at all. I haven't actually read enough of the spec 
to know if you can do that though (i.e. it may require that the neighbor 
come up before the neighbor signalled BFD can start for all I know).

BFD is one of those features which sounds like it should be a really
good thing, but which still has a lot of design flaws and implementation
bugs to work out. For example, Cisco doesn't support BFD on 6500/7600
SVIs, and implements it on the same CPU as the control-plane on those
platforms, leading to many false positives unless you have very high
timeout values. Juniper doesn't support BFD on IPv6 (and more to the
point, causes a commit error if you try to apply it at the BGP group
level and happen to have an IPv6 neighbor in that group), nor a
mechanism to disable BFD on a specific neighbor below a group level. We
frequently get complaints from peers about "why are you sending me these
packets!" when we enable BFD at a BGP group level, and we lack any
mechanism to disable it for just them. The MPLS bootstrapping mechanism
for BFD using lsping is a complete disaster too, and it doesn't appear
to support BFD when doing ECMP over multiple RSVP LSPs either.

One area I've been meaning to test but haven't had the time is security,
i.e. how easy is it to cause an outage by inducing a false positive
failure with a BFD flood. There is an inherient TTL security mechanism
in BFD (setting ttl to 255 and expecting 254 from your directly
connected neighbor), but we all know that Juniper has no native TTL
security support anywhere else (shamefully :P), requiring you to
manually filter the packets in firewall filters if you want to actually
block them. It would be interesting to see what happens when you get a 
BFD flood and don't apply those manual firewall filters, especially for 
older platforms or other vendors which don't support TTL matching in 
filters.

Overall we've had very poor luck getting any significant amount of
adoption from remote networks in the places where it is needed most,
such as over Internet exchange points (where the lack of link state can
cause very significant blackholing periods in the event of an issue,
90-180 secs with default hold timer values). I really wish Juniper would
implement BFD Echo Mode, which would make it far more useful when
working with third party networks like peers. Instead of sending BFD
packets and expecting your peer to generate BFD packets of their own,
Echo Mode sends the BFD packets to the peer via layer 2 (e.g. their DST
MAC, in the case of ethernte) but with your IP in the layer 3 DST IP
field. This results in the peer returning the packet to you entirely via
their forwarding plane, and doesn't require them to support BFD on their
control plane at all. The other implementation I'd like to see is the
ability to do an "interface bfd", where a failure of a specific BFD
session (or sessions) makes the interface route ineligable for use as a
nexthop in other routing protocols (similar to how link down does the
same). This would be especially useful in multipoint lan scenarios, such
as Internet exchange points, where you could bring down the entire 
interface rather than having to test BFD to 500 peers on that interface 
(where only 3 actually support BFD currently anyways :P).

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)