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.
Thanks,
Gopi
From: Vengada Prasad Govindan (venggovi) <[email protected]>
Sent: Wednesday, October 29, 2025 3:51 AM
To: Rao P, Gopinatha <[email protected]>; Alexander Vainshtein
<[email protected]>; Greg Mirsky
<[email protected]>
Cc: [email protected]; [email protected]; BFD WG <[email protected]>
Subject: Re: Mail regarding draft-ietf-bess-evpn-bfd
Hello Gopi,
Please see notes below (See GVP1) this is mandated by RFC5880
Thanks
Prasad
________________________________
From: Rao P, Gopinatha <[email protected]<mailto:[email protected]>>
Sent: Thursday, October 23, 2025 9:42 PM
To: Alexander Vainshtein
<[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]>>;
[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
Thanks Sasha for clarification.
Will wait for comment from authors as well on the same and also for #3 whether
it should stay as MUST.
Thanks,
Gopi
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, October 21, 2025 11:56 AM
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,
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.
GVP1> Exactly. This is why it is a MUST. Also please note that there are two
choices for the discriminator allocation
Regards,
Sasha
From: Rao P, Gopinatha
<[email protected]<mailto:[email protected]>>
Sent: Thursday, October 16, 2025 7:47 AM
To: Alexander Vainshtein
<[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: [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]
