Ballot for draft-ietf-bfd-unaffiliated-echo
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Thanks to Stephen Farrell for both of his secdir reviews of this draft.
# 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. "
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".
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.
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.
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.
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.
Thanks for addressing my discuss point.