Matthew, On Fri, Oct 21, 2022 at 09:37:13AM +0000, Bocci, Matthew (Nokia - GB) wrote: > NVO3 and BFD working groups, > > To give more time to review and comment on this draft in the light of the > draft submission deadline of 24th October, I am extending this WG last call > to Friday 4th November 2022. > > Please review and post any comments to the NVO3 list (including whether you > support publication as an RFC).
Thanks for your patience. I have reviewed the BFD for geneve draft. My comments are below. Section 4: : Destination IP: IP address of a VAP of the terminating NVE. If the VAP of : the terminating NVE has no IP address, then the IP address 127.0.0.1 for : IPv4 or ::1/128 for IPv6 MUST be used. The procedure here is clear. I suspect that those who have been exposed to other prior tunnel endpoint destination IP address discussions may note that more of the "loopback range" has been used. In particular, the comparable BFD for vxlan - RFC 8971, Section 3. While I'm not suggesting that the draft change its behavior, the Working Group may wish to be aware that this may come up as a point of discussion. That said, the IESG has collective amnesia about this point when it shows up in other proposals so I think you're fine. :-) : In BFD over Geneve, a BFD session is originated and terminated at VAP, : usually one NVE owns multiple VAPs, so multiple BFD sessions may be running : between two NVEs, there needs to be a mechanism for demultiplexing received : BFD packets to the proper session The above is a bit of a run-on sentence. Suggest minor punctuation changes: "In BFD over Geneve, a BFD session is originated and terminated at VAP, usually one NVE owns multiple VAPs. Since multiple BFD sessions may be running between two NVEs, there needs to be a mechanism for demultiplexing received BFD packets to the proper session." : If the BFD packet is received with Your Discriminator equals to 0, the BFD : session MUST be identified using the VNI number, and the inner : Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the destination : MAC, the destination IP, and the source UDP port number present in the inner : Ethernet/IP/UDP header. Not being familiar with Geneve configuration at all, I'll presume that with there is a motivation for using the MAC addresses within a given VNI context in addition to the IP addresses. If this is clear from typical Geneve procedures, it might be worth a nod to the appropriate section. I'll note that this point of procedure doesn't seem to have a parallel in BFD for vxlan. What I'm far more puzzled by is the source port demultiplexing step. This isn't normal for RFC 5881. Why is there a desire to add this to initial demultiplexing? The same comment on UDP port number holds for section 5.1 for IP encapsulation. -- Jeff
