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

["Miya Kohno \(mkohno\)" <[e-mail]>]

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.
  2) each protocol instance register itself as a BFD client
  3) BFD clients should be notfiied in case of BFD session timeout

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

Miya