Subject: BFD for different BGP next hops

From: Carlos Garcia Braschi <[email-masked]>
Date: Tue, 20 Dec 2005 19:48:41 +0100

Hi,

Let's say there is an implementation of BFD used to test reachability
of routes announced through a BGP routing session. Let's say that the
BGP session announces several routes with different next hop
addresses, but all of them are inside the same subnet (so that they
could use bfd-v4v6-1hop). This could be the case, for example, in a
peering point.

I have a doubt: would a router implementing this establish a BFD
session with each next hop received or just with the BGP peer?

Although from the point of view of BFD interoperability this is of no
concern, from the point of view of using BFD in the practical sense,
it is quite important, as I would expect a BFD session with each next
hop, but probably others would like to check just the BGP peer and
think about this case an exception rather than the norm.
And the behaviours would be quite different...

Is this just an implementation option/issue that router manufacturers
may or may not offer? Should it have a name and/or more formal
description?

Something similar may happen with RIP but I think no one uses the
option so it's not an issue...

Regards,
Carlos.
--
Telefónica Empresas.

---

From: Bill Barns <[email-masked]>
Date: Tue, 20 Dec 2005 14:24:52 -0500

A situation that interests me is health monitoring of labeled paths coming
from BGP using RFC 3107 when route reflector servers are the means of
distributing those paths/LSPs.  BFD to the BGP peer isn't helpful to that
goal.  And that seemed to give me an excuse to inquire whether BFD to the
next hops is a good idea for this purpose or if I should be looking
elsewhere.

For better or worse, there sure are a lot of features and flavors of OAM /
link monitoring / connectivity verification / failure detection from various
points of view that could arguably be part of the picture.  Overall I find
that more disorienting than helpful, though.

/Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carlos Garcia Braschi
Sent: Tuesday, December 20, 2005 1:49 PM
To: [email-masked]
Subject: BFD for different BGP next hops

Hi,

Regards,
Carlos.
--
Telefónica Empresas.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Dec 2005 23:53:38 +0200 (EET)

> session with each next hop received or just with the BGP peer?
...

This issue has been discussed a couple of times on the list, without a 
clear conclusion; some folks think that BFD should only be used to the 
BGP session end-point (which gives roughtly the same amount of 
liveness testing as today), Jeff Haas has thought it would be useful 
to test the liveness to the 3rd party next-hops as well as that's one 
potential failure mode.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: David Ward <[email-masked]>
Date: Tue, 20 Dec 2005 18:04:36 -0600

Bill -
    In this case you would:

0) Form a BFD session to the RR via BGP bootstrapping

1) Form BFD sessions to the nexthops via IGP bootstrapping throughout the
topology.

Thus, if the RR was using nexthopself you would be covered and also for all
interior nexthops.

For EBGP nexthops, one should form BFD sessions via EBGP bootstrapping.  For
third party nexthops, you will need to cause bootstrapping  to occur via
other means (e.g. via CLI/NMS). Since it is rare/not-wise/violating
reasonable security measures to blindly accept all third party nexthops, the
authors believe it is also not wise to for BFD sessions via "triggered"
third party nexthops and recommend a configured session to be enabled if
desired.

Hope it helps.

-DWard

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 22 Dec 2005 12:22:51 -0500

> Thus, if the RR was using nexthopself you would be covered and also for all

As a further (probably unneeded) clarification, for iBGP you probably wouldn't
want to form BFD sessions for the nexthops in the non-directly connected
case.  In the event of an event in your internal network that affected
forwarding, BFD between the various routers will cause the necessary IGP
event to happen that will cause BGP to do the Right Thing.  

However, if the Right Thing isn't timely enough (time to flood and reconverge
the IGP at a given BGP speaker, maybe in the several second range), a
BFD session to a given iBGP nexthop *might* provide faster convergence.

Personally, I think it'll just result in your thrashing your BGP every
time you have lossy forwarding at any internal link. :-)

The directly connected iBGP case resembles the eBGP case, so I'll comment
on that below.

> third party nexthops and recommend a configured session to be enabled if

This is clearly a "rope" situation - give the customer what they want
and they're likely to hang themselves.  This wont stop someone from getting
such rope installed. :-)

BFD sessions to directly connected nexthops, triggered or not, can
be helpful in situations where forwarding connectivity may not be properly
reflected in the routing.  ATM and frame relay networks, as examples,
are vulnerable to blackholes resulting from imperfect meshing or
failures in a given virtual circuit.  

Code wise, it might be appropriate to treat a nexthop with which you've
enabled BFD to have the same effect as an unreachable IGP nexthop when
you have a BFD session failure.

-- 
Jeff Haas 
NextHop Technologies