Re: Comments on draft-ietf-bfd-unaffiliated-echo-05

[[e-mail]]

Jeff,






Thank you very much for the insightful and detailed review and comments, especially the proposed text, very helpful.


A new -06 revision to address your comments has just been posted: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-06.


Please see inline for details...




Original



From: JeffreyHaas <[e-mail]>
To: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2023年03月22日 01:04
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-05


[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.
 [XM]>>> OK.
 
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.
 [XM]>>> OK.




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.
 [XM]>>> OK.
 
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".   
 [XM]>>> OK.




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." 
 [XM]>>> OK.




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]." 
 [XM]>>> OK.




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." 
 [XM]>>> OK.




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.
 [XM]>>> The related text was changed as below.

OLD

such as BFD "Your Discriminator" defined in [RFC5880] (BFD


   "My Discriminator" can be set to 0 to avoid confusion),

NEW

such as BFD "Your Discriminator" and/or "My Discriminator" defined in [RFC5880].




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.
 [XM]>>> OK.




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.
[XM]>>> Acc to your last review on version -01 (https://mailarchive.ietf.org/arch/msg/rtg-bfd/FlSvmcBmjuTW2Kl1NhVgmapPZuY/) the BFD Unaffiliated Echo packets can only be received with 254.

The related text was changed as below.


OLD

All BFD Echo packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255.

NEW

All BFD Unaffiliated Echo packets for the session MUST be	sent with a Time to Live (TTL) or Hop Limit 
value of 255, and received with a TTL or Hop Limit value of 254, otherwise the received packets MUST 
be dropped [RFC5082].




314       Within the BFD Echo packet, the "Desired Min TX Interval" and
 
This is a BFD Control packet carried via BFD Echo.
 [XM]>>> OK. It's called BFD Unaffiliated Echo packet now.




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)." 
 [XM]>>> OK.




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.
 [XM]>>> OK.




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." 
 [XM]>>> OK.
 
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." 
 [XM]>>> OK.




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.
 [XM]>>> OK.




324       Similar to what's specified
325       in [RFC5880], the BFD Echo session begins with the periodic, slow
 
BFD Unaffiliated Echo session
 [XM]>>> OK.




326       transmission of BFD Echo packets, the slow transmission rate SHOULD
 
"packets. The slow" 
 [XM]>>> OK.




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." 
 [XM]>>> OK.




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.
 [XM]>>> The second choice was selected. The related text was changed as below.

OLD

Considering that the BFD peer wouldn't advertise "Detect Mult" as defined in	 	 

[RFC5880], the "Detect Mult" for calculating the Detection Time MUST

be provisioned at device A, the Detection Time at device A is equal

to the provisioned "Detect Mult" multiplied by the provisioned	transmission interval. 

NEW

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 BFD Unaffiliated 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].




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.
 [XM]>>> OK.




341       The Unaffiliated BFD Echo can be used when two devices are
 
"Unaffiliated BFD Echo can" (drop leading The)
 [XM]>>> OK.




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." 
 [XM]>>> OK.




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.
 [XM]>>> OK.




Thanks again,

Xiao Min




-- Jeff