Subject: BFD w/ static routes and single-hop eBGP

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Oct 2005 13:28:28 +0300 (EEST)

Hi,

I still want to see the details of BFD with:
  - single-hop static routes
  - single-hop eBGP

.. in some document.  At the last meeting, David said that he didn't 
believe these are necessary as the bfd-generic-01 doc includes this 
information but I disagree.  Even if the details are trivial (they may 
or may not be), as an operator I think it's vital to see them spelled 
out anywhere so that we can point vendors to a specific section of a 
spec in CFTs and ensure the protocols will be interoperable.

I suggest a section or two either in the main body of the spec or in 
an appendix either in draft-ietf-bfd-v4v6-1hop or 
draft-ietf-bfd-generic.

All of this would likely fit in one or two pages -- and if not, that 
would be even stronger reason that those details must be written out. 
At least one deployed implementation of static routes + BFD already 
exists.

-- 
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: Dave Katz <[email-masked]>
Date: Tue, 25 Oct 2005 09:52:49 -0600

Seems like we've beaten this one to death already.

For static routes, by their nature, there can be no interoperability  
problem as there is nothing to interoperate.

I don't see what else there is to specify for eBGP.  (This makes it  
considerably shorter than two pages.)

--Dave

On Oct 25, 2005, at 4:28 AM, Pekka Savola wrote:

> .. in some document.  At the last meeting, David said that he  
> didn't believe these are necessary as the bfd-generic-01 doc  
> includes this information but I disagree.  Even if the details are  
> trivial (they may or may not be), as an operator I think it's vital  
> to see them spelled out anywhere so that we can point vendors to a  
> specific section of a spec in CFTs and ensure the protocols will be  
> interoperable.
>
> I suggest a section or two either in the main body of the spec or  
> in an appendix either in draft-ietf-bfd-v4v6-1hop or draft-ietf-bfd- 
> generic.
>
> All of this would likely fit in one or two pages -- and if not,  
> that would be even stronger reason that those details must be  
> written out. At least one deployed implementation of static routes  
> + BFD already exists.
>
> --

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 26 Oct 2005 09:39:52 -0400

[With my co-chair hat off]

>  - single-hop static routes

I'd also like to see at the least the BGP/RIP case spelled out in
a little more detail.

In the case of statics, it seems reasonably clear that your BFD session
can be with the nexthop assigned to the static route.

In the case of BGP and RIP, your session probably should be with
the advertising router (RIP) or the peer (BGP) for purposes of
converging the protocol up/down state.  In the case where each of
these protocols use first party nexthops, you will typically need
this session to verify that the nexthop is reachable.  The BFD session
status could then be used to remove routes that can't be active due
to a down session.

The third party nexthop case is the more interesting one.  I believe
you'd want a BFD session for each third party nexthop.

> information but I disagree.

In the sense that you can turn on a BFD session with any address you want,
that may be clear.  What's not clear is what you'd want to do per
protocol.  Is that your argument?

> an appendix either in draft-ietf-bfd-v4v6-1hop or 

[With my co-chair hat on]

In interest in advancing the base specifications on a timely fashion,
I'd say we wish to have this in the generic document.

-- 
Jeff Haas 
NextHop Technologies

---

From: David Ward <[email-masked]>
Date: Wed, 26 Oct 2005 12:13:22 -0500

Jeff -

> I'd also like to see at the least the BGP/RIP case spelled out in

What you are saying below is that you want to see the single hop EBGP
clearly spell out that you should not use GR mechanisms (we left it
generically stated as it is clear and didn't spell out a MUST). More below

> this session to verify that the nexthop is reachable.

DWARD: Sure, this is what will happen w/ the protocol bootstrapping. I am
not sure how to make this clearer than the current wording.

 The BFD session
> status could then be used to remove routes that can't be active due

This is stated already.

> you'd want a BFD session for each third party nexthop.

I disagree here. The reason being ... What do you care about the
intermediate NHs wrt the EBGP bootstrapping since you can route to/through
different intermediate NH? The routes and peering session is still valid. In
addition, within the BGP MH scenarion; GR may be applicable (it may be not
in "your case" therefore "your choice"). As stated, you don't really care
about the intermediate nodes as you would then bootstrap the intermediate
nodes via the underlying protocol that is directing you through those
intermediate nodes. E.g. Multisession EBGP via a static route; the static
route would do the bootstrapping in this case. EBGP MH is of course, a
'routed' session like IBGP and thus, see text on layering of control
protocols.

> I'd say we wish to have this in the generic document.

We will attempt to hack what I wrote above into clearer draft language.

-DWard

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Oct 2005 08:35:21 +0300 (EEST)

On Wed, 26 Oct 2005, David Ward wrote:
[...]
> This is stated already.

A lot of things are stated already, in generic context.  What I'd like 
to see is a brief, normative description how those apply to protocol 
Foo.  If there's nothing to say (e.g., with static routes) one or two 
sentences may be enough; if there is little to say (e.g., eBGP), maybe 
a couple of paragraphs is enough.

> different intermediate NH? [...]

I agree with Dave here.  BGP hello mechanism does not monitor the 
liveness of the 3rd party nexthops, and therefore I think it goes 
beyond the scope of BFD to do that, even though BFD is meant to detect 
forwarding problems (which obviously would happen if the 3rd party 
next-hop would go away).

(It might not hurt as an extension, but we don't see a need for it.)

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 28 Oct 2005 10:59:24 -0400

On Fri, Oct 28, 2005 at 08:35:21AM +0300, Pekka Savola wrote:
> >>[Jeff]
> >[Dave]
> [Pekka]

BFD to monitor the liveness of the BGP peering session is good.
In most eBGP cases, this is also sufficient to monitor the ability of
the announced nexthop (usually the same as the address of the peering
session) to forward traffic.

In the case of third party nexthops, it isn't.

To give an example that may have bitten some people in this working
group, presume an exchange point where peering is done via eBGP.
In the case that third party nexthops are permitted, you can announce
a nexthop that would normally be considered reachable because you are
on a shared subnet.  If the nexthop is not reachable for some reason,
but the peering session is up, a blackhole will occur.

Solutions: 
- Disallow third party nexthops.
- Run a BFD session on your nexthop.

-- 
Jeff Haas 
NextHop Technologies

---

From: David Ward <[email-masked]>
Date: Fri, 28 Oct 2005 10:58:28 -0500

Jeff -

> BFD to monitor the liveness of the BGP peering session is good.

No, it is bad :-) We state that you can attempt to use BFD for control plane
liveness (you can do anything you want) but, BFD is for the control plane
and we don't suggest that you use it for the control plane liveness at all.
We suggest that control protocols Hello packets run sedate and instead, use
BFD just for the forwarding plane.

> - Run a BFD session on your nexthop.

Run a BFD session on the NH but, don't have it test the BGP session. Only
the NH. Echo mode is wonderful for this :-)

-DWard