Greg,
On Tue, Mar 01, 2022 at 08:41:50AM -0800, Greg Mirsky wrote:
> In the unsolicited draft:
> - The passive side is not sending packets.
> - It is waiting for an incoming session.
>
> In my understanding, that is already defined in Section 6.1 RFC 5880:
> 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.
> If my understanding of RFC 5880 and the draft is correct, it appears that
> the draft does not define any new local behavior but re-tells what already
> has been defined in Section 6.1.
The authors largely made these points at various times over presentation and
working group discussion. It was the motivation originally to start with
INFORMATIONAL status.
> Or the new behavior is that the passive
> role might be not only for the specified BFD session ("particular BFD
> session" in RFC 5880) but any yet unlearned BFD session?
A "wildcard" session, yes.
> But that, in my
> opinion, would require Security Considerations stepping up from
> recommendations to requirements, especially when the draft includes the
> multi-hop BFD scenario.
This feature is well deployed already. Yes, from an IETF process
perspective, the main considerations here are security considerations.
I believe that as the authors update the text to explicitly call out that
multihop is a valid scenario that additional scrutiny of the security
considerations will be necessary.
-- Jeff
