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 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? GIM>> I am a bit confused by the "BFD Async procedures" term. In your opinion, what are these procedures defined in RFC 5880? BFD state machine? BFD state changes? I believe it would help me if you could give an example, and add more details to the interpretation of that term. [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his comments on -05 version of this draft [1]. My understanding to the term is that the BFD Control packet and the procedure on demultiplexing it, as well as the BFD state machine and the procedure on changing the state are mostly reused. [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/ GIM2>> I imagine that we expect a reader of this document to be familiar with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD Async procedures". If that is correct, then any new term must be explained or defined in this document. Would you agree? [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing procedures more clear? GIM3>> Yes, that would address my concern. [XM-4]>>> OK. Will make the change. 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. 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. GIM>> Thank you for the clarification. I feel that the current text and its location are unclear. Reiterating the scope of the proposed solution will certainly make it clearer. [XM-2]>>> OK. Please see the proposed changes as below. OLD 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. NEW Section 5 of [RFC5880] indicates that the payload of an affiliated 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 Unaffiliated BFD Echo packets and what to do with them. GIM2>> I cannot find in RFC 5880 any reference to the affiliated BFD Echo function. As I noted above, all new terms used in a document must be explained and/or defined in it. I think that applies to the "affiliated BFD Echo" term too. [XM-3]>>> OK. Propose to make some changes to the Introduction section. OLD The former scenario is not changed by this document in any way. The latter scenario is referred to as Unaffiliated BFD Echo in this document. NEW The former scenario is referred to as affiliated BFD Echo, which is not changed by this document in any way. The latter scenario is referred to as Unaffiliated BFD Echo in this document. GIM3>> Thank you for patiently working with me. The proposed new text addresses my concern. [XM-4]>>> OK. Will make the change. 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. GIM>> Perhaps that can be added to the document as "In the case when the value of Your Discriminator in the received packet is zero, demultiplexing is done based on ..."? [XM-2]>>> OK. Please see the proposed changes as below. OLD 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... NEW Device A performs its initial demultiplexing of a Unaffiliated BFD Echo session using the source IP address or UDP source port, that is to say, in the case when "Your Discriminator" in the received packet is zero, demultiplexing is done based on the source IP address or UDP source port, once the remote system echoes back the local discriminator... GIM2>> I am not sure what "initial" means in the description of the processing. Do you think it can be expressed as follows: Unaffiliated BFD Echo packets with zeroed "Your Discriminator" are demultiplexed based on the source IP address or UDP source port ... [XM-3]>>> Will make the change you proposed if there is no objection from Jeff. GIM3>> OK 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.". GIM>> Perhaps my question was unclear. I understand that the Sender starts the session at a slow rate. Then, after some event, the Sender switches to "the provisioned transmission interval". Hence my question What is that event that is described as "afterward"? [XM-2]>>> The event is that "the session is Up". To me, the text is clear enough, please suggest some text if that's still not clear to you. GIM2>> This document proposes extensive updates to RFC 5880, including the BFD state machine. I feel that it is on the authors to clarify how the updated state machine operates, and what causes states to change. [XM-3]>>> OK. Propose to do s/Afterwards/After the session is Up. GIM3>> I agree with the proposed editorial update. [XM-4]>>> OK. Will make the change. 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. 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. GIM>> I find myself confused. As I understand it, "expected value" is something that is known to the system either through configuration or a pre-set (hardcoded) value. And that value, supposedly, in validating the received packet, hence the "expected value" clause. But if the value must be ignored, then there's no expectation of it in the system. Right? I agree with the reasoning for initializing memory before transmitting a packet, but that is far from setting it to an "expected value", in my opinion. WDYT? [XM-2]>>> Here "an expected value" means "a certain value", is "a certain value" more clear? GIM2>> Unless it is used to validate the received packet. If it is not, then perhaps a requirement to re-initialize the memory block can do the job. WDYT? [XM-3]>>> Now that we all agreed on the desire that "avoid unset values being a potential vector for disclosure of uninitialized memory", providing a suggested value for each of these fields seems reasonable to me. GIM3>> OK, and thanks. [XM-4]>>> Thank you for your understanding. Best Regards, Xiao Min Best Regards, Xiao Min