FWD: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Jeffrey Haas <[e-mail]>]

I requested additional internal review from my colleagues who work on
Juniper's BFD implementation.  Please find his comments attached.

-- Jeff

-------------------------------8<--- cut here --->8--------------------------

Date: Mon, 17 Aug 2020 16:11:05 -0400
From: Raj Chetan Boddireddy <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

> On Aug 5, 2020, at 7:38 AM, Raj Chetan Boddireddy <[e-mail]> wrote:
> 
> Hi Jeff,
>  
> Please find comments below:
>  
> >   o  When BFD is used to keep track of the "liveness" of the nexthop of
> >      static routes.  Although only one side may need the BFD
> >      functionality, currently both sides need to be involved in
> >      specific configuration and coordination and in some cases static
> >      routes are created unnecessarily just for BFD.
> (1) Unsolicited BFD may not be desired since we end-up running BFD detection timers on both peers and ideal mechanism for this case would require running detect timers only on the device tracking nexthop of the static route and trigger the necessary repair when this fails. SBFD seems more apt for this case.
> >   When the passive side receives a BFD Control packet from the active
> >   side with 0 as the "remote-discriminator", and it does not find an
> >   existing session with the same source address as in the packet and
> >   "unsolicited BFD" is allowed on the interface by local policy, it
> >   SHOULD then create a matching BFD session toward the active side
> (2) Linklocal and unnumbers address can be spread across multiple interfaces, existing session must be looked with both source-address and interface id to uniquely identify a session IMO.
>  
>  
> >   procedure for bringing up, maintaining and tearing down the BFD
> >   session.  If the BFD session fails to get established within certain
> >   specified time, or if an established BFD session goes down, the
> >   passive side would stop sending BFD Control packets and delete the
> >   BFD session created until the BFD Control packets is initiated by the
> >   active side again.
> (3) We could  infer that a system participating in a passive role may also seize sending BFD Down packets after the session transitions out of Up state. In which case, the benefit of detecting one-way failures sooner will be lost. If we could send only a select few packets to notify the peer of this transition and we may need to wait for a predetermined duration during teardown. New passive BFD session can be spawned only after this teardown duration has expired.
>  
>  
> >   The "Passive role" may change to the "Active role" when a local
> >   client registers for the same BFD session, and from the "Active role
> >   " to the "Passive role " when there is no longer any locally
> >   registered client for the BFD session.
> (4) When IGP protocol unsubscribes to a BFD session (in the presence of unsolicited passive mode config), shouldn’t we handle this as an AdminDown? Having a passive role may prevent this.
>       If the sessions transitions to a passive role, then we may create a scenario where both end-points for the BFD  session take the passive role.
> Ex:
> -R0 (IGP  + Passive BFD) Active-role                     R1 (IGP + Passive BFD)    Active-role
> -R0 (Passive BFD)              Passive-role                   R1 (IGP + Passive BFD)    Active-role
> At this point ideally we need R0 to send AdminDown to R1 which may not be the case if it transitions to Passive role.
>  
> -R0 (Passive BFD)              Passive-role                   R1 (Passive BFD)               Passive-role
> Furthermore both R0 and R1 may assume passive role and the session may lie in this state until it flaps.
>  
>  
> >   o  Limit the feature to specific interfaces, and to a single-hop BFD
> >      with "TTL=255" [RFC5082].  In addition make sure the source
> >      address of an incoming BFD packet belongs to the subnet of the
> >      interface from which the BFD packet is received.
> (5) Restricting this feature only  to interfaces with matching subnet will restrict this feature for unnumbered interfaces and link-local addresses.
>
> Thanks & Regards,
> Raj Chetan
> 
-------------------------------8<--- cut here --->8--------------------------