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 <rche...@juniper.net> 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 <rche...@juniper.net> 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--------------------------
