Jeff,
Thank you for the thorough review and thoughtful comments. Please see inline... Best Regards, Xiao Min Original From: JeffreyHaas <jh...@pfrc.org> To: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; Cc: NVO3 <n...@ietf.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2022年11月04日 08:11 Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks 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. :-) [XM]>>> Good observation. You're right that "loopback range" is used in RFC 8971 while a dedicated loopback address is used in this document. That's an intended change. In -00 wg draft, the "loopback range" as RFC 8971 was used, and after discussion among the authors, it's realized that a dedicated loopback address would facilitate the implementation, so this change. Hope the IESG would not object it. :-) : 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." [XM]>>> The changes you suggested look good to me. Will use your text in the next revision. : 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. [XM]>>> Would you please elaborate a bit on the possible nod? As I understand it, the reason why there is no a parallel in RFC 8971 is that only one BFD session using the management VNI is needed between a pair of VTEPs, so there is no demultiplexing procedure needed in RFC 8971. 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? [XM]>>> In section 4 of RFC 5881 it says An implementation MAY use the UDP port source number to aid in demultiplexing incoming BFD Control packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session. It seems adding the UDP source port is helpful, what do you think? The same comment on UDP port number holds for section 5.1 for IP encapsulation. [XM]>>> OK. I'll take care of section 5.1 too. -- Jeff
