Skip to main content

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