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

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

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: [e-mail]
> Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt 
> 
> 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
> >
> >
> 
>