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