Subject: Multiple BFD sessions and Discriminator

From: Glen Kent <[email-masked]>
Date: Thu, 17 Jun 2010 06:01:20 +0530

Hi,

If multiple BFD sessions exist on a LAN segment between two nodes, the
BFD descriminator is used to demultiplex the BFD control packets to
the appropriate BFD session. Given this I am unable to envisage a case
where i will have multiple BFD sessions between the same set of nodes.

Assume i have the following setup:

Router A ---- Router B

I am running BFD on the interface connecting the two routers
I am running OSPF between them and its using BFD
I have a static route on A for which the nexthop is B, and that too is
covered using BFD.

Is this the scenario where i will have multiple BFD sessions between
the two sets of routers?

What is the utility of having two sessions. Why cant just one session
work. If BFD goes down, then it can locally inform both OSPF and the
static route manager on A about this, so that router A can take the
appropriate action.

How does having multiple BFD sessions help?

One reason that i can think of is, if the user wants different Rx and
Tx intervals. However, this seems inane. Why would anybody want to
detect one failure quicker than the other?

Or is it that we only assume multiple BFD sessions between the same
set of routers in case of multihop BFD?

Glen

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Jun 2010 00:50:55 +0000

> Is this the scenario where i will have multiple BFD sessions between

You want RFC 5881, section 3.  There will be one session between two systems
over a given interface.  RFC 5880, section 6.3 may also be helpful.

> How does having multiple BFD sessions help?

You would have one session between systems on a given interface for each
address family.  E.g. ipv4, ipv6.

-- Jeff

---

From: Dave Katz <[email-masked]>
Date: Wed, 16 Jun 2010 18:42:16 -0700

If you have separate V4 and V6 sessions, the two sessions are demultiplexed first at the encapsulating data protocol (V4 vs. V6) so they don't occupy the same namespace or any other universe.

Each session protects the data protocol on top of which it runs, so in this case, V4 and V6 have separate fate, as they should.

You're exactly right about the reasons not to have multiple sessions when running over the same L3 protocol (OSPF2 and v4 static routes, etc.)

--Dave

---

From: Glen Kent <[email-masked]>
Date: Thu, 17 Jun 2010 07:38:41 +0530

Hi Dave,

Ok, so we dont need a discriminator to disambiguate between v4 and v6
directly connected sessions. We can thus infer that discriminator is
really required *only* for multihop BFD sessions. Is this correct?

And the reason its required there is because i could have, to cite one
example, multiple LSPs from router A to router B and i would like to
run BFD on each of these paths.

Using the source IP and dest IP is not enough as this would be same
for all the BFD packets over each of these paths, and hence the
discriminator. On a single hop BFD, i can simply use the source IP and
dest IP to disambiguate between different BFD sessions.

Glen

---

From: Dave Katz <[email-masked]>
Date: Wed, 16 Jun 2010 20:25:47 -0700

> dest IP to disambiguate between different BFD sessions.

This is true in some contexts (and you could add the input interface to the list of demuxing values) but the base spec is very specific:

   Once the remote end echoes back the local discriminator, all further
   received packets are demultiplexed based on the Your Discriminator
   field only (which means that, among other things, the source address
   field can change or the interface over which the packets are received
   can change, but the packets will still be associated with the proper
   session).

Once the discriminator value is established, it is the *only* thing used to demultiplex the packet to the appropriate BFD session--not source or destination address, and not input interface.  This allows for almost anything to change--the addresses, even the other guy's discriminator value.  You're free to change your own discriminator value, and the other guy will parrot it back at you, and you can still demux your packets.

It is true that you could sort out one-hop sessions with other things (you can't solely use the IP address because it could change if you're talking over an unnumbered link, for example) but we chose to have a single mechanism for simplicity--it is always the same, regardless of application (one-hop, multihop, etc.), and medium (LAN, point-to-point.)  It also allows other things to change that might be outside the purview of BFD (such as addresses).  It also minimizes assumptions about the encapsulation of the BFD packet, since it could be run in places other than the network layer.  As such, having a single, well-defined, fully-contained mechanism to demultiplex packets was deemed critical.

--Dave