Skip to main content

Unaffiliated Bidirectional Forwarding Detection (BFD) Echo
draft-ietf-bfd-unaffiliated-echo-14

Yes

Éric Vyncke

No Objection

Erik Kline
Francesca Palombini
Orie Steele
Paul Wouters

Note: This ballot was opened for revision 12 and is now closed.

Éric Vyncke
Yes
Deb Cooley
No Objection
Comment (2024-10-16 for -12) Not sent
Thanks to Stephen Farrell for both of his secdir reviews of this draft.
Erik Kline
No Objection
Francesca Palombini
No Objection
Gunter Van de Velde
No Objection
Comment (2024-10-14 for -12) Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-unaffiliated-echo-12.txt

# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-12.txt

# idnits spits a warning about pre-rfc5378 work

# i found the document well written and a nice read into this technology. Thank you.

# In what follows you will find some detailed observations and some editorial suggestions trying to improve readability while keeping original message. 

#DETAILED COMMENTS
#=================

18	   Bidirectional Forwarding Detection (BFD) is a fault detection
19	   protocol that can quickly determine a communication failure between
20	   two forwarding engines.  This document defines a use of the BFD Echo
21	   where the local system supports BFD but the adjacent system does not
22	   support BFD.  BFD Control packet and its processing procedures can be
23	   executed over the BFD Echo port where the adjacent system only loops
24	   packets back to the local system.

26	   This document updates RFC 5880 by defining a new method of BFD Echo-
27	   Only without requiring an implementation to support the full BFD
28	   protocol.

GV> proposed alternative abstract rewrite for readability and high level understanding of the technology proposed:

"
This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency.

This document updates RFC 5880 by defining a new Unaffiliated BFD Echo mechanism.
"

77	1.  Introduction
78
79	   To minimize the impact of device/link faults on services and improve
80	   network availability, in the single-hop cases a network device needs
81	   to be able to quickly detect faults in communication with adjacent
82	   devices.  Measures can then be taken to promptly rectify the faults
83	   to ensure service continuity.
84
85	   BFD [RFC5880] is a low-overhead, short-duration method to detect
86	   faults on the communication path between adjacent forwarding engines.
87	   The faults can be on interfaces, data links, and even the forwarding
88	   engines.  It is a single, unified mechanism to monitor any media and
89	   protocol layers in real time.
90
91	   BFD defines the Asynchronous mode and the Demand mode to satisfy
92	   various deployment scenarios.  It also supports an Echo function that
93	   reduces the level of BFD support required in device implementations,
94	   as described in Section 3.2 of [RFC5880].  When the Echo function is
95	   activated, the local system sends BFD Echo packets and the remote
96	   system loops back the received Echo packets through the forwarding
97	   path.  If several consecutive BFD Echo packets are not received by
98	   the local system, then the BFD session is declared to be Down.
99
100	   When using BFD Echo function, there are two typical scenarios as
101	   below:
102
103	   *  Full BFD protocol capability with adjunct Echo function.  This
104	      scenario requires both the local device and the adjacent device to
105	      support the full BFD protocol.
106
107	   *  BFD Echo-Only method without full BFD protocol capability.  This
108	      scenario requires only the local device to support sending and
109	      demultiplexing BFD Control packets.  In this scenario, the BFD
110	      Control packets are sent over the BFD Echo port, but that the
111	      processing procedures for Asynchronous mode are used with the
112	      modifications described in this document.  Note that this method
113	      monitors the connectivity to a system over a specific interface
114	      and does not verify the availability of a specific IP address at
115	      that system.
116
117	   The former scenario is referred to as "Affiliated BFD Echo" in this
118	   document, which remains unchanged from [RFC5880].  The latter
119	   scenario is referred to as "Unaffiliated BFD Echo", which is
120	   specified in this document.
121
122	   Section 5 of [RFC5880] indicates that the payload of an affiliated
123	   BFD Echo packet is a local matter and hence its contents are outside
124	   the scope of that specification.  This document, on the other hand,
125	   specifies the contents of the Unaffiliated BFD Echo packet and what
126	   to do with them.  This would appear to contravene Section 5 of
127	   [RFC5880].  However, the core behavior in that RFC simply states that
128	   the contents of the BFD Echo packets are a local matter, and this
129	   document is simply defining "the local matter".  Regarding the
130	   selection of IP address, the rules stated in Section 4 of [RFC5881]
131	   are applicable to the encapsulation of an Unaffiliated BFD Echo
132	   packet.
133
134	   Section 6.2.2 of [BBF-TR-146] describes one use case of the
135	   Unaffiliated BFD Echo.
136
137	   This document updates [RFC5880] by defining a new method of BFD Echo-
138	   Only without requiring an implementation to support the full BFD
139	   protocol.  It specifies the use of the Unaffiliated BFD Echo over
140	   IPv4 and IPv6 for a single IP hop.  A full description of the updates
141	   to [RFC5880] is provided in Section 3.

