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. If the encap/decap fail on say VNI x then this BFD session running on VNI 0/1 will be active.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
