Subject: Re: Some comments to the authors of draft-ietf-bfd-unsolicited

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Mar 2022 07:38:34 -0500

Greg,

On Mon, Feb 28, 2022 at 09:34:19AM -0800, Greg Mirsky wrote:
> it is also my impression that the concept described in the draft is
> different from the Passive role as defined in RFC 5880. I think that needs
> to be clearly explained in the draft and, it seems to be helpful to even
> use another term to avoid any possible confusion.

I spent some time reviewing the text of the draft and I don't think I agree
with this statement.

Section 2, Procuedures for Unsolicited BFD, has the following as its first
paragraph:

:   With "unsolicited BFD", one side takes the "Active role" and the
:   other side takes only the "Passive role" as described in [RFC5880].
:   On the passive side, the "unsolicited BFD" SHOULD be explicitly
:   configured on an interface or globally (apply to all interfaces).
:   The BFD parameters can be either per-interface or per-router based.
:   It MAY also choose to use the parameters that the active side uses in
:   its BFD Control packets.  The "My Discriminator", however, MUST be
:   chosen to allow multiple unsolicited BFD sessions.

Passive is covered in RFC 5880 section 6.1:

:   A system may take either an Active role or a Passive role in session
:   initialization.  A system taking the Active role MUST send BFD
:   Control packets for a particular session, regardless of whether it
:   has received any BFD packets for that session.  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.  At least one
:   system MUST take the Active role (possibly both).  The role that a
:   system takes is specific to the application of BFD, and is outside
:   the scope of this specification.

In the unsolicited draft:
- The passive side is not sending packets.
- It is waiting for an incoming session.

I don't see a mismatch of expected behaviors.

-- Jeff

---

From: Aijun Wang <[email-masked]>
Date: Tue, 1 Mar 2022 20:50:51 +0800

Is it better to use “reflection mode”?

Aijun Wang
China Telecom

> 在 2022年3月1日，20:38，Jeffrey Haas <[email-masked]> 写道：
> 
> Greg,
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Mar 2022 08:41:50 -0800

Hi Jeff,
thank you for the clarification. Top-posting:

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. 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? 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.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Mar 2022 11:07:36 -0500

Greg,

On Tue, Mar 01, 2022 at 08:41:50AM -0800, Greg Mirsky wrote:
> 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
> session" in RFC 5880) but any yet unlearned BFD session? 

A "wildcard" session, yes.  

> But that, in my

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