Hi,
I took a look at the doc mostly from a BFD perpective.
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.If not all paths are tracked, is it coarser or is it incomplete (a path
failure might not be detected)?
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.s/with a BFD discriminator/with a BFD local discriminator/?Then the last
part "to be used as Your Discriminator..." wouldn't be needed.
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.If the BFD Discriminator attribute is advertised in a
route R1 and that route R1 is withdrawn, how is that handled? There could be
other routes R2, R3 etc which haven't advertised the discriminator. Is the
discriminator also "withdrawn"?If the discriminator has been advertised by
other routes (which haven't ben withdrawn) no change to the discriminator.
The BFD session is brought down if a PE node is no longer configured to
maintain it or if a route and discriminator are no longer available."No
longer configured" should lead to the BFD session to be removed instead of
"brought down"?
I saw the thread on per VNI BFD session v/s single BFD session, I think that
deserves an operational considerations section.
Regards,Reshad.
On Wednesday, October 15, 2025 at 11:16:39 AM EDT, Matthew Bocci (Nokia)
<[email protected]> wrote:
Hello Working Group,
This email starts a Working Group Last Call for draft-ietf-bess-evpn-bfd-12
(draft-ietf-bess-evpn-bfd-12 - EVPN Network Layer Fault Management).
Please review the draft and post any comments to the BESS list, and whether or
not you support progressing with publication of this draft as a standards track
RFC.
This WG LC notice has also been CC’d to the BFD working group list. BFD
participants: please can you respond to the BESS WG list as this will greatly
help in judging consensus.
This poll runs until 31st October 2025.
We are also polling for knowledge of any undisclosed IPR that applies to this
document, to ensure that IPR has been disclosed in compliance with IETF IPR
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please
respond to this email and indicate if you are aware of any relevant undisclosed
IPR.
There is no IPR currently disclosed.
If you are not listed as an Author or a Contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.
We are also polling for any existing implementations as per [bess] Conclusion
on the "one implementation policy". Please reply to this email or directly to
the BESS chairs if you are aware of any implementations of the draft.
Best regards
Matthew (on behalf of the BESS chairs).
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
