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