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 <[email protected]> wrote: > Hi Greg, > > > The points we have converged are trimmed, because I received a notice from > [email protected] 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. > >>> >>> - >>> >>> 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. > >>> >>> - >>> >>> 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. > >>> >>> - >>> >>> 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. > > >>> - >>> >>> 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. > >>> - >>> >>> 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. > > Best Regards, > > Xiao Min >
