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

From: Greg Mirsky <[email-masked]>
Date: Sun, 20 Feb 2022 14:09:03 -0800

Dear Authors,
I've read the current version of the draft and have several questions.
Greatly appreciate your consideration and feedback.

   - The document uses the normative language and is on the Standard track.
   At the same time, the behavior of the passive BFD system is entirely local
   and has no impact on the active BFD system. It appears like the use of
   normative language describing the implementation of the passive BFD system
   is unnecessary. It appears that the Informational track is more appropriate
   for this specification.
   - It appears that the YANG data model allows the BFD unsolicited only
   for the single-hop BFD. What, in your opinion, prevents allowing it for
   multi-hop BFD?
   - In the following text:

   The "Passive role" may change to the "Active role" when a local

   client registers for the same BFD session, and from the "Active role

   " to the "Passive role " when there is no longer any locally

   registered client for the BFD session.

it is not clear to me as to which BFD session is the reference "for the
same BFD session". Is that for the session that is already in the Up state?
Or something else?

   - Two recommendations in the Security Considerations section:

   o  Apply "access control" to allow BFD packets only from certain
      subnets or hosts.
...
   o  Use BFD authentication.

leave some serious doubts that the proposed model does bring any
operational simplification compared to explicitly configuring BFD on both
systems (especially to use authentication).

Regards,
Greg

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 27 Feb 2022 16:24:35 +0000 (UTC)

Hi Greg,
Thanks for the review and comments. Please see inline.
    On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky <[email-masked]> wrote:  
 
 Dear Authors,I've read the current version of the draft and have several questions. Greatly appreciate your consideration and feedback.   
   - The document uses the normative language and is on the Standard track. At the same time, the behavior of the passive BFD system is entirely local and has no impact on the active BFD system. It appears like the use of normative language describing the implementation of the passive BFD system is unnecessary. It appears that the Informational track is more appropriate for this specification.
<RR> This was debated extensively ~15 months ago. I'll defer to Jeff H and John S, but the last email I have on this is the following: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
   
   - It appears that the YANG data model allows the BFD unsolicited only for the single-hop BFD. What, in your opinion, prevents allowing it for multi-hop BFD?
<RR> As per reply to Gyan, we will extend the document + YANG to support multi-hop.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/567Ey36geGC427ulnAqcWFag3xc/

   - In the following text:

it is not clear to me as to which BFD session is the reference "for the same BFD session". Is that for the session that is already in the Up state? Or something else?
<RR> It is for the already created session. So a session is created in "passive" state via BFD unsolicited procedure (no local client or config for it). After that a local client wants the same session (e.g. because BFD was enabled under a client), the BFD session becomes "active". We'll see if we can make this clearer.

   o  Apply "access control" to allow BFD packets only from certain      subnets or hosts....   o  Use BFD authentication.

leave some serious doubts that the proposed model does bring any operational simplification compared to explicitly configuring BFD on both systems (especially to use authentication).

<RR> Good point. I think it depends. e.g. if BFD authentication is already in use, this is not an issue. 
Regards,Reshad.

Regards,Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 27 Feb 2022 17:53:09 -0500

> <RR> This was debated extensively ~15 months ago. I'll defer to Jeff H and John S, but the last email I have on this is the following: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_M…

We'll stick with Proposed Standard for the time being based on conversation
to date.  I expect that we'll get similar discussion yet again once this
hits IESG review.  End of the day, we'll take whatever gets the document
published. :-)

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 27 Feb 2022 16:54:47 -0800

Hi Jeff,
of course, the WG can send the document IESG on its current track. What is
not clear to me is what is being standardized by the document. It appears
that everything described is a local behavior that does not affect any
other BFD system. Is my understanding correct? Or I'm missing something?
I also have some follow-up notes to share with the authors.

Regards,
Greg

On Sun, Feb 27, 2022 at 2:53 PM Jeffrey Haas <[email-masked]> wrote:

> > >    - The document uses the normative language and is on the Standard
> track. At the same time, the behavior of the passive BFD system is entirely
> local and has no impact on the active BFD system. It appears like the use
> of normative language describing the implementation of the passive BFD
> system is unnecessary. It appears that the Informational track is more
> appropriate for this specification.
> > <RR> This was debated extensively ~15 months ago. I'll defer to Jeff H
> and John S, but the last email I have on this is the following:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Feb 2022 06:39:44 -0500

