Hi Gopi, thank you for your questions and sharing scenarios that you have interest in. Please find my notes below tagged GIM>>.
Regards, Greg On Tue, Sep 23, 2025 at 1:02 PM Rao P, Gopinatha <gopinatha.rao-p= [email protected]> wrote: > 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. > > GIM>> Correct. As noted in the Introduction: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol to enable monitoring continuity of the path between VXLAN VTEPs that are performing as VNEs, and/or between the source NVE and a replicator MSN using a Management VXLAN Network Identifier (VNI) (Section 4). All other uses of the specification to test toward other VXLAN endpoints are out of scope. > > 1. If VNI 0 BFD session goes down it doesn’t indicate other VNIs are > failing to perform encap/decap right ? > > GIM>> I think that you refer to the management VNI. RFC 8971 recommends using VNI 1 as the default management VNI. To your question. Yes, that event doesn't indicate how other VNIs perform, but I believe that if the BFD session using Management VNI goes down, then the tunnel between BFD peers is down. If that is the case, the state of other VNIs seems unimportant, would you agree? > > 1. > > > > 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(?) > GIM>> As noted in Section 2 of RFC 8971: Using a BFD session to monitor a set of VXLAN VNIs between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration. An implementation that supports this specification MUST be able to control the number of BFD sessions that can be created between the same pair of VTEPs. > 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) > GIM>> The question of how known fault management methods can be used in concert seems like an operational question to me. I don't think that anything needs to be changed in BFD or ICMP. > > > 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 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/16/*:*:text=At*20the*20same,from*20data*20packets__;I34lJSUl!!NpxR!lJvv-ABogDlvIGojnMk7GWGBRhImGm6CRlXXyy0R_uIZGvh0E7FcP28zSWLxkca1UFar17qeuSThgwnbGZZ4zVNafSCElE7S0AI$> > . > > > > 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 > >
