Skip to main content

Early Review of draft-ietf-bess-evpn-bfd-07
review-ietf-bess-evpn-bfd-07-rtgdir-early-boucadair-2024-09-16-00

Request Review of draft-ietf-bess-evpn-bfd
Requested revision No specific revision (document currently at 08)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-10-04
Requested 2024-09-06
Requested by Matthew Bocci
Authors Vengada Prasad Govindan , Mallik Mudigonda, Ali Sajassi , Greg Mirsky , Donald E. Eastlake 3rd
I-D last updated 2024-09-16
Completed reviews Rtgdir Early review of -07 by Mohamed Boucadair (diff)
Assignment Reviewer Mohamed Boucadair
State Completed
Request Early review on draft-ietf-bess-evpn-bfd by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/VpVkRyvgwECH644ylvSeLsGjtrg
Reviewed revision 07 (document currently at 08)
Result Has issues
Completed 2024-09-16
review-ietf-bess-evpn-bfd-07-rtgdir-early-boucadair-2024-09-16-00
Hi authors,

Thanks for the effort put into this document.

Overall, the document reads well. The specification leverages existing
specifications with exceptions called out it in the document. This approach
seems reasonable, but there are some issues that need to be fixed. These are
highlighted in the detailed review (see below). A subset of them are
highlighted hereafter:

# Better position the document: For example, I failed to find this "network
layer" defined in RFC7432 or 7432bis. I think that you are referring to the
layering in 2.1 of 9062. For example, you can consider adding a sentence in the
introduction about 2.1 of 9062 to position the layer you are considering.

# 7432 or 7432bis: Any reason why the bis is cited explicitly here? Are there
parts of the spec that are not applicable to 7432? I don't think so, but it is
better clarify this in the doc rather than leaving the readers guess.

# "future versions of this document" vs "other documents": The document says in
several places that "It is intended to address this in future versions of this
document.". The intended scope should be clarified.

# Internal inconsistency:

## The document refers to TBD3 and cites Section 8, but there is no such
definition in the IANA section ## The document cites "dedicated unicast MAC"
and "dedicated multicast MAC" but these are not defined in the document.

## RFC 9026

Previous sections state that 9026 is not mandatory and other mechanisms can be
used. However, Section  This text seems to assume that it is always used:

"It also contains a BFD Discriminator
   Attribute [RFC9026] with BFD Mode TDB4 giving the BFD discriminator
   that will be used by the tail.
"

(note that s/TDB4/TBD2)

# Redundant requirements: For example, the document says

"   The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] and
   BFD for VXLAN [RFC8971] are, except as otherwise provided herein,
   applied to test loss of continuity for unicast EVPN traffic.
"
 but then

"   Once the BFD session is UP, the ends of the BFD session MUST NOT
   change the local discriminator values of the BFD Control packets they
   generate, unless they first bring down the session as specified in
   [RFC5884].
"

the intended behavior vs "local discriminator values" here is redundant with
this part in Section 7 of 5884:

"Note that once the BFD session for the MPLS LSP is UP, either end of the BFD
session MUST NOT change the source IP address and the local discriminator
values of the BFD Control packets it generates, unless it first brings down the
session."

No?

# Detailed review can be found here, fwiw:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc

Feel free to grab whatever you think useful.

Hope this helps.

Cheers,
Med