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

From: "Miya Kohno \(mkohno\)" <[email-masked]>
Date: Tue, 3 Apr 2007 23:49:50 +0800

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 5 Apr 2007 01:23:28 -0700

Hi Miya,

>   1) BFD session is to be associated with each p2p interface, not L3

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.

>   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

---

From: "Miya Kohno \(mkohno\)" <[email-masked]>
Date: Thu, 5 Apr 2007 21:28:13 +0800

Hi Naiming,

I felt shutting down the interface might be too aggressive, because
there is a case that fast-detection/fast-convergence, which could
conflict with the stability or fault tolerance (GR/NSF..),  is not
always preferable. 

But it's true we run BFD only because we want the fast convergence. :) A
concern would be the case that multiple protocol instances share an
interface and one of the instances doesn't want the fast convergence
while others do. That's why I still think it'd be beneficial if each
protocol instance can select to register or not. But then it requires an
additional development for each client protocols, while your proposal
that bring down the interface doesn't. So I agree that there are cases
where your proposal is useful. 

Miya
> -----Original Message-----
> From: Naiming Shen (naiming) 
> Sent: Thursday, April 05, 2007 5:23 PM
> To: Miya Kohno (mkohno)
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt 
> 
> Hi Miya,
> 
> > The protocol-agnostic nature would be very much suitable 
> for static, 
> > TE FRR/local protection and global path restoration/ protection (by 
> 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.
> 
> 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
> 
> >