Greg,

> On Feb 27, 2022, at 7:54 PM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Jeff,
> of course, the WG can send the document IESG on its current track. What is not clear to me is what is being standardized by the document. It appears that everything described is a local behavior that does not affect any other BFD system. Is my understanding correct? Or I'm missing something?

See the cited message from the OPS AD.

I suggest not spending energy fighting this point in the Working Group.  Feel free to direct your questions directly to Rob.

-- Jeff

> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/# <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#>

---

From: Naiming Shen <[email-masked]>
Date: Sun, 27 Feb 2022 16:09:48 -0800

Also regarding the simplification, normally this is operated in some ’trusted’ environment,
e.g. in some trusted IXP subnet where the route server is at. Even the router does apply
the ‘access control’ on the subnet, it is much simpler than pre-configuring hundreds of BFD
peers on the subnet,  just in case some of those peers will later send us data traffic
and those BFD sessions will be used.

When MH is added in this draft, those recommendations will be more relevant.
Tradeoffs need to be considered in operations also, maybe it is better  in some cases
to use regular BFD vs unsolicited BFD in some environment due to security concerns.

thanks.
- Naiming
> Two recommendations in the Security Considerations section:

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 07:20:46 -0800

Thank you, Jeff. Let ADs discuss it when the document comes to the IESG.

Regards,
Greg

On Mon, Feb 28, 2022 at 3:39 AM Jeffrey Haas <[email-masked]> wrote:

> I suggest not spending energy fighting this point in the Working Group.
> Feel free to direct your questions directly to Rob.
>
> -- Jeff
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 07:34:18 -0800

Hi Reshad,
thank you for clarifying things for me, much appreciated. I have several
follow-up notes logged in-line below under the GIM>> tag.

Regards,
Greg

On Sun, Feb 27, 2022 at 8:24 AM Reshad Rahman <[email-masked]> wrote:

> <RR> This was debated extensively ~15 months ago. I'll defer to Jeff H and
> John S, but the last email I have on this is the following:
GIM>> Thank you, will read and follow up on that thread.

> <RR> It is for the already created session. So a session is created in
> "passive" state via BFD unsolicited procedure (no local client or config
> for it). After that a local client wants the same session (e.g. because BFD
> was enabled under a client), the BFD session becomes "active". We'll see if
> we can make this clearer.
>
> GIM>> Thinking of what might had confused me, I feel that it may be the
use of "passive role" that was already described in Section 6.1 RFC 5880
<http://The state of New Hampshire removes ALL Russian liquor brands from
the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do
you see as the distinction between the Passive role behavior as described
in RFC 5880 and the passive role described in the draft?

> GIM>> And a thought on the Security Considerations.  All remedial steps
related to the security of BFD protocol are recommendations. What if an
implementation does not support any of them? Would it be reasonable to have
some as requirements?

> Reshad.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Feb 2022 11:35:48 -0500

Greg,

Not speaking for the authors here, but:

> On Feb 28, 2022, at 10:34 AM, Greg Mirsky <[email-masked]> wrote:
> 
> GIM>> Thinking of what might had confused me, I feel that it may be the use of "passive role" that was already described in Section 6.1 RFC 5880 <http://The state of New Hampshire removes ALL Russian liquor brands from the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do you see as the distinction between the Passive role behavior as described in RFC 5880 and the passive role described in the draft?

The primary distinction of this proposal is whether or not a session is PROVISIONED at the passive side or not.

It's possible to be provisioned, and passive.  

This draft makes the passive side at best loosely provisioned.  "I am willing to accept incoming BFD sessions without having one configured".

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 09:34:19 -0800

Hi Jeff,
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.

Regards,
Greg

On Mon, Feb 28, 2022 at 8:35 AM Jeffrey Haas <[email-masked]> wrote:

> use of "passive role" that was already described in Section 6.1 RFC 5880.
> What do you see as the distinction between the Passive role behavior as
> described in RFC 5880 and the passive role described in the draft?
>
>
> This draft makes the passive side at best loosely provisioned.  "I am
> willing to accept incoming BFD sessions without having one configured".
>
> -- Jeff
>
>