Last Call Review of draft-ietf-bess-evpn-vpws-fxc-09
review-ietf-bess-evpn-vpws-fxc-09-genart-lc-halpern-2024-09-29-00
Request | Review of | draft-ietf-bess-evpn-vpws-fxc |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2024-10-04 | |
Requested | 2024-09-20 | |
Authors | Ali Sajassi , Patrice Brissette , Jim Uttaro , John Drake , Sami Boutros , Jorge Rabadan | |
I-D last updated | 2024-09-29 | |
Completed reviews |
Rtgdir Last Call review of -07
by Gyan Mishra
(diff)
Opsdir Last Call review of -09 by Qin Wu Genart Last Call review of -09 by Joel M. Halpern |
|
Assignment | Reviewer | Joel M. Halpern |
State | Completed | |
Request | Last Call review on draft-ietf-bess-evpn-vpws-fxc by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/yLsgTmXyL07mbeQWE3ounVmIqYU | |
Reviewed revision | 09 | |
Result | Ready w/issues | |
Completed | 2024-09-29 |
review-ietf-bess-evpn-vpws-fxc-09-genart-lc-halpern-2024-09-29-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-bess-evpn-vpws-fxc-09 Reviewer: Joel Halpern Review Date: 2024-09-29 IETF LC End Date: 2024-10-04 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: I found the description of the motivation in the introduction slightly misleading. It talks about the number of access circuits (ACs). Which is clearly where it needs to start. It would help if the text were clear about what level of aggregation is supported, and what ration of ACs this provides. The text in the introduction seems to imply aggregation across PEs, while the definition of VPWWS Service Tunnel seems to be for a single PE. Note that if it is aggregating across PEs, this should be called out explicitly early, as the naive reader will assume that aggregation in the default case is within a PE. I think the following is a minor issue. However, if I have misunderstood the draft, that suggests the issue may be more significant. As I read the draft, the scaling benefit is a reduction in the number of service labels needed, but not a reduction in the number of BGP advertisements required. If so, the introduction should make that clear. And probably call out the implication that these cases will still have a LOT of BGP advertisements. If I have misunderstood the benefit, we should probably correspond so that I can understand how this works and then suggest a text revision to make it clear. (I think 3.3 paragraph 3 says that I have understood the draft, which is why I consider this a minor issue.) Nits/editorial comments: N/A