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

[Naiming Shen <[e-mail]>]

Hi Miya,

On Apr 3, 2007, at 8:49 AM, Miya Kohno ((mkohno)) wrote:

> Hi,
>
> On Apr 2, 2007:1:14 PM, at 1:14 PM, Naiming Shen wrote:
>> I agree the intf UP->Down signal is the key of this draft; but as I
> pointed out
>> in the previous email, there is also an important difference in the
> bring-up stage
>> in terms of non-protocol services, that the bfd session state is
> condensed into
>> an intf-based indication, which is very easy for implementation.  
>> Since
> those
>> services looking at the intf state anyway, to augment with tins
> intf-p2p bfd,
>> is just simply a one-line diff to those services.
>
> I think the protocol-agnostic nature is more the essence of the draft,
> rather than the interface UP->Down.
>
> I've been thinking that, assuming the primary goal of BFD is to detect
> the (un)liveness of underlying layer when it cannot generate/propagate
> its fault status, it should not necessarily be tightly coupled with L3
> protocols...
>
> The protocol-agnostic nature would be very much suitable for  
> static, TE
> FRR/local protection and global path restoration/ protection (by
> detecting-node generating PATH error to headend), which don't have a
> direct upperlayer protocol peer. It could also be applicable for the
> OSPFv3 prefixes, when it shares the same topology as OSPFv2. In fact,
> the single topology is pretty much common in v4/v6 dual stack
> deployment, so separately running BFDv6 session could be viewed as an
> unnecessary overhead.
>
> A concern would be that bringing down the interface might be too
> aggressive, depending on various situations.
>
> So how about including a less aggressive way ?  i.e.
>
>   1) BFD session is to be associated with each p2p interface, not L3
> protocol.

As long as we are looking at the p2p or p2p-over-lan interfaces,
then I don't see anything wrong with the 'aggressive' way of shutting  
down
the interface.

>   2) each protocol instance register itself as a BFD client
>   3) BFD clients should be notfiied in case of BFD session timeout

But by shutting down the interface, we don't have to do any of the  
above,
which was the original intention of the draft.

thanks.
- Naiming

>
> 1) is only a bit new by the draft. But 2) and 3) is the same as the
> existing implementation.
>
> Miya
>
>