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

[David Ward <[e-mail]>]

Jeff -

On 10/26/05 8:39 AM, "Jeffrey Haas" <[e-mail]> wrote:

> [With my co-chair hat off]
> 
> On Tue, Oct 25, 2005 at 01:28:28PM +0300, Pekka Savola wrote:
>> I still want to see the details of BFD with:
>>  - single-hop static routes
>>  - single-hop eBGP
> 
> I'd also like to see at the least the BGP/RIP case spelled out in
> a little more detail.

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

> 
> 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.

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
> to a down session.
> 

This is stated already.


> The third party nexthop case is the more interesting one.  I believe
> 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.

>> .. 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.
> 
> 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?
> 
>> 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.
> 
> [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.

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

-DWard