GV> proposed rewrite for improved readability:

"
To minimize the impact of device and link faults on services and to improve network availability in single-hop scenarios, a network device needs the capability to quickly detect communication faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure service continuity.

BFD [RFC5880] provides a low-overhead, short-duration method for detecting faults on the communication path between adjacent forwarding engines, which may include interfaces, data links, and the forwarding engines themselves. BFD offers a unified mechanism to monitor any media and protocol layers in real time.

BFD defines two primary modes—Asynchronous mode and Demand mode—to accommodate various deployment scenarios. Additionally, it supports an Echo function that reduces the level of BFD support required in device implementations, as described in Section 3.2 of [RFC5880]. When the Echo function is activated, the local system sends BFD Echo packets, and the remote system loops back the received Echo packets through the forwarding path. If several consecutive BFD Echo packets are not received by the local system, the BFD session is declared Down.

There are two typical scenarios when using the BFD Echo function:

* Full BFD protocol capability with adjunct Echo function (Affiliated BFD Echo): This scenario requires both the local device and the adjacent device to support the full BFD protocol. This operation remains unchanged from [RFC5880].

* BFD Echo-Only method without full BFD protocol capability (Unaffiliated BFD Echo): This scenario requires only the local device to support sending and demultiplexing BFD Control packets. In this case, BFD Control packets are sent over the BFD Echo port, and the processing procedures for Asynchronous mode are used with the modifications specified in this document. Note that this method monitors the connectivity to a system over a specific interface and does not verify the availability of a specific IP address on that system.

This document specifies the Unaffiliated BFD Echo scenario.

