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]> 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]> > *Sent:* Thursday, September 25, 2025 9:03 PM > *To:* Vengada Prasad Govindan (venggovi) <[email protected]>; > [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]> > *Sent:* Thursday, September 25, 2025 8:42:01 PM > *To:* Rao P, Gopinatha <[email protected]>; > [email protected] <[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]> > *Sent:* Thursday, September 25, 2025 8:26 PM > *To:* Vengada Prasad Govindan (venggovi) <[email protected]>; > [email protected] <[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]> > *Sent:* Thursday, September 25, 2025 7:47 PM > *To:* Rao P, Gopinatha <[email protected]>; > [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]> > *Sent:* Wednesday, September 24, 2025 11:54 PM > *To:* [email protected] <[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 >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
