Hi Gunter, Thanks for your review and comments.Please see inline.
Original From: GunterVandeVeldeviaDatatracker <[email protected]> To: The IESG <[email protected]>; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月14日 19:01 Subject: Gunter Van de Velde's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-bfd-unaffiliated-echo-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # 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 [XM]>>> Thank you for pointing that out. I wonder how we can resolve that warning, do we need to contact the authors of RFC 5880 and get their grant? # 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. [XM]>>> Your suggestions significantly improve the readability of this document. Thank you very much! :-) #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. " [XM]>>> The alternative abstract you proposed looks good to me. Will use it in the next revision. 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. " [XM]>>> OK. Will change the text as you suggested. 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? [XM]>>> What about s/within its implementation/from its own standpoint? 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? [XM]>>> I agree "For the Unaffiliated Echo procedure" is more accurate. Thank you! 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]. " [XM]>>> OK. Will change the text as you suggested. 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. " [XM]>>> OK. Will change the text as you suggested. As I recall it, the uninitialized memory came from a debate on whether a specific value should be suggested by this document. 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. " [XM]>>> OK. Will change the text as you suggested. 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? [XM]>>> As far as I know, the range of the valid transmission intervals with unaffiliated sessions has nothing special. 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. " [XM]>>> OK. Will change the text as you suggested. 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/ [XM]>>> I suggest to remain the current text as is, because when using Unaffiliated BFD Echo the local system won't enable BFD Asynchronous or Demand mode. 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. " [XM]>>> OK. Will change the text as you suggested. Cheers, Xiao Min
