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
