[resend with correct draft address] Authors,
Some comments on version -05: 16 Abstract 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 proposes a use of the BFD Echo 21 where the local system supports BFD but the neighboring system does 22 not support BFD. It would be good in the abstract to discuss the core idea of this mechanism: BFD Async procedures can be executed over the BFD Echo port where the remote system only loops packets back to the local system. The procedures discussed below cover this, but it takes some time to understand what the intent is. 73 1. Introduction [...] 86 BFD defines Asynchronous and Demand modes to satisfy various 87 deployment scenarios. It also supports an Echo function to reduce 88 the device requirement for BFD. When the Echo function is activated, 89 the local system sends BFD Echo packets and the remote system loops 90 back the received Echo packets through the forwarding path. If 91 several consecutive BFD Echo packets are not received by the local 92 system, then the BFD session is declared to be Down. It would be appropriate to reference RFC 5880, section 5 here. "The payload of a BFD Echo packet is a local matter". This draft, on the other hand, specifies the contents of the Echo packets and what to do with them. 94 When using BFD Echo function, there are two typical scenarios as 95 below: 97 * Full BFD protocol capability with affiliated Echo function. This 98 scenario requires both the local device and the neighboring device 99 to support the full BFD protocol. 101 * BFD Echo-Only method without full BFD protocol capability. This 102 scenario requires only the local device to support sending and 103 demultiplexing BFD Control packets. The bullet point above is a good place to discuss that the BFD Control packets are sent over the BFD Echo port, but that the BFD Async procedures are used with the modifications described in this document. 266 3. Unaffiliated BFD Echo Procedures [...] 288 To rapidly detect any IP forwarding faults between device A and 289 device B, a BFD Echo session MUST be created at device A, and the BFD I would remove the "To rapidly detect" clause before the comma and replace it with "For unaffiliated echo,". The current wording seems to suggest this procedure is the only way to detect forwarding faults. Perhaps also change "session MUST be created" with "session is created". 290 Echo session MUST follow the BFD state machine defined in Section 6.2 291 of [RFC5880], except that the received state is not sent but echoed 292 from the remote system, and AdminDown state is ruled out because 293 AdminDown effectively means removal of BFD Echo session. In this Perhaps: "from the remote system. BFD Unaffiliated Echo does not use the AdminDown state." 293 In this 294 case, although BFD Echo packets are transmitted with destination UDP 295 port 3785 as defined in [RFC5881], the BFD Echo packets sent by 296 device A are BFD Control packets too, Perhaps: "BFD Control packets are transmitted and received as BFD Echo packets using destination UDP port 3785, as defined in [RFC5881]." 296 the looped BFD Echo packets 297 back from device B would drive BFD state change at device A, 298 substituting the BFD Control packets sent from the BFD peer. Also 299 note that when device A receives looped BFD Control packets, the 300 validation procedures of [RFC5880] are used. Perhaps: "The procedures for BFD Async sessions are executed for the looped BFD Control packets as per [RFC5880], including validation and authentication." 302 Once a BFD Echo session is created at device A, it starts sending BFD 303 Echo packets, which MUST include BFD Echo session demultiplexing 304 fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD 305 "My Discriminator" can be set to 0 to avoid confusion), except for Why would My Discriminator be 0? A local value should be chosen to distinguish individual sessions. This is for a few reasons: - Demultiplexing for sessions that are Up should happen solely based on discriminators, if possible. - RFC 5880, Section 6.8.6 says: : If the My Discriminator field is zero, the packet MUST be : discarded. 306 BFD "Your Discriminator", device A can also use IP source address or 307 UDP source port to demultiplex BFD Echo session, or there is only one 308 BFD Echo session running at device A. Perhaps: Device A performs its initial demultiplexing of a BFD Unaffiliated session using the source IP address or UDP source port. 308 Device A would send BFD Echo 309 packets with IP destination address destined for itself, such as the 310 IP address of interface 1 of device A. All BFD Echo packets for the 311 session MUST be sent with a Time to Live (TTL) or Hop Limit value of 312 255. You need to mention the receive procedures as well here. Sent with 255, received with either 255 or 254. Cite RFC 5082. 314 Within the BFD Echo packet, the "Desired Min TX Interval" and This is a BFD Control packet carried via BFD Echo. 315 "Required Min RX Interval" defined in [RFC5880] may be populated with 316 one second, I'd suggest being more normative here: "SHOULD be populated with a value of 1 second (1,000,000 microseconds)." 316 which however has no real application and would be 317 ignored by the receiver. Perhaps: These values, however, are ignored and not used to calculate the Detection Time. 319 Considering that the BFD peer device B wouldn't advertise "Required 320 Min Echo RX Interval" as defined in [RFC5880], I'd suggest being more normative here. Perhaps: "The Required Min Echo RX Interval MUST be set to zero." 320 the transmission 321 interval for sending BFD Echo packets MUST be provisioned at device 322 A, Perhaps: "The transmission interval for BFD Unaffiliated Echo packets in the Up state MUST be provisioned on device A." 322 how to make sure the BFD peer device B is willing and able to loop 323 back BFD Echo packets sent with the provisioned transmission interval 324 is outside the scope of this document. Perhaps: "The method for provisioning device B to loop back BFD Echo packets is outside the scope of this document." Start a new paragraph here. 324 Similar to what's specified 325 in [RFC5880], the BFD Echo session begins with the periodic, slow BFD Unaffiliated Echo session 326 transmission of BFD Echo packets, the slow transmission rate SHOULD "packets. The slow" 327 be no less then one second per packet, until the session is Up, after 328 that the provisioned transmission interval is applied, and reverting 329 back to the slow rate once the session goes Down. "Up. Afterwards, the provisioned transmission interval is used. When the BFD Unaffiliated Echo session goes Down, the slow transmission rate is resumed." 329 Considering that 330 the BFD peer wouldn't advertise "Detect Mult" as defined in 331 [RFC5880], the "Detect Mult" for calculating the Detection Time MUST 332 be provisioned at device A, the Detection Time at device A is equal 333 to the provisioned "Detect Mult" multiplied by the provisioned 334 transmission interval. Your intent here is that the "Detect Mult" value is irrelevant since the BFD Unaffiliated Echo session can make its own choices as to what criteria it uses to determine that a session is Down. You're also trying to discuss the intended Detection Time. I think you have two choices here: 1. Permit the BFD Unaffiliated Echo implementation make completely local choices about the number of lost Echo packets and expected time between the packets. If so, suggest that the Detect Mult is set to a known value (e.g. 0). Maybe offer some advice about measuring time for the loss of packets. 2. Set a Detect Mult value and use existing text (e.g. RFC 5880, Section 6.8.5) to discuss that the loss of N packets in that Detect Mult is what is used to declare the session down. This likely permits easier debugging of the feature by observing the packets. There is still the challenge of calculating when a packet is lost or not. In the absence of negotiated timers, the value you're trying to observe is the round-trip time for an Echo packet. If the RTT is unknown, how do you figure that out? Your Detection Time becomes (Detect Mult * RTT), perhaps with jitter considerations. 336 4. Unaffiliated BFD Echo Applicability 338 Some devices that would benefit from the use of BFD may be unable to 339 support the full BFD protocol. Examples of such devices include 340 servers running virtual machines, or Internet of Things (IoT) 341 devices. Break into new paragraph. 341 The Unaffiliated BFD Echo can be used when two devices are "Unaffiliated BFD Echo can" (drop leading The) 342 connected and only one of them supports the BFD protocol, and the 343 other is capable of looping BFD Echo packets. 345 5. Security Considerations 347 All Security Considerations from [RFC5880] and [RFC5881] apply. 349 Note that the Unaffiliated BFD Echo prevents the use of Unicast 350 Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode. Perhaps: "Unaffiliated BFD Echo requires the remote device to loop BFD Echo packets. In order provide this service, the remove device cannot make use of of Unicast Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode." 358 In order to mitigate the potential reflector attack by the remote 359 attackers, or infinite loop of the BFD Echo packets, it's RECOMMENDED 360 to put two requirements on the device looping BFD Echo packets, the 361 first one is that a packet SHOULD NOT be looped unless it has a TTL 362 or Hop Limit value of 255, and the second one is that a packet being 363 looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use 364 a TTL or Hop Limit value of 254. Please cite RFC 5082 here. -- Jeff
