Subject: RE: Proposed BFD WG

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 25 Mar 2004 14:20:06 -0500

Hi Pekka,

Yes, that static route application is exactly what I meant.

Tom Phelan

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, March 25, 2004 10:27 AM
> To: Phelan, Tom
> Cc: Rahul Aggarwal; [email-masked]
> Subject: RE: Proposed BFD WG
> 
> 
> On Thu, 25 Mar 2004, Phelan, Tom wrote:
> > > IMHO, this is probably an important point.  If we don't know any
> > > protocols we'd like to rule out right now, they should be listed
> > > there.
> > 
> > I'm having trouble parsing this.  Did you mean "If we know 
> any protocols ..."?
> 
> That's what I meant -- sorry.
> 
> > > On the other hand, listing the protocols which we should AT
> > > LEAST work on would be equally useful; for example, the 
> list could be
> > > at least: IS-IS (both IPv4 and IPv6), OSPFv2, OSPFv3, 
> eBGP, {static
> > > routes}.
> > 
> > If we're going to have a list of protocols we're going to give
> > guidelines to, I'd like to see "static routes" taken out of
> > parenthesis.  We seem to have a very router-to-router focus on the
> > uses of BFD here, but it's also very useful for high-availability
> > host systems to monitor interface and first hop router status.  In
> > these cases the routers usually have static routes to the hosts,
> > since the hosts tend to not run routing protocols.
> 
> Yes, static routes has a lot of nice areas of applicability.  The
> reason why I put it in parentheses was because it is not an
> "adjancency" being formed as such.  So if it is to be included, some
> wiggling around in the charter could be useful.
> 
> FWIW, another good for static routes is that you would not need to run
> a routing protocol between the ISP and customer if you did this for
> redundancy.  Just set up two static routes, with two physical links
> (one set of routes with lower preference), and if BFD notices the
> primary link goes down, it's taken down and you start to use the less
> preferred one automatically.  (Today this doesn't work on media which
> don't provide end-to-end link state notifications to the routers, like
> Ethernets.)
> 
> Very simple in very simple multi-connection scenarios.  No need for
> OSPF or BGP mess in a scenario where you don't need it.
> 
> -- 
> 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: Alex Zinin <[email-masked]>
Date: Thu, 25 Mar 2004 13:01:06 -0800

Folks-

 A couple of comments on this thread:

  1. I think adding some explanatory text listing the "client" protocols to
     the work item descriptions wouldn't hurt.

  2. An interesting question is how IS-IS should be covered. On the one
     hand, IS-IS does not use IP encapsulation for its packets and works
     directly over L2 (Ethernet in our case). On the other hand, I see at
     least two arguments in favor of covering IS-IS using BFD over IP:

       - IP liveness detection. Debugging networks where an IS-IS adjacency
         is up, but the line card gave up on IP for some reason is not fun,
         and adding some IP awareness at this level to IS-IS seems beneficial.
         (A question for further study is what to do when IS-IS is used for
         both v4 and v6.)

       - Media independence. Instead of defining BFD over every possible L2
         encapsulation, simply use IP.

     Maybe Daves could add something here... I remember seeing an IS-IS section
     in the bfd-v4v6 document.

  3. Regarding the question of static routes and their applicability to the
     host-router scenarios. While I don't have a problem with using BFD for
     static route's next hop liveness detection, I don't believe we should be
     putting the host-router scenarios in the charter. This brings a set of
     completely different security aspects into play, and they are likely
     to require different mechanisms than those suitable for router-to-router
     protocols (see SEND WG). I suggest we focus on the router-router case
     where we (the RTG area) are experts, and if people want to use the same
     mechanisms for the host-router case, understanding the risks, etc.--it's
     their responsibility.

-- 
Alex

---

From: Dave Katz <[email-masked]>
Date: Thu, 25 Mar 2004 14:03:11 -0800

On Mar 25, 2004, at 1:01 PM, Alex Zinin wrote:

>      directly over L2 (Ethernet in our case).

Keep in mind that the stated purpose of BFD is to demonstrate data 
protocol liveness.  In some sense the fact that it can be used to 
trigger routing protocol failover is coincidental.

If implemented in the forwarding plane, it can be used in conjunction 
with Graceless Restart to decide whether to declare a fractured 
topology in the IGP.

The interaction with IS-IS is interesting in a number of ways, the 
primary being that it supports multiple network protocols.  The latest 
(almost published) draft addresses this by saying that in the case of 
congruent topologies a BFD failure should cause adjacency teardown, 
whereas in the case of independent topologies the edge corresponding to 
the failing protocol should be removed from the graph.

The purpose of running BFD over L2 is to do datalink liveness, talking 
to switches.  One pragmatic application is to approximate subnet 
reachability by having the router chatting BFD with the switch (and no 
longer announcing the subnet in the IGP when the BFD session goes 
down.)  It could also be used as a liveness protocol in the switching 
world, but that's even further outside the WG scope, methinks.

--Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 Mar 2004 17:26:49 -0500

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dave Katz
> Sent: Thursday, March 25, 2004 5:03 PM
> To: Alex Zinin
> Cc: [email-masked]
> Subject: Re: Proposed BFD WG
> 
> 
> 
> The purpose of running BFD over L2 is to do datalink 
> liveness, talking to switches.  One pragmatic application is to
approximate subnet 
> reachability by having the router chatting BFD with the 
> switch (and no longer announcing the subnet in the IGP when the BFD
session goes 
> world, but that's even further outside the WG scope, methinks.

	One area doing BFD for L2 potentially collides with is ongoing 
work the IEEE. In particular, there is a group working on OAM
mechanisms for Enet. 

	--Tom

---

From: Dave Katz <[email-masked]>
Date: Thu, 25 Mar 2004 14:39:26 -0800

> work the IEEE. In particular, there is a group working on OAM

Yes, we're hoping BFD survives the collision.  ;-)  Dward has moles in 
the IEEE; perhaps he can fill us in as to how things are going there.

---

From: David Ward <[email-masked]>
Date: Thu, 25 Mar 2004 17:02:29 -0600

Baited out of my cave .....

Well, things are not progressing very quickly. The BFDoE draft is coming
together but, it is not talking w/ the 802.3ah (EFM folks that
are working on enet OAM) group yet. The EFM OAM folks are working on
a slow protocol that is to accomplish a lot more than simple failure 
detection. Also, they are working to change PHYs, which we are not.

Hoping that we can all get along :-)

-DWard

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 08:55:14 +0200 (EET)

On Thu, 25 Mar 2004, Alex Zinin wrote:
>      static route's next hop liveness detection, [...]

Just to make sure it's clear -- static routes are very much applicable
to router-router scenarios as well, practically between administrative
domains (or possibly stub networks).  Such links are typically used in
a point-to-point fashion (i.e., even if the media was not p-t-p, there
are only two boxes on the link).

The difference with router-host scenarios is that there the link is 
typically shared between the others, and is considered less secure.