Section 5 of [RFC5880] indicates that the payload of an Affiliated BFD Echo packet is a local matter and, therefore, its contents are outside the scope of that specification. This document, however, specifies the contents of the Unaffiliated BFD Echo packet and the procedures for handling them. While this may appear to contravene Section 5 of [RFC5880], the core behavior in that RFC states that the contents of BFD Echo packets are a local matter; this document is defining that "local matter." Regarding the selection of IP addresses, the rules stated in Section 4 of [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo packet.

Section 6.2.2 of [BBF-TR-146] describes a use case for the Unaffiliated BFD Echo.

This document updates [RFC5880] by defining a new method of BFD Echo-only operation that does not require an implementation to support the full BFD protocol. It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. A full description of the updates to [RFC5880] is provided in Section 3.
"

186	   engage in a BFD session.  The local end as an initiator may regard
187	   the Unaffiliated BFD Echo session as a BFD session within its
188	   implementation.

GV> To me the wording "within its implementation" is not so clear what it exactly means. I suspect that the intent is to say that this session is perceived to be internal contained within its own implementation without any external control plane devices or systems? Can the text be made more descriptive?

190	   For unaffiliated echo, an Unaffiliated BFD Echo session is created on
191	   device A, and the Unaffiliated BFD Echo session MUST follow the BFD
192	   state machine defined in Section 6.2 of [RFC5880], except that the

GV> The wording "For unaffiliated echo" reads odd. Would it be correct to say "For the unaffiliated echo procedure" to be more accurate? or was this suggesting something else?


190	   For unaffiliated echo, an Unaffiliated BFD Echo session is created on
191	   device A, and the Unaffiliated BFD Echo session MUST follow the BFD
192	   state machine defined in Section 6.2 of [RFC5880], except that the
193	   received state is not extracted from BFD Control packets originated
194	   by the remote system, but from packets originated by the local system
195	   and looped back from the remote system.  Therefore, Unaffiliated BFD
196	   Echo does not use the AdminDown state.  BFD Control packets are
197	   transmitted and received as Unaffiliated BFD Echo packets using
198	   destination UDP port 3785, as defined in [RFC5881].  The procedures
199	   for BFD Async sessions are executed for the looped BFD Control
200	   packets as per [RFC5880], including validation and authentication.

GV> From a readability perspective, what about the following editorial suggestion:

"
For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session MUST adhere to the BFD state machine specified in Section 6.2 of [RFC5880], with the exception that the received state is not derived from BFD Control packets originating from the remote system, but rather from packets that are generated by the local system and looped back from the remote system. Consequently, the AdminDown state is not utilized in Unaffiliated BFD Echo.

BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port 3785, as defined in [RFC5881]. The standard procedures for BFD Asynchronous sessions are applied to the looped BFD Control packets, including packet validation and authentication, in accordance with [RFC5880].
"

216	   Within the Unaffiliated BFD Echo packet, the "Desired Min TX
217	   Interval" and "Required Min RX Interval" defined in [RFC5880] MUST be
218	   populated with a certain value, which can avoid unset value being a
219	   potential vector for disclosure of uninitialized memory.  A suggested
220	   value is 1 second (1,000,000 microseconds).  These values, however,
221	   MUST be ignored on receipt.  Furthermore, these values MUST NOT be
222	   used to calculate the Detection Time.

GV> I got thrown off guard when reading the word 'certain' I am not sure it the correct construct to use here. There is no certainty. I suspect that the intent is to say that a specific value must be used. I am not sure why or how the uninitialized memory comes into the picture? Maybe a word to explain this could be added for non-bfd experts? 

To make the existing paragraph better readable what about the following rewrite:

"
In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX Interval" and "Required Min RX Interval" fields, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential exposure of uninitialized memory. It is RECOMMENDED that these fields be set to a value of 1 second (1,000,000 microseconds). However, upon receipt, these values MUST be ignored and MUST NOT be used in the calculation of the Detection Time.
"

224	   The "Required Min Echo RX Interval" defined in [RFC5880] MUST be
225	   populated with a certain value, which can avoid unset value being a
226	   potential vector for disclosure of uninitialized memory.  A suggested
227	   value is 0.  This value MUST be ignored on receipt.  The transmission
228	   interval for Unaffiliated BFD Echo packets in the Up state MUST be
229	   provisioned on device A.  The Unaffiliated BFD Echo feature depends
230	   on device B performing IP forwarding (actually IP redirect)
231	   functionality.  While such functionality may normally be expected to
232	   be supported on a router, it may not be enabled on a host by default.
233	   The method for provisioning device B to loop back Unaffiliated BFD
234	   Echo packets is outside the scope of this document.

GV> What about the following rewrite:

"
The "Required Min Echo RX Interval" field, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential disclosure of uninitialized memory. It is RECOMMENDED that this value be set to 0. However, this value MUST be ignored upon receipt. The transmission interval for Unaffiliated BFD Echo packets when in the Up state MUST be provisioned on device A.

The functionality of the Unaffiliated BFD Echo feature is dependent on device B performing IP forwarding (specifically, IP redirect functionality). While this capability is typically expected to be supported on routers, it may not be enabled by default on hosts. The method for provisioning device B to loop back Unaffiliated BFD Echo packets is outside the scope of this document.
"

236	   Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo
237	   session begins with the periodic, slow transmission of Unaffiliated
238	   BFD Echo packets.  The slow transmission rate SHOULD be no less than
239	   one second per packet, until the session is Up.  After the session is
240	   Up, the provisioned transmission interval is used.  When the

GV> In the above is described that with slow transmission rate to be no less as one second per packet. Next the text moves to the provisioned transmission interval. I was wondering if it would be useful to inform about the range of the valid transmission intervals with unaffiliated sessions for completeness of the paragraph?

253	   *  "My Discriminator" MUST be set to the provisioned local
254	      discriminator.
255
256	   *  "Your Discriminator" MUST be set to 0 initially, and then MUST be
257	      set to the same as "My Discriminator" looped back.
258
259	   *  "Desired Min TX Interval" MUST be set to a certain value.  A
260	      suggested value is 1 second (1,000,000 microseconds).
261
262	   *  "Required Min RX Interval" MUST be set to a certain value.  A
263	      suggested value is 1 second (1,000,000 microseconds).
364
265	   *  "Required Min Echo RX Interval" MUST be set to a certain value.  A
266	      suggested value is 0.
267
268	   *  "Detect Mult" MUST be set to the provisioned maximum allowable
269	      number of consecutively lost Unaffiliated BFD Echo packets.

GV> Proposed readability rewrite:

"
* My Discriminator: MUST be set to the provisioned local discriminator.

* Your Discriminator: MUST initially be set to 0, and then MUST be set to the value of "My Discriminator" looped back from the remote system.

* Desired Min TX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds).

* Required Min RX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds).

* Required Min Echo RX Interval: MUST be set to a specific value, with a suggested value of 0.

* Detect Mult: MUST be set to the provisioned maximum allowable number of consecutively lost Unaffiliated BFD Echo packets.
"

273	   The Unaffiliated BFD Echo described in this document reuses the BFD
274	   Echo function as described in [RFC5880] and [RFC5881], but does not
275	   require BFD Asynchronous or Demand mode.  When using the Unaffiliated

GV> Is the following more accurate?

s/require BFD Asynchronous or Demand mode/require BFD Asynchronous or Demand mode on the remote system/

275	   require BFD Asynchronous or Demand mode.  When using the Unaffiliated
276	   BFD Echo, only the local system has the BFD protocol enabled; the
277	   remote system just loops back the received BFD Echo packets as
278	   regular data packets.

GV> suggested editorial rewrite:

"
In the Unaffiliated BFD Echo operation, only the local system has the BFD protocol enabled, while the remote system simply loops back the received BFD Echo packets as ordinary data packets, without engaging in the BFD protocol.
"
John Scudder
No Objection
Comment (2024-10-16 for -12) Sent
Thanks for this document! It's a little unusual in that it talks about how a system can talk to... itself! Which stretches the usual definition of "protocol". Still, it's useful and I'm glad you've done the work.

## COMMENT

### General, theory of operation

I didn't see anywhere the document explains in simple terms that the way the extension functions is for the active side to send a packet with one of its own IP addresses as the destination address, upon receipt of which the other side sends it back to the active side. It seems like the lack of this simple explanation led to confusion for at least one reviewer. I suggest adding something like that to avoid future confusion. The Abstract and Introduction seem like the right places.

### General, choice of DA

Related, I wonder if there is some need for the document to talk about how the local system should be careful in its choice of destination address. Specifically, I would imagine that if system S is sending a packet out interface F, the best DA to choose would be the local address of F, and not one of S's other addresses (e.g. a loopback address, a different interface address). That's because the far-end system can be expected to know the address of F, but is less sure of knowing S's other addresses. 

### Section 2, couldn't understand

   Once an Unaffiliated BFD Echo session is created on device A, it
   starts sending Unaffiliated BFD Echo packets.  Unaffiliated BFD Echo
   packets with zeroed "Your Discriminator" field are demultiplexed to
   the proper session based on the source IP address or UDP source port,
   once the remote system loops back the local discriminator, all
   further received packets are demultiplexed based on the "Your
   Discriminator" field only, which is conform to the procedure
   specified in Section 6.3 of [RFC5880].  
   
