Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt

[Naiming Shen <[e-mail]>]

Hi Dave,

Good comments, see some replies inline.

On Mar 30, 2007, at 2:44 PM, Dave Katz wrote:

> Hi Naiming, thanks for submitting this.
>
> I've pointed out privately to Naiming that I think this is a rather  
> ugly architectural hack, albeit a pragmatic one.  The Right Way™ to  
> do this would be to run BFD directly over the datalink layer and  
> take down all data protocols (but not the datalink) in sympathy  
> with the BFD session state.  However, there are (at least) two  
> problems with this.  Firstly, it means specifying how to run BFD  
> over a plethora of datalink layers.  Secondly, the IETF cannot  
> standardize how to run BFD over datalink layers it does not control  
> (so we could standardize something directly over PPP, for example,  
> but not IEEE or cisco HDLC.)

Yes, ugly architecture to avoid endless of clean work;-) only trying  
to be an engineer.

>
> The architectural ugliness, aside from being a layer violation,  
> rears its head in a couple of ways related to fate-sharing.   
> Firstly, it means that everything shares fate with the IP over  
> which BFD is being run, so if, say, IPv4 forwarding fails, non-v4  
> applications will see the failure.  This isn't *too* terrible;  it  
> means that there may be false negatives, causing the application to  
> temporarily flap.
>
> But secondly, there is a self-referential problem.  What you'd  
> *really* like to do on a BFD failure is to take down the failing  
> protocol and keep it down until the BFD session resumes.  But you  
> can't do this if BFD is running on top of that failing protocol  
> (which it will be) which thus requires the "special flag" hack and  
> only temporarily taking down the protocol.  The fate-sharing  
> implications of this are more serious, because it is possible to  
> get false positives in some cases when the data protocol has  
> failed.  Imagine, for example, running ISIS with this method.  If  
> IPv4 fails, the BFD session goes down, the interface flaps for five  
> seconds, and then is reenabled.  At that point ISIS will happily  
> come back up and report IP reachability even though it doesn't  
> exist.  You can bet that folks who have not yet implemented BFD  
> will be tempted to do this.

I don't quick get this point. Let's take an easy example: if the bfd  
always uses the
connected nexthop of the peer address as it's bfd peer address, how  
ISIS is doing
should be independent of the intf-p2p BFD session and vise versa.

If you are talking about sharing fate between ipv4 bfd and ISIS is a  
problem, then I agree,
this scheme is only meant for sharing fate among protocols, it should  
not be used
if this assumption is not true. But using ISIS to carry IP  
information itself is violating this
principle;-) don't know who to blame, although it's not a BFD issue.

if you are talking about bfd connection depending on the ISIS routes,  
then the original
BFD spec also has this problem, this is not a new feature of this draft.

>
> My other objection to the "special flag" is that it is arguably  
> overspecified.  As far as I can tell, this is isomorphic with  
> simply having static routes interact with BFD "directly" and is  
> already covered by the generic spec (which carefully says only what  
> the effect of the interaction should be, not the implementation of  
> it.)  It is an explicit signaling mechanism from BFD, albeit a  
> primitive one.

Ok, I agree. This 'special flag' is not a requirement of this scheme,  
it's a purely implementation
issue, be it a 'flag', a 'registration/callback' function, or  
something else. I'll change that part.

>
> In light of this, my preference would be for all of the verbiage  
> about static routes and dynamic protocols and special fiags to be  
> removed.  In place of this, add text that is very specific about  
> the fate-sharing implications of this mechanism as outlined above,  
> and point out that any application of BFD that does not  
> automatically share fate with the data protocol over which BFD is  
> running (such as ISIS or static routes) MUST have some form of  
> explicit interaction with BFD in order to avoid false positives,  
> and leave it at that.  The "special bit" hack is orthogonal to this  
> mechanism;  it could just as well have been specified in the  
> generic spec (and would have been just as inappropriate there.)

I think the dynamic and static difference still needs to be  
mentioned, although should not
be directly linked with a 'special flag' for the static routing.

>
> It would be nice to point out that the only function of flapping  
> the interface is to provide an Up->Down edge for protocols to see,  
> and that the only requirement for duration is for it to be long  
> enough so that it isn't absorbed by any hysteresis mechanism that  
> might be sitting on top of it, and short enough so that the  
> protocol isn't held down for "too long" (another ugly interaction.)
>

Yes, I should emphasize this Up->Down edge transition and the timing  
thing as suggested
in this draft.

thanks again.
- Naiming

> --Dave
>
> On Mar 30, 2007, at 10:21 AM, Naiming Shen wrote:
>
>>
>> hi bfd-wg,
>>
>> comments are welcome.
>>
>> thanks.
>> - Naiming