Gopi and all, It seems that there are quite a few things in this draft that are specific to EVPN-VxLAN but could not be extended to EVPN-MPLS.
I wonder if the same applies to EVPN-SRv6. Regards, Sasha From: Rao P, Gopinatha <[email protected]> Sent: Tuesday, November 4, 2025 10:14 AM To: Alexander Vainshtein <[email protected]>; Jeffrey Haas <[email protected]> Cc: Vengada Prasad Govindan (venggovi) <[email protected]>; Greg Mirsky <[email protected]>; [email protected]; [email protected]; BFD WG <[email protected]> Subject: [EXTERNAL] RE: Re: Mail regarding draft-ietf-bess-evpn-bfd Thanks Jeffrey for the comments. For Vxlan EVPN BFD the below discovery mechanism should still be valid which is applicable for GENEVE BFD. Authors can confirm the same. https://datatracker.ietf.org/doc/rfc9521/#:~:text=If%20the%20BFD%20packet%20is,MAC%2C%20and%20the%20destination%20IP<https://datatracker.ietf.org/doc/rfc9521/#:~:text=If%20the%20BFD%20packet%20is,MAC%2C%20and%20the%20destination%20IP> If the BFD packet is received with the value of the Your Discriminator field set to 0, then the BFD session SHOULD be identified using the VNI number and the inner Ethernet/IP header. The inner Ethernet/IP header stands for the source MAC, the source IP, the destination MAC, and the destination IP Thanks, Gopi From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Sent: Sunday, November 2, 2025 1:05 PM To: Jeffrey Haas <[email protected]<mailto:[email protected]>> Cc: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; Greg Mirsky <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; BFD WG <[email protected]<mailto:[email protected]>>; Rao P, Gopinatha <[email protected]<mailto:[email protected]>> Subject: RE: [EXTERNAL] Re: Mail regarding draft-ietf-bess-evpn-bfd Importance: High Jeffrey, Lots of thanks for your email. Can you please comment also on proposed usage of Destination UDP Port 3784 (reserved for single-hop IP BFD control packets in RFC 5881) in encapsulation of the EVPN-BFD Control packets? Regards, Sasha From: Jeffrey Haas <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 29, 2025 7:59 PM To: Rao P, Gopinatha <[email protected]<mailto:[email protected]>> Cc: Vengada Prasad Govindan (venggovi) <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>>; Greg Mirsky <[email protected]<mailto:[email protected]>>; [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 Note that I'm behind in this thread, but wanted to make comment on the specifically raised point: On Oct 29, 2025, at 11:33 AM, Rao P, Gopinatha <[email protected]<mailto:[email protected]>> wrote: Hi Venkat, From RFC 5880: “If the Your Discriminator field is zero, the session MUST be selected based on some combination of other fields, possibly including source addressing information, the My Discriminator field, and the interface over which the packet was received. The exact method of selection is application specific and is thus outside the scope of this specification. If a matching session is not found, a new session MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification.” When the remote PE sends a DOWN packet to begin with, your_discriminator can be 0 and the incoming BFD packet can be demuxed based on the VNI(and other parameters) on which the packet is coming in on ? RFC 5880 doesn’t mandate the incoming DOWN packet should come in with your_discriminator set to non-zero value. It clearly says what needs to be done when your_discriminator field to set to 0. The followup on this is that if you're getting such a 0 discriminator, the idea is that you have other mechanisms to determine how to associate these packets with a BFD session. The typical simple example is for single-hop BFD you can see what interface and IP address things are coming in as. RFC 5882 for multihop both acknowledges use cases like demultiplexing based on IP, but also that sometimes you need to learn this out of band. The question for the draft authors and the BESS WG is whether there's alternative means that such a EVPN BFD session could use to associate incoming packets to its session? If no, then a "MUST" for discovered (by BGP) or provisioned is reasonable. Clarifying that this is required since there's no alternative discovery mechanism available might address the raised point. -- Jeff 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]
