bfd-unsolicited, possible RFC 5880 ambiguity for passive mode

[Jeffrey Haas <[e-mail]>]

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