RE: bfd-unsolicited, possible RFC 5880 ambiguity for passive mode

["Les Ginsberg (ginsberg)" <[e-mail]>]

Jeff -

I don't know for certain what our implementations do, but I will hazard a guess that for any platform where BFD is supported in hardware that the hardware is unaware of passive mode. It will simply continue to send DOWN packets until the control plane destroys the BFD session. Which likely means multiple DOWN packets will be sent (depending on the TxInterval in use) even when in passive mode - which is actually the behavior that is desired.

You could file an errata and specify that even in Passive mode some minimum # of DOWN packets should be sent (or for some minimum duration), but I suspect in practice this wouldn't result in an implementation change because (as I indicated above) I would be surprised if hardware implementations are aware of passive mode.

For me, the intent of the statement:

" A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
   zero and the system is taking the Passive role."

is as a means of implementing passive mode for the session bringup (as you mention below). And I would argue that transmitting multiple DOWN packets following a DOWN transition doesn't violate the "spirit" of RFC 5880.

I won't argue the pedantic points.

   Les


> -----Original Message-----
> From: Rtg-bfd <[e-mail]> On Behalf Of Jeffrey Haas
> Sent: Wednesday, March 2, 2022 11:05 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: bfd-unsolicited, possible RFC 5880 ambiguity for passive mode
> 
> Working Group,
> 
> Greg Mirsky brought to our attention that we may have an undefined edge
> case
> covering Passive mode in RFC 5880.  This discussion is partially a result of
> prior analysis about Demand mode, but Demand mode is not the relevant
> detail
> here.
> 
> Presuming Greg's observation is correct, this is at least deserving an Errata.
> 
> Copying selectively from the thread with Greg:
> 
> RFC 5880, §6.1:
> :   A system taking the
> :   Passive role MUST NOT begin sending BFD packets for a particular
> :   session until it has received a BFD packet for that session, and thus
> :   has learned the remote system's discriminator value
> 
> Passive governs the initial connection.  A system desiring to be passive
> can't fully go back to being passive until signaling to the remote system
> sufficiently to take the session to the Down state.
> 
> RFC 5880 §6.8.7:
> :   A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
> :   zero and the system is taking the Passive role.
> 
> We have a session that's transitioning, the RemoteDiscr was known, but
> procedure says to clear it:
> 
> RFC 5880 §6.8.1:
> :   bfd.RemoteDiscr
> :
> :      The remote discriminator for this BFD session.  This is the
> :      discriminator chosen by the remote system, and is totally opaque
> :      to the local system.  This MUST be initialized to zero.  If a
> :      period of a Detection Time passes without the receipt of a valid,
> :      authenticated BFD packet from the remote system, this variable
> :      MUST be set to zero.
> 
> So, without a deep comb-through of the RFC to find something that causes
> us
> to send Down "long enough", passive mode could indeed imply with
> pedantic
> reading of the RFC that you'd not do work that lets the remote take the
> state down.  (See the Daves' caveat about excess pedantry.)
> 
> The obvious thing to do here is that we need to send packets in the Down
> state for some period.  The reasonable question is, how long?  And even if
> we provide a length of time, the obvious point is "is that long enough?"
> 
> Since Demand mode isn't a core scenario for the bfd-unsolicited draft, we
> don't have the unfortunate circumstance that reporting the BFD state is
> difficult.  A session that was Up minimally in the presence of such pedantic
> behavior would simply go Down at the Active side once the Detection
> Interval
> expired.
> 
> Since bfd-unsolicited has implementations, what do YOUR implementations
> do?
> 
> One option would be to transmit Down for at least DetectMult number of
> packets.
> 
> -- Jeff