Review of -13 vs. previous open issues. The short version is the issue list is largely resolved. Summary of actions: - Update BFD Echo text as per last comment in this reply. - We need to resolve MAC address assignment. - There may be a lingering issue over the loopback network which will be addressed in a reply to Benjamin.
-- Jeff On Tue, Jun 16, 2020 at 05:10:57PM -0400, Jeffrey Haas wrote: > > Open Issue 2: Document Status should be Informational rather than Proposed > > Standard. > > > > Proposed Action: Greg should make the document Informational. Prior WG > > discussion suggested that we don't really care what level it should be at, > > and had actually requested IESG guidance long ago via our AD. > > This action is pending. This is resolved. > > --- > > > > Open Issue 5: Comma parsing issue (COMMENT via Benjamin K.) > > > > Proposed Action: Accept Benjamin's suggested changes. (RFC Editor will win > > the day here though!) > > This action is pending. This is, in my opinion, resolved. The text in -13 is: : This document describes the use of Bidirectional Forwarding Detection : (BFD) protocol to enable monitoring continuity of the path between : VXLAN VTEPs that are performing as Network Virtualization Endpoints, : and/or availability of a replicator MSN using a Management VNI : (Section 4). All other uses of the specification to test toward : other VXLAN endpoints are out of the scope. > > --- > > > > Open Issue 6: "Section 3, MUST NOT be forwarded to a VM" (COMMENT via > > Benjamin K.) > > > > Proposed Action: The fate of this issue is tied to Open Issue 3. > > If the proposal is limited solely to management VNI, this text is not > > relevant and may be deleted. > > This action is still open. This is resolved. > > --- > > > > Open Issue 7: "::FFFF:7F00:0/104 IPv6 range" (COMMENT via Benjamin K.) > > > > Proposed Action: I believe this issue's fate is similarly tied to Open > > Issue 3. > > If the proposal is limited solely to management VNI, this text is not > > relevant and may be deleted. > > This action is still pending. I believe this issue should be resolved in its original intent. However, Benjamin still has it listed in his most recent comments. Will move the lingering response to there. > > --- > > > > Open Issue 8: "Section 4: MUST ensure that the BFD Control packet is not > > forwarded to a tenant but is processed locally at the remote VTEP" (COMMENT > > via Benjamin K.) > > > > Proposed Action: I believe this issue's fate is similarly tied to Open > > Issue 3. > > If the proposal is limited solely to management VNI, this text is not > > relevant and may be deleted. > > This action is still pending and perhaps requires further discussion. > > Benjamin's point was: > "This has to be 100% reliable, and I think we need to provide some > example mechanism that has that property even if we don't mandate that > it be the only allowed mechanism." > > The motivation here was that when this specification was intended to address > a fully generalized BFD for vxlan for arbitrary VNIs, there was a strong > need to say "do not forward the BFD traffic to the tenant". > > For the now default scenario of only the management VNI, this text may be > adequate. Benjamin should look at the current document and decide if the > scenario is still of concern. I believe our discussion is that it's now appropriate in its current form. I'm considering this resolved. > > --- > > > > Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC > > addresses." (COMMENT via Benjamin K.) > > > > Proposed Action: I believe this issue's fate is similarly tied to Open > > Issue 3. > > If the proposal is limited solely to management VNI, this text is not > > relevant and may be deleted. > > In -12, we now have the following text: > "Destination MAC: since a Management VNI is the VNI that does > not have any tenants, the value of this field is not analyzed > by the receiving VTEP." > > For the management VNI, this text is true. However, it likely requires a > value that is described in the specification. > > Proposed solution: A MAC value should be chosen that is well known and the > text would become: > > "Destination MAC: A Management VNI, which does not have any tenants, will > have no dedicated MAC address for decapsulated traffic. The value X:X:X:X:X > SHOULD be used in this field." > > SHOULD might need to be MUST. Since a partial motivation for permitting the > flexibility in the specification to NOT use the management VNI is desired, > MUST might be inappropriate. I believe there's consensus that we want a SHOULD here. The discussion for the MAC address has been split to a separate thread. > > --- > > > > Open Issue 19: "Section 4...FCS" (COMMENT via Eric V.) > > > > Proposed Action: Accept suggested change to "Outer Ethernet FCS"? > > This action is pending. This is resolved in -13. > > --- > > > > Open Issue 20: "using the src mac as the dst mac" (COMMENT via Eric V.) > > > > Proposed Action: ? I'm unclear what the proposal and comment is here. > > It is unclear what action was requested. Still lingering. Will defer to next IESG review. > > --- > > > > Open Issue 22: "terminology isn't" (COMMENT via Warren K.) > > > > Proposed Action: Either rename the section "acronyms used in this document" > > or expand the section to cover the terminology. > > This action is still pending. This is resolved in -13. > > --- > > > > Open Issue 25: "leading to a false negative" (COMMENT via Barry L.) > > > > Proposed Action: The underlying concern in this sentence is that BFD packets > > must not be mis-delivered to VMs since there will be no BFD machinery > > present in that VM to execute the BFD procedures and thus sessions will > > drop. Possible action is to simply delete this sentence since it > > prematurely anticipates procedures later described in the document. > > This action is still pending. The problematic text was dropped. This issue is resolved. > > --- > > > > Open Issue 26: "loopback range through a firewall" (COMMENT via Barry L.) > > > > Proposed Action: Accept suggested rewording. > > This action is still pending. I believe this issue was resolved by dropping the firewall text in -13. > --- > > Section 7 should be rewritten as: > 7. BFD Echo Function > > Support for the BFD Echo function [RFC5880], Section 3.2, is outside the > scope of this document. This issue is still pending. -- Jeff
