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

From: Suping Zhai <[email-masked]>
Date: Wed, 26 Oct 2005 09:27:39 +0800

Hi,
Perhaps what we, at least Pekka and me, concern is that we should have a very clear definition of what eBGP should do in order to bootstrap BFD, and what is the specific interactions between BGP and BFD session.
What I want to further to do is that as well as BGP, how the RIP(v2) should react when run with BFD, regarding to the BFD bootstrapping and interactions with BFD.
Or else there is no strict rules to run BFD in various situations, and the result will be that the interoperation become a problem. Just a few pages can solve this problem, why do we wait and see:(

Best Regards,
Suping
>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:
>
>> 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 21:50:38 -0600

I think that part of the problem here is that people view BFD as some  
sort of extension to other protocols, or somehow tightly coupled to  
them.

The problem seems (at least to me) a lot less worrisome if you look  
at BFD as a standalone service.  As such, there is no  
interoperability issue in the traditional sense;  all compliant BFD  
implementations are guaranteed to interoperate, end of story.

The interaction between BFD and its clients is not an  
interoperability issue, as it is purely an internal implementation  
issue.  The interaction does not need to be the same (or even  
present) at both ends;  it would be entirely reasonable for only one  
eBGP peer to be caring about the BFD session (which might have been  
bootstrapped for some other reason independent of eBGP) and it would  
still be useful and would still not cause interoperability issues.   
This is identical to other mechanisms (say, SONET alarms.)  There is  
no specification for how OSPF interacts with SONET alarms, but it is  
arguably useful, and it doesn't have to be done the same way (or at  
all) on every system in order for things to interoperate.

This is equally true of bootstrapping.  The fundamental issue is in  
finding (or launching, if it's not there already) a BFD session that  
corresponds to your protocol session in terms of the identity of the  
neighbor.  This doesn't have to be done the same way (or at all) at  
each end of the protocol session.  For that matter, if you managed to  
end up with two parallel BFD sessions due to addressing issues, you  
could even have each end of the protocol session interacting with a  
*different* BFD session and it would all still work.

I don't know what an explicit eBGP document would say, other than "if  
you don't find a BFD session to your neighbor, start one up" and "if  
the BFD session goes down, do something useful, like maybe pretending  
that the eBGP session timed out."

If someone could actually point out what they think is missing and  
why that's important (interoperability, correctness, etc.) then maybe  
I'll be able to understand better what the issue is here.  But I just  
don't get it.

If anything substantive is missing, it should be added to the generic  
document.  eBGP is just not particularly special.  For that matter we  
could probably rip out most of the OSPF- and ISIS-specific stuff in  
the 1hop draft, since the techniques should be amply documented in  
the generic draft.  I'm not too excited about revisiting those  
documents, however.

--Dave

On Oct 25, 2005, at 7:27 PM, Suping Zhai wrote:

> Hi,
> Perhaps what we, at least Pekka and me, concern is that we should  
> have a very clear definition of what eBGP should do in order to  
> bootstrap BFD, and what is the specific interactions between BGP  
> and BFD session.
> What I want to further to do is that as well as BGP, how the RIP 
> (v2) should react when run with BFD, regarding to the BFD  
> bootstrapping and interactions with BFD.
> Or else there is no strict rules to run BFD in various situations,  
> and the result will be that the interoperation become a problem.  
> Just a few pages can solve this problem, why do we wait and see:(
>
> Best Regards,
> Suping
>