Dear Authors,
I've read the latest version and I have several questions. I greatly
appreciate your insights and clarifications:
- Firstly, what is being standardized by this specification? I couldn't
find that the described process requires any cooperation, action from a
remote BFD peer. As I can see, only the sender of BFD Echo packets is
acting and thus every action, e.g., construction of the test probe, a
method to demultiplex incoming test packets, etc., is internal to the
sender. Hence, it appears that there is nothing to be standardized as
all of it is internal processing that does not impact any other BFD system.
- The first update to RFC 5880 seems to suggest that the Echo function
is an essential part of both Asynchronous and Demand modes of BFD. The
original text of RFC 5880 characterizes the Echo function as an adjunct,
i.e., a supplemental, function. The proposed new text - as a function that
completes both BFD modes, makes them perfect, i.e., is an essential,
necessary component. I think that that is not really the case and the BFD
Echo function is not an essential, optional function of the BFD protocol.
- The last sentence in the next proposed update to the RFC 5880 concerns
me:
The Echo function may also be used independently, with neither Asynchronous
nor Demand mode.
It appears that, if accepted, the BFD Echo function is transformed into an
additional BFD mode. If that is the case, then this specification, in my
opinion, is not updating the RFC 5880 but is defining a new protocol.
- For all the proposed updates to the RFC 5880, it is not clear why
in some proposed texts, both modes, Asynchronous, and Demand, are
referenced but in some only the Asynchronous. For example, updates to
Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous
mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD
modes.
- In the second paragraph of Section 3 of the draft, the specification
recommends that an implementation supporting this draft follows the BFD
state machine, as defined in RFC 5880. Why is it a recommendation and not a
requirement? And further, if an implementation does not follow the BFD
state machine, is it still BFD?
- Further, in the third paragraph of Section 3, it appears that the BFD
Echo function on device A starts transmitting BFD control packets once the
session is created. What is the state of the created BFD Echo session? As I
understand it, the BFD state machine starts from the Init. Isn't that the
case for this document as well?
- In the same first sentence of the third paragraph in Section 3,
another recommendation reads as "SHOULD include a BFD Echo session
demultiplexing field". I have questions similar to the recommendation in
the second paragraph of Section 3:
- Why is it a recommendation and not a requirement?
- What happens if an implementation does not include that particular
field in the transmitted packets? Is it still a BFD Echo? How
then sessions
are demultiplexed?
I greatly appreciate your consideration and help in clarifying these
aspects of the draft.
Now, I may have an alternative proposal that can produce the desired result
and not require any update to RFC 5880. Please consider the following:
- RFC 8562 introduced a new type of the BFD session - MultipointHead. A
system acting as the MultipointHead periodically transmits BFD Control
packets in Demand mode, doesn't have the Init state, and starts in the Up
state (no three-way handshake).
- Considering the above, a system that uses the Unaffiliated BFD Echo
starts as MultipointHead with bfd.DesiredMinTxInterval set to the maximum
value (or any sanely large enough). The exact construction of the periodic
BFD Control packets transmitted by the MultipointHead needs some detailed
analysis (I haven't spent enough time on that).
- In the meantime, because the BFD session for the MultipointHead
started in the Up state, it can transmit BFD Echo packets according to RFC
5880 and RFC 8562.
I think that if this proposal works, it may be moved as Informational since
it describes the use of well-known BFD principles and mechanisms in an
innovative and useful manner.
What are your thoughts, questions?
Regards,
Greg
