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

[Naiming Shen <[e-mail]>]

On Mar 30, 2007, at 7:20 PM, Dave Katz wrote:

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

Ok, I see your point. So in this case as you mentioned, isis dealing  
could be categorized or
implemented the same as static routing if this is a concern.

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

Ok.

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

Something else reminds that, there is a difference between the normal  
bring up stage
and this scheme in terms of the 'non-dynamic' applications, that was  
why I wrote this
'special flag' in the first place, is that the flag/callback/whatever  
with this scheme can be
an interface based trick, which is very easy to implement (or some  
multiple
interface/dataplane based) ; while the normal bfd which is nexthop  
based, need to have
proper registration/etc mechanism, it's rather hard to handle. It may  
worth to mention
this in the draft.

thanks.
- Naiming

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