Hi Gopi, Please see inline.
Original From: RaoP,Gopinatha <[email protected]> To: 肖敏10093570; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2025年09月24日 13:15 Subject: RE: Vxlan BFD RFC 8971 Hi Xiao Min, Thanks for clarifying that RFC 9521 provides a solution to per VNI BFD session. It just doesn’t provide support for vxlan but for other encap techniques as well. [XM]>>> As said, I believe the solution defined in RFC 9521 can also be applied to VxLAN. Specifically, Section 4 "BFD Encapsulation with the Inner Ethernet/IP/UDP Header" can be applied to VxLAN encapsulation with few tweaks. As far as the RFC 8971 is concerned, wouldn’t it be good to explicitly call out the “False Positive” cases which I have mentioned below and to overcome them either RFC 9521 technique can be proposed or per VNI ping mechanism can be added to ensure only the affected vteps are brought down or per VNI ping fails for all vteps , tunnel can be brought down? [XM]>>> An RFC can't be changed in any way once published, and the issue you raised is not an erratum, so one way I can think of is to work on a RFC8971bis document. The chairs can determine which way is better for the WG. Cheers, Xiao Min This way it would be much more deterministic ? Thanks, Gopi From: [email protected] <[email protected]> Sent: Wednesday, September 24, 2025 6:26 AM To: Rao P, Gopinatha <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Vxlan BFD RFC 8971 Hi Gopi, RFC 9521 provides a solution on one BFD session per VNI. Link as below. https://datatracker.ietf.org/doc/rfc9521/ Even if that RFC is published as "BFD for Geneve", I believe it's also applicable to "BFD for VxLAN". As to the scalability of per VNI BFD session, please refer to Security Considerations section of RFC 9521. Hope this helps. Cheers, Xiao Min Original From: RaoP,Gopinatha <[email protected]> To: Rahman <[email protected]>;BFD WG <[email protected]>; Date: 2025年09月24日 04:01 Subject: RE: Vxlan BFD RFC 8971 Thanks Rehman for updating the right WG. Hi All, Along with below questions, “How do we avoid False Positives” as the session is being run on VNI 0/1. 1. If the encap/decap fail on say VNI x then this BFD session running on VNI 0/1 will be active. 2. If VNI 0 BFD session goes down it doesn’t indicate other VNIs are failing to perform encap/decap right ? Per VNI BFD session if run on respective VNI would help over above false positives but again in scaled deployments/topologies the number of BFD sessions would not be scalable(?) Say there is a single BFD session run on VNI 0 , can running a synthetic traffic like ping on VNI to confirm if the actual traffic on VNI is broken or not ? If ping fails on certain VNI then bring down those vteps and keep the others operational. If ping fails on all bring down all the vteps. ( Yes this will add overhead to BFD Down detection time) Do share your thoughts on this. Thanks, Gopi From: Rahman <[email protected]> Sent: Monday, September 22, 2025 8:23 AM To: Rao P, Gopinatha <[email protected]> Cc: BFD WG <[email protected]> Subject: Re: Vxlan BFD RFC 8971 Correcting BFD WG alias. Sent from my iPhone On Sep 18, 2025, at 3:44 AM, Rao P, Gopinatha <[email protected]> wrote: Hi, From the below link should it be read as this RFC is specific to BFD session monitoring tunnel endpoints ? https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/16/#:~:text=At%20the%20same,from%20data%20packets. The RFC describes as to what should be the da_mac and dst_ip for these BFD sessions and these BFD packets should never make it out of the VTEP. Per VNI BFD session is not in the scope of this RFC and it is describing purely a mechanism to monitor tunnel endpoint using mgmt VNI ( 0 or 1) ? Can we associate a action to withdraw routes if this BFD session goes down because encap/decap is broken to peer VTEP ? Per VNI BFD session can still be operating fine but there might be processing issues for this BFD Session with VNI 0 for which it might have gone down so how should this BFD Down be interpreted ? Thanks, Gopi
