Gopi, Apologies for a delayed response. I think that my response dealt with your #2 in the case of EVPN-MPLS. My guess is that the same answer should be equally applicable to EVPN-VxLAN, but I defer to people with better experience in this application.
As for reservation of discriminators (your #3): Please note that per RFC 5880, BFD Control Packets MUST be demuxed based solely on the received Your Discriminator value. Regards, Sasha From: Rao P, Gopinatha <[email protected]> Sent: Thursday, October 16, 2025 7:47 AM To: Alexander Vainshtein <[email protected]>; Greg Mirsky <[email protected]>; Vengada Prasad Govindan (venggovi) <[email protected]> Cc: [email protected]; [email protected]; BFD WG <[email protected]> Subject: [EXTERNAL] RE: Mail regarding draft-ietf-bess-evpn-bfd Thanks Sasha for your comments on point1. Any comments on points 2&3 ? For a P2P vxlan use-case why is it a MUST to have your_discriminator reserved on peer PE ? Reserving my_discriminator is not good enough as it will follow RFC5880 ? Thanks, Gopi From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Sent: Sunday, October 12, 2025 6:45 PM To: Rao P, Gopinatha <[email protected]<mailto:[email protected]>>; Greg Mirsky <[email protected]<mailto:[email protected]>>; Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; BFD WG <[email protected]<mailto:[email protected]>> Subject: RE: Mail regarding draft-ietf-bess-evpn-bfd Gopi, Greg andi all, Please note that the latest (-12) version of the draft explicitly leaves any service layer handling of failure of EVPN BFD sessions out of scope. The only required action is reporting of an alarm to management systems. The draft also explains (in Appendix A<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-12*appendix-A__;Iw!!NpxR!mXA7nRDecTGoQ9t8W-8Ke5ZrhTgrC0XF7B6-8wbJN11lZzJj5zfj72jeyli4LS77UAkzkmv_MfUoEYEck66fHFbs4wrYAsiNI9E$>) that such handling (e.g., recovery of failed traffic) could be highly non-trivial, My 2c, Sasha From: Rao P, Gopinatha <[email protected]<mailto:[email protected]>> Sent: Friday, October 10, 2025 8:24 AM To: Greg Mirsky <[email protected]<mailto:[email protected]>>; Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; BFD WG <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] RE: Mail regarding draft-ietf-bess-evpn-bfd Hi, Any thoughts on the below points? Thanks, Gopi From: Rao P, Gopinatha Sent: Monday, October 6, 2025 10:57 AM To: 'Greg Mirsky' <[email protected]<mailto:[email protected]>> Cc: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; BFD WG <[email protected]<mailto:[email protected]>> Subject: RE: Mail regarding draft-ietf-bess-evpn-bfd Hi Mirsky, Below are few points which needs clarification 1. Clarification on scale vs reliability , that was the purpose of the below text. It can be left to implementation but as there will always be a question of how to scale sessions on per VNI basis thought this clarification would help. 2. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/#:~:text=Data%20is%20not%20sent%20over%20the%20EVPN%20route%20until%20the%20BFD%20session%20or%0A%20%20%20sessions%20are%20in%20the%20UP%20state<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/*:*:text=Data*20is*20not*20sent*20over*20the*20EVPN*20route*20until*20the*20BFD*20session*20or*0A*20*20*20sessions*20are*20in*20the*20UP*20state__;I34lJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NpxR!mXA7nRDecTGoQ9t8W-8Ke5ZrhTgrC0XF7B6-8wbJN11lZzJj5zfj72jeyli4LS77UAkzkmv_MfUoEYEck66fHFbs4wrYkg71_Mg$> “Data is not sent over the EVPN route until the BFD session or sessions are in the UP state.” This is not a MUST but can this be made as MAY so it is read as traffic can flow even before BFD session is UP ? 3. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/#:~:text=To%20support%20unicast,least%20one%20route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/12/*:*:text=To*20support*20unicast,least*20one*20route__;I34lJSUl!!NpxR!kqITpGuHxPIbR6HZCKkALGD80MU42JVZTq4dRP0x8GPrZJPIIo5O75vWwX2hpF-5LISeLBKnRYth9pPsX0w$>. “To support unicast fault management with BFD packets sent to a PE node, that PE node MUST allocate or be configured with a BFD discriminator to be used as Your Discriminator (Section 4.1 of [RFC5880]) in the BFD messages to it. By default, a PE node advertises this discriminator with BGP using the BFD Discriminator Attribute [RFC9026] with BFD Mode TBD2 in an EVPN Ethernet Autodiscovery Route [rfc7432bis] or MAC/IP Advertisement Route as long as it advertises it in at least one route. It extracts its peer's discriminator from such an attribute. However, these discriminators MAY be exchanged out-of-band or through some other mechanism outside the scope of this document.” For a Vxlan BFD session on a given VNI why should the peer PE MUST reserve your_discriminator ? BFD can still come up on a given VNI when BFD packets flow between P2P and gets demuxed based on VNI/src_ip/dst_ip . Is this a MAY instead of MUST ? Do share your thoughts. Thanks, Gopi From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Saturday, September 27, 2025 10:37 PM To: Rao P, Gopinatha <[email protected]<mailto:[email protected]>> Cc: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; BFD WG <[email protected]<mailto:[email protected]>> Subject: Re: Mail regarding draft-ietf-bess-evpn-bfd Hi Rao, What is the purpose of the proposed text? The interpretation of the transition of a BFD session to the Down state and how applications that are clients of the BFD session fall outside the scope of all specifications, as this is an operational issue, i.e., a matter of implementation rather than standardization. Regards, Greg On Fri, Sep 26, 2025 at 9:50 AM Rao P, Gopinatha <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, September 25, 2025 9:03 PM To: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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) <[email protected]<mailto:[email protected]>> Sent: Thursday, September 25, 2025 8:42:01 PM To: Rao P, Gopinatha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, September 25, 2025 8:26 PM To: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> Sent: Thursday, September 25, 2025 7:47 PM To: Rao P, Gopinatha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Sent: Wednesday, September 24, 2025 11:54 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
