Hi Greg,
Thank you for the continued discussion.
As to Standard vs Experimental/Informational, I've stated my opinion and no
more to add.
For the last two remaining discussion points, please see inline [XM-5]>>>.
Original
From: GregMirsky <gregimir...@gmail.com>
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
Date: 2023年06月15日 20:01
Subject: Re: Fw: New Version Notification for
draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min,thank you for your constructive consideration of my comments. I am
glad that we have converged on technical issues. Minor remaining, in my
opinion, can remain in the "let's agree to disagree" category. I have added two
notes below, tagged GIM4>>.
In conclusion, I think that if the document is switched to Experimental (which
seems like the most logical to me) or Informational, then perhaps it then
doesn't need to update RFC 5880 altogether but define a new, standalone
Unaffiated BFD function, using some of the mechanisms defined in RFC 5880.
Regards,
Greg
On Thu, May 18, 2023 at 10:55 AM <xiao.m...@zte.com.cn> wrote:
Hi Greg,
Thank you for the comprehensive and detailed discussion, which improves this
document in many aspects.
I'll post a new version draft after we reach agreement on the last few points.
Please see inline [XM-4]>>>.
Original
From: GregMirsky <gregimir...@gmail.com>
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
Date: 2023年05月18日 12:22
Subject: Re: Fw: New Version Notification for
draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min,thank you for your thoughtful consideration of my notes. I greatly
appreciate it and our discussion that helps us to come to resolutions. Please
find my follow-up notes tagged GIM3>>.
Best regards,
Greg
On Sun, May 14, 2023 at 11:47 PM <xiao.m...@zte.com.cn> wrote:
Hi Greg,
The points we have converged are trimmed, because I received a notice from
rtg-bfd-ow...@ietf.org that "Message body is too big".
Please see inline [XM-3]>>>.
Original
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?
GIM>> I think that the capability to faster detection of a network failure is
always desirable. Thus, the statement can be presented as a general node
requirement. On the other hand, it can be worded as an observation. Using
normative keywords in a lowercase form might confuse readers.
[XM-2]>>> I'd like to try again. Please see the proposed changes as below.
OLD
To minimize the impact of device/link faults on services and improve network
availability, a network device must be able to quickly detect faults in
communication with adjacent devices.NEW
To minimize the impact of device/link faults on services and improve network
availability, in some cases a network device needs to be able to quickly detect
faults in communication with adjacent devices.
GIM2>> In your opinion, how important to the document and this text is it to
say "in some cases"? Personally, I think that the ability to quickly detect a
network failure is a generic requirement, essential in all scenarios.
[XM-3]>>> Please note that "in some cases" is derived from your comments
"Indeed, in some cases, local protection is a viable option, while in other
environments, e2e path protection might be preferable". The text focuses on the
communication with adjacent devices, so "in some cases" is used, does that make
sense to you?
GIM3>> It seems like my note confused you. I was pointing out that in some
cases operator may use local protection; in others - e2e. And, in some cases,
both protection methods thus effectively creating a multi-layer OAM
environment. But the ability to quickly detect network failure is critical in
all cases. I hope that clarifies my views.
[XM-4]>>> Let me rephrase my words. :-) As you know, BFD can be used for either
single-hop or multi-hop fault detection, while the text says "detect faults in
communication with adjacent devices", which means only single-hop application,
so "in some cases". In other cases, BFD is used only for multi-hop application,
single-hop fault detection is not needed.
GIM4>> Thank you for the clarification. In that case, perhaps can explicitly
point to the single-hop use of the Unaffiliated BFD Echo function, avoiding
somewhat ambiguous "in some cases".
[XM-5]>>> OK. Propose to change the text as below.
OLD
To minimize the impact of device/link faults on services and improve network
availability, a network device must be able to quickly detect faults in
communication with adjacent devices.
NEW
To minimize the impact of device/link faults on services and improve network
availability, in the single-hop cases a network device needs to be able to
quickly detect faults in communication with adjacent devices.
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.
GIM>> To me, that is not clear from the current text. I think that adding more
detail would help.
[XM-2]>>> OK. Please see the proposed changes as below.
OLD
* Your Discriminator MUST be set to 0 initially, and then MUST be set to the
same as My Discriminator echoed back.
NEW
* Your Discriminator MUST be set to 0 initially, and then MUST be set to the
same as My Discriminator looped back. In other words,
Your Discriminator MUST be changed from 0 to the received My Discriminator
once initial demultiplexing of the received packet is done.
GIM2>> Does "initial demultiplexing" replace BFD Control packet validation as
defined in RFC 5880 and RFC 5881? As discussed above, demultiplexing only
matches the source IP address or source UDP port number in the received packet.
Is that sufficient to validate it?
[XM-3]>>> I believe the initial demultiplexing is comformed to RFC 5880 and
5881. It seems to me the source IP address or source UDP port is sufficient for
initial demultiplexing.
GIM3>> It seems like RFC 5881 specifies demultiplexing of BFD Control packets
with Your Discriminator zeroed differently:
... any BFD packet from the remote machine with a
zero value of Your Discriminator MUST be associated with the session
bound to the remote system, interface, and protocol.
And later is noted:
An implementation MAY use
the UDP port source number to aid in demultiplexing incoming BFD
Control packets ...
It seems like this document changes demultiplexing process defined in RFC 5881.
[XM-4]>>> I prefer not to use the normative language as RFC 5881. The
difference comes from the fact that in RFC 5881 the BFD Control packet is sent
from the remote system, while in this document sent from the local system and
looped back by the remote system. Furthermore, the difference doesn't mean the
initial demultiplexing in this document would replace that in RFC 5881.
GIM4>> I think that for the receiving BFD component, the source of the BFD
Control message is not important. Would you agree? If that is the case, then
demultiplexing must be done using the same principles whether in Asynchronous
BFD mode or using the Unaffiliated BFD Echo function. What, as I understand it,
is different - BFD state machine with transitions. WDYT?
[XM-5]>>> I think the source of the BFD Control packet is relevant. As you
quoted, RFC 5881 says "
... any BFD packet from the remote machine with a
zero value of Your Discriminator MUST be associated with the session
bound to the remote system, interface, and protocol."
The *remote system* indicates the source of the BFD Control packet, while for
Unaffiliated BFD Echo the source is the *local system*.
Although I agree with you that the demultiplexing must be done using the same
principles whether Async BFD or Unaffiliated BFD Echo, I don't think the same
text as RFC 5881 can be reused. If you still dislike the current text, would
you please provide some text change suggestion?
Best Regards,
Xiao Min
Best Regards,
Xiao Min
Best Regards,
Xiao Min
