Subject: RE: FW: Internal WG Review: Recharter of Bidirectional Forwarding Detection (bfd)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Jun 2014 17:30:27 +0100

Hi Stewart,

Pedantry noted :-)

> > The BFD Working Group is chartered to standardize and support the
> > bidirectional forwarding detection protocol (BFD) and its extensions.  A
> > core goal of the working group is to standardize BFD in the context of
> > IP routing, or protocols such as MPLS that are based on IP routing, in a
> > way that will encourage multiple, inter-operable vendor implementations.
> 
> Isn't BFD also used to support TRILL (which has no basis on IP)?

It may be true that many other folk use BFD for all sorts of things. That doesn't change the fact of "a core goal of the working group"

> >> Important characteristics of BFD include:
> >>
> >> - Simple, fixed-field encoding to facilitate implementations in
> >>    hardware.
>
> Well it does have options. Perhaps you just mean hardware efficient
> encoding.

Yeah, that is a bit ambiguous. I think we can say that the core protocol uses simple, fixed-field encodings and it is only the options (which are, erm, optional) that cause variable encoding.

> >> - Path independence: BFD can provide failure detection on any kind of

> Any kind of path is a bit ambitious!

In the IP context, isn't this true? Let's run BFD over avian carriers to show that this works.

> >>    path between systems, including direct physical links, virtual
> >>    circuits, tunnels, MPLS LSPs, multihop routed paths, and
> >>    unidirectional links (so long as there is some return path, of
> >>    course).
> >>
> >> - Ability to be bootstrapped by any other protocol that automatically
> >>    forms peer, neighbor or adjacency relationships to seed BFD endpoint
> >>    discovery.
>
> Similarly here "any" is very ambitious.

I think BFD doesn't care what protocol bootstraps it.

Cheers,
Adrian