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

[Dave Katz <[e-mail]>]

On Mar 30, 2007, at 6:29 PM, Naiming Shen wrote:

>>
>> I guess my point is that you need to be very explicit about what  
>> works and what doesn't.  It's certainly the case that, without the  
>> presence of BFD, ISIS will do Bad Things if IP forwarding breaks,  
>> since it will continue to advertise IP connectivity.  But the  
>> whole point of BFD is to sense data protocol connectivity and  
>> provide that (presumably useful) information to other parts of a  
>> system.  If BFD is providing information directly to ISIS, it can  
>> withdraw IP connectivity (or tear down the adjacency if need be)  
>> and keep it that way until connectivity is restored.  If ISIS  
>> relied on this scheme, and IP connectivity failed (but datalink  
>> connectivity remained), the ISIS adjacency would flap, and then  
>> ISIS would proceed to black hole traffic.
>
> Even in the normal BFD interacting with ISIS(for ipv4), I would  
> think it can also do this
> black holing. Since ipv4 bfd session is flapping, and datalink  
> layer is fine, and ISIS
> packets is going through ok, hellos are happy. ISIS will bring up  
> the adjacency, and
> then register with bfd, and bfd later failed again, which will  
> bring down the ISIS session.
> I fail to see the difference between the two schemes.

In the v4 failure case, the BFD session would stay down, and the ISIS  
adjacencies (or announcement of IP reachability) would be held down  
as well, thus no black hole.  The problem in this scheme is that the  
circularity problem requires that you only temporarily assert that  
the interface is down;  you can't hold the whole interface down  
because BFD would never be able to come up.  Thus in this case ISIS  
would not know that IP reachability was still broken, and would black  
hole the traffic.

>
>>
>> I think you need to specifically disallow this mechanism for cases  
>> like this, namely, applications that will continue to run even  
>> with the failure of a data protocol, but whose correct operation  
>> requires that data protocol.  (Note that this sentence describes  
>> both ISIS and static routes.)
>>
>> OSPFv3 is another interesting example if you're running BFD in  
>> this configuration only over IPv4.  If there is a v4 failure,  
>> OSPFv3 will flap unnecessarily.  This gets back to the IPv4 ==  
>> everything fate sharing that is at the heart of the way you've  
>> specified it, and which I think is an unnecessary restriction.  A  
>> number of systems (including the one I'm most familiar with these  
>> days) has an interface hierarchy that includes the data protocol.   
>> Such systems are likely better served by having, say, separate v4  
>> and v6 BFD sessions and flapping the appropriate data protocol up/ 
>> down status in the face of a BFD session failure.  This would  
>> allow the OSPFv3 case to run unmolested when v4 died.  I would  
>> suggest to at least offer this up as a MAY when you discuss the  
>> fate sharing implications of this mechanism, since it should be  
>> essentially no more work to implement if the system is already  
>> built this way.
>
> Sure. There can be an configuration option for bring down the whole  
> thing or bring
> down the data protocol part if the platform supports that.
>
> Even though from architecture wise, the separation of bfds is  
> clean, ipv4 controls the
> ipv4 protocols and ipv6 controls the ipv6 protocols. there are  
> still much to be desired
> from implementation point of angle. On many routers BFD packets  
> going out not really
> through the exact data packets forwarding path or the packets are  
> sent out from the
> same software process, be it v6 or v6. So the argument of data  
> separation is rather
> mood. And I'm yet to see a case BFD session down is actually caused  
> by the layer 3
> lookup engine which is only responsible for ipv4;-) I would rather  
> do the re-route
> altogether though if we know one of the data plane is already in  
> trouble.

But once again, because of the temporary nature of the "downness" of  
the interface, it will not really reroute the second protocol, but  
just cause it to flap (twice.)  But so long as the spec allows  
multiple sessions (since currently it does not) we can leave the  
mootness or lack thereof to the individual implementor.

>
>>
>> But I think the "difference" here is fundamental--as soon as you  
>> have any special case communication between BFD and a part of the  
>> system, you've basically discarded the point of the draft (if I  
>> understand it) which is to be able to leverage BFD without  
>> changing your "clients" to specifically use it.  What you're  
>> specifying here is functionally *exactly* the same as what the  
>> generic spec talks about for static routes and other non-protocol  
>> applications, and only muddies the spec, IMHO.
>
> only the UP->Down portion is different between the two schemes. the  
> rest is the same.
> but the bring down itself is different from the point of dynamic or  
> static.

But the "bring down" is the crux of the proposal.

>
>>
>> Why not just say that this mechanism only provides a way of more  
>> rapidly taking down applications that would otherwise go down  
>> eventually and which will stay down on their own until the path is  
>> healed (namely, control protocols), and leave statics out of it  
>> altogether?
>
> Maybe you have a point. I'll think about that.

Thanks...

--Dave