Jeff,
Thank you for the quick reply. Please see inline... Original From: JeffreyHaas <jh...@pfrc.org> To: 肖敏10093570; Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>;n...@ietf.org <n...@ietf.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2022年11月04日 19:20 Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks Xiao Min, On Nov 3, 2022, at 10:52 PM, <xiao.m...@zte.com.cn> <xiao.m...@zte.com.cn> wrote: : 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 withthere is a motivation for using the MAC addresses within a given VNI contextin addition to the IP addresses. If this is clear from typical Geneveprocedures, it might be worth a nod to the appropriate section. I'll notethat 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. To restate my question, on a given device receiving, for a given VNI, will there ever be multiple sets of the same IP addresses? If yes, the addition of the MAC addresses for initial multiplexing makes sense. Otherwise, perhaps they are unneeded? [XM-2]>>> The answer to your first question is Yes. In section 4.1 of this document it says 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. Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping between VAP and VNI at one NVE, multiple BFD sessions between two NVEs for the same VNI are allowed. What I'm far more puzzled by is the source port demultiplexing step. Thisisn'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? It actually can make configuration more difficult. You must then have provisioning for the UDP ports for your sessions on each side of things. If you don't need to explicitly control more than one session between the same VNI, for the same IP address pairs, on the same device, you can simply demultiplex based on the UDP destination port for BFD single hop as per RFC 5881 procedures. If you have need for such explicit control, such additional procedure is fine. [XM-2]>>> Yes, I believe there is such a need. Furthermore, the provision for source UDP port is optional even if it's included in the demultiplexing fields, because the source UDP port is not the only field for demultiplexing. In other words, if an implementation selects not to configure the source UDP port, but just use the default one, this implementation can still comply with this specification. Best Regards, Xiao Min -- Jeff