I find it impossible to understand what the preceding sentence is trying to tell me. If I could understand it I'd suggest a rewrite, but I can't even guess. :-(

(Also, "which is conform to" should be something like "in conformance to".)

### Section 2, IP redirect

   provisioned on device A.  The Unaffiliated BFD Echo feature depends
   on device B performing IP forwarding (actually IP redirect)
   functionality.  While such functionality may normally be expected to

As far as I know "IP redirect" isn't a defined thing, although there's a confusing overlap with ICMP redirect. I suggest deleting the parenthetical.

### Section 2, confusion about the definition of "rate"

   Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo
   session begins with the periodic, slow transmission of Unaffiliated
   BFD Echo packets.  The slow transmission rate SHOULD be no less than
   one second per packet, until the session is Up.  After the session is
   Up, the provisioned transmission interval is used.  When the
   Unaffiliated BFD Echo session goes Down, the slow transmission rate
   is resumed.  The "Detect Mult" defined in [RFC5880] MUST be set to a

There seems to be some confusion between "interval" and "rate" here. A "rate" is conventionally defined as quantity per unit time, i.e. it's a synonym for frequency. So, "rate SHOULD be no less than one second per packet" doesn't make sense, that's a period, not a frequency. The easiest fix would be "rate SHOULD be no greater than one packet per second".

### Section 5, specified

   As specified in Section 5 of [RFC5880], BFD Echo packets may be
   spoofed.  Specifically for Unaffiliated BFD Echo, a DoS attacker may

"Specified" is an unfortunate verb in this context, perhaps "explained"? 

## NITS

### Section 3

      NEW TEXT
      When the Echo function is active with Asynchronous mode, a system
      SHOULD set bfd.RequiredMinRxInterval to a value of not less than
      one second (1,000,000 microseconds).  This is intended to keep
      received BFD Control traffic at a negligible level, since the
      actual detection function is being performed using BFD Echo
      packets.  While a system operating in Demand mode would not
      receive BFD Control traffic.

The last sentence ("While...") is a sentence fragment. Probably you could fix it by deleting "while", so "A system operating in..."

### Section 4

   As specified in Section 2 of this document, some configurations are
   needed to make the Unaffiliated BFD Echo work, although the
   configurations won't go beyond the scope of [RFC5880].  At a BFD-

The RFC Editor would fix this, but should be something like, "some configuration is needed"... "although the configuration won't go".
Mahesh Jethanandani
No Objection
Comment (2024-10-15 for -12) Sent
Section 1, paragraph 2
>    BFD [RFC5880] is a low-overhead, short-duration method to detect
>    faults on the communication path between adjacent forwarding engines.
>    The faults can be on interfaces, data links, and even the forwarding
>    engines.  It is a single, unified mechanism to monitor any media and
>    protocol layers in real time.

I do not know if "short-duration" is the right way to describe a "BFD session", even as the document says it is not a "BFD session". Whatever you call the continious sending of packets that are echoed back, which in my mind is a session, it can run with a short interval, but can run for a very long duration. Maybe "short-interval"?

Section 1, paragraph 9
>    This document updates [RFC5880] by defining a new method of BFD Echo-
>    Only without requiring an implementation to support the full BFD
>    protocol.  It specifies the use of the Unaffiliated BFD Echo over
>    IPv4 and IPv6 for a single IP hop.  A full description of the updates
>    to [RFC5880] is provided in Section 3.

As noted in Gyan Mishra's review, even as it might be obvious to some, it would help to clarify why Unaffliated BFD Echo cannot be supported over multi-hop BFD. 

Section 2, paragraph 10
>    Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo
>    session begins with the periodic, slow transmission of Unaffiliated
>    BFD Echo packets.  The slow transmission rate SHOULD be no less than
>    one second per packet, until the session is Up.  After the session is
>    Up, the provisioned transmission interval is used.  When the
>    Unaffiliated BFD Echo session goes Down, the slow transmission rate
>    is resumed.  The "Detect Mult" defined in [RFC5880] MUST be set to a
>    value provisioned on device A.  When the bfd.SessionState is Up and a
>    "Detect Mult" number of Unaffiliated BFD Echo packets have not
>    arrived at device A as they should, the device A "MUST set
>    bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function
>    Failed)", as specified in Section 6.8.5 of [RFC5880].

In this example, device A is the one implementing the full BFD stack. Thus it is the only one to have a notion of session being up. Can that be made explicit in the text?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2, paragraph 6
> iscriminator" field only, which is conform to the procedure specified in Sect
>                                    ^^^^^^^
Consider using either the past participle "conformed" or the present participle
"conforming" here.
Murray Kucherawy
No Objection
Comment (2024-10-16 for -12) Sent
I support Roman's DISCUSS.

The SHOULD in Section 2 appears to be re-stating advice from RFC 5880.  I suggest not using SHOULD here if that advice is simply being carried forward, since you already refer back to that document whose advice is still in effect.  Or if you're actually tweaking that advice here, I suggest being more explicit that that's what's going on.
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
(was Discuss) No Objection
Comment (2024-10-29 for -12) Sent
Thank you to Gyan Mishra for the GENART review.  Please review this thread as it proposes helpful clarifying language.

Thank you for re-chartering the WG to address my DISCUSS feedback.
Warren Kumari
No Objection
Comment (2024-10-15 for -12) Sent
Much thanks to Dhruv for the initial OpsDir review (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-11-opsdir-lc-dhody-2024-10-08/), and then for updating the reviw (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-12-opsdir-telechat-dhody-2024-10-10/) to explicitly note that their concerns have been addressed. 
I'm traveling at the moment, and so have relied heavily on the review.
Zaheduzzaman Sarker
(was Discuss) No Objection
Comment (2024-12-11) Sent
Thanks for addressing my discuss point.