Hi Prasad, As discussed below is the clarification part
Since a BFD session established between two EVPN PEs is associated with a specific EVI/ VNI the scope of liveness detection is limited to only that EVI/ VNI. If this BFD session transitions to the Down state due to encapsulation/decapsulation issues on that VNI, or for any other reason, it does not necessarily indicate a data-plane failure for other VNIs that may continue to remain operational. The treatment of such BFD Down events is left to the implementation. While per-EVI/VNI BFD sessions provide one possible solution to a more fine grained liveness detection, this approach raises scalability concerns. Alternatively, other OAM mechanisms for data-plane continuity/ liveness checks may be employed to verify liveness for EVI/VNIs that are not protected by BFD. Thanks, Gopi From: Rao P, Gopinatha <gopinatha.ra...@hpe.com> Sent: Thursday, September 25, 2025 9:03 PM To: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com>; draft-ietf-bess-evpn-...@ietf.org Subject: Re: Mail regarding draft-ietf-bess-evpn-bfd Hi Prasad, Sure we can have call. It would be good to clarify or mitigate this false positive by performing a synthetic traffic test like per vni ping on functional vteps before bringing them down. Thanks, Gopi ________________________________ From: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com<mailto:vengg...@cisco.com>> Sent: Thursday, September 25, 2025 8:42:01 PM To: Rao P, Gopinatha <gopinatha.ra...@hpe.com<mailto:gopinatha.ra...@hpe.com>>; draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org> <draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org>> Subject: Re: Mail regarding draft-ietf-bess-evpn-bfd Hello Gopi, The previous paragraph to the one you highlight has some clarification in this matter. · At least one path of multi-path connectivity between two PE nodes MUST be tracked with BFD, but in that case the granularity of fault-detection will be coarser This is a trade-off that we need to make as the larger the number of sessions, the more resources it takes. We can discuss in a call if you think it helps. Thanks Prasad ________________________________ From: Rao P, Gopinatha <gopinatha.ra...@hpe.com<mailto:gopinatha.ra...@hpe.com>> Sent: Thursday, September 25, 2025 8:26 PM To: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com<mailto:vengg...@cisco.com>>; draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org> <draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org>> Subject: RE: Mail regarding draft-ietf-bess-evpn-bfd Hi Prasad, https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/#:~:text=By%20default%2C%20a,no%20longer%20available<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/*:*:text=By*20default*2C*20a,no*20longer*20available__;I34lJSUlJQ!!NpxR!jQ9kEKFJZ6EO_Ros9mdRywwrpohCc9HOBNpqwRqKk-ksM94kIQ8hPNMQ6mDyzWixEIy42IVZvOx865gh_NE$>. Once the required discriminator and unicast route is present BFD session is brought up. As this RFC is following RFC8971 encap mechanism, the VNI used for this BFD session will be that of what it received in BGP EVPN update. When this BFD session is brought down it can be just that VNI which might have encap/decap problem but rest of the other VNIs might be forwarding traffic as expected. This BFD down shouldn’t affect traffic on other VNIs by bringing the vxlan tunnel down. Either there has to be per VNI BFD session ( considering the scale) or single BFD session between the PEs but with the mechanism to ensure the BFD going down will not bring the vxlan tunnel where other VNIs might be just working fine. Thanks, Gopi From: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com<mailto:vengg...@cisco.com>> Sent: Thursday, September 25, 2025 7:47 PM To: Rao P, Gopinatha <gopinatha.ra...@hpe.com<mailto:gopinatha.ra...@hpe.com>>; draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org> Subject: Re: Mail regarding draft-ietf-bess-evpn-bfd Hello Gopi, Can you please share why there could be false positives? Thanks Prasad ________________________________ From: Rao P, Gopinatha <gopinatha.ra...@hpe.com<mailto:gopinatha.ra...@hpe.com>> Sent: Wednesday, September 24, 2025 11:54 PM To: draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org> <draft-ietf-bess-evpn-...@ietf.org<mailto:draft-ietf-bess-evpn-...@ietf.org>> Subject: Mail regarding draft-ietf-bess-evpn-bfd Hi Authors, Going by the vxlan EVPN encapsulation setup in Section 7.2 , the BFD session will operate on the VNI on which the route is received along with your_discriminator. Based on each VNI configuration a similar RT3 route would be coming in marking the vxlan vtep operational and wouldn’t that bulk up the number of BFD session between the same set of vteps? Is the idea to have only one EVPN BFD session running on the VNI on which the first RT3 was received with valid BFD your_discriminator ? With this there can be false positives which might mark the EVPN BFD Down if that particular VNI encap/decap fails but rest of VNIs are still functional? Thanks, Gopi
