Hi Greg,
Thank you for the detailed review and comments, although I don't think your
comments justify your conclusion.
Please see inline...
Original
From: GregMirsky <gregimir...@gmail.com>
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
Date: 2023年04月29日 03:42
Subject: Re: Fw: New Version Notification for
draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min,thank you for sharing updates. I've read the new version and have
several questions and comments.
It is stated in the Abstract:
BFD Async procedures can be executed over the BFD
Echo port where the neighboring system only loops packets back to the
local system.
Is this conclusion differs from the definition of the BFD Echo function in RFC
5880? If it is not, what is the value of such a re-statement? If it is, it
seems like an explicit attribution of this conclusion to this document would be
helpful.
[XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the BFD
Echo port because it classifies BFD Echo as an affiliated function. Would you
please suggest some text you think helpful?
Is the following a requirement or an observation:
a network device must be able to quickly detect
faults in communication with adjacent devices.
If the former, please capitalize the normative language. If the latter, then it
appears as an arguable view. Indeed, in some cases, local protection is a
viable option, while in other environments, e2e path protection might be
preferable.
[XM]>>> At the beginning of the sentence "in some cases" can be added, is that
acceptable to you?
Further, in Introduction, I read:
Section 5 of
[RFC5880] indicates that the payload of a BFD Echo packet is a local
matter and hence its contents are outside the scope of that
specification. This document, on the other hand, specifies the
contents of the Echo packets and what to do with them.
It seems to me that this draft is positioned as the definition of the content
of an Echo message and the processing of it, whether as an unaffiliated or
affiliated (RTC5880-style) function. Is that correct?
[XM]>>> That's incorrect. This document specifies only Unaffiliated BFD Echo,
and it doesn't touch affiliated BFD Echo.
I hope you can help me understand the demultiplexing of Unaffiliated BFD
sessions:
Device A performs its
initial demultiplexing of a Unaffiliated BFD Echo session using the
source IP address or UDP source port, once the remote system echoes
back the local discriminator, all further received packets are
demultiplexed based on the "Your Discriminator" field only, which is
conformed to the procedure specified in Section 6.3 of [RFC5880].
Does "initial demultiplexing" refers to the first BFD Control message
transmitted in the Unaffiliated BFD Echo mode?
[XM]>>> Not exactly. Actually "initial demultiplexing" is applied to the
received BFD Control packet(s) whose "Your Discriminator" is zero.
Considering that "device B would not intercept any received Unaffiliated BFD
Echo packet", how "the remote system echoes back the local discriminator"?
[XM]>>> Here "echoes back" means "loops back", is "loops back" more clear?
A lengthy copy of a text from Section 4 of RFC 5881 seems like unnecessary:
the destination address MUST be chosen in such a way as to
cause the remote system to forward the packet back to the local
system. The source address MUST be chosen in such a way as to
preclude the remote system from generating ICMP or Neighbor Discovery
Redirect messages. In particular, the source address SHOULD NOT be
part of the subnet bound to the interface over which the BFD Echo
packet is being transmitted, and it SHOULD NOT be an IPv6 link-local
address, unless it is known by other means that the remote system
will not send Redirects.
It seems that a reference to that section and something like "rules stated in
Section 4 [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD
Echo Control message" could be sufficient.
[XM]>>> I'd like to follow your suggestion if there is no objection from Jeff.
What is the interpretation of "expected value"? It appears that none of these
values are used, but are ignored. Right?
[XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a
potential vector for disclosure of uninitialized memory".
A zero value of the Required Min Echo RX Interval field per RFC 5880 is
interpreted as no support for the Echo function. But it is the recommended
value. Although it is ignored. Thus, what is the benefit of initializing the
field after all?
[XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a
potential vector for disclosure of uninitialized memory".
In the description
Afterwards, the
provisioned transmission interval is used.
What is the event that triggers the "afterward" transition?
[XM]>>> The preceding text says "The slow transmission rate SHOULD be no less
then
one second per packet, until the session is Up.".
With the high number of "this value MUST be ignored on receipt", "the
Unaffiliated BFD Echo packet reuses the format of the BFD Control packet
defined in [RFC5880]" seems like a severe overstatement.
[XM]>>> I don't think so. Ignoring some fields on receipt doesn't break the
truth that BFD Control packet is reused here.
Which event triggers the transition in
* Your Discriminator MUST be set to 0 initially, and then MUST be
set to the same as My Discriminator echoed back.
[XM]>>> The event is that "My Discriminator" is echoed/looped back.
What happens if Desired Min TX Interval, Required Min RX Interval, or Required
Min Echo is not set to "the expected value"?
[XM]>>> Unset values can be a potential vector for disclosure of uninitialized
memory.
Best Regards,
Xiao Min
In conclusion. As we learned from the BBF Liason, the Broadband Forum is not
seeking standardization of the mechanism described in TR-146. Also, I learned
about the implementation of the mechanism described in BBF's TR-146, and the
authors are not interested in standardization either, as, in their opinion,
there's no externally noticeable behavior that requires specification. So, I
still don't see any value in standardizing what is described in the document.
Regards,
Greg
On Sun, Apr 23, 2023 at 7:16 PM <xiao.m...@zte.com.cn> wrote:
Dear BFD WG,
A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted, attempting
to address all the WGLC comments.
The main updates are as below.
* add a sentence to clarify that this document doesn't change the affiliated
BFD Echo function.
* change the order of section 2 "Updates to RFC 5880" and section 3
"Unaffiliated BFD Echo Procedures".
* add a summary on the Unaffiliated BFD Echo packet fields setting into the end
of section "Unaffiliated BFD Echo Procedures".
* change the text on IP address setting to the same as specified in section 4
of RFC 5881.
* some editorial changes, e.g., s/BFD Unaffiliated Echo packet/Unaffiliated BFD
Echo packet/g.
Best Regards,
Xiao Min
Original
From: internet-dra...@ietf.org <internet-dra...@ietf.org>
To: Raj Boddireddy <rche...@juniper.net>;Raj Chetan Boddireddy
<rche...@juniper.net>;Reshad Rahman <res...@yahoo.com>;Ruixue Wang
<wangrui...@chinamobile.com>;Weiqiang Cheng
<chengweiqi...@chinamobile.com>;肖敏10093570;
Date: 2023年04月24日 10:09
Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.
Name: draft-ietf-bfd-unaffiliated-echo
Revision: 07
Title: Unaffiliated BFD Echo
Document date: 2023-04-23
Group: bfd
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07
Abstract:
Bidirectional Forwarding Detection (BFD) is a fault detection
protocol that can quickly determine a communication failure between
two forwarding engines. This document proposes a use of the BFD Echo
where the local system supports BFD but the neighboring system does
not support BFD. BFD Async procedures can be executed over the BFD
Echo port where the neighboring system only loops packets back to the
local system.
This document updates RFC 5880.
The IETF Secretariat
