[bess] Genart last call review of draft-ietf-bess-evpn-vpws-fxc-09

Joel Halpern via Datatracker <noreply@ietf.org> Sun, 29 September 2024 15:32 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172762395208.420076.6078924250689077440@dt-datatracker-7bbd96684-zjf54>
Date: Sun, 29 Sep 2024 08:32:32 -0700
Message-ID-Hash: 2PJXFMSL3DWWXDVJWCRJ3MOQMO3GARIO
CC: bess@ietf.org, draft-ietf-bess-evpn-vpws-fxc.all@ietf.org, last-call@ietf.org
Reply-To: Joel Halpern <jmh@joelhalpern.com>
Subject: [bess] Genart last call review of draft-ietf-bess-evpn-vpws-fxc-09
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ecmO28vsYoP8ra0vA2kToI71DdA>

Reviewer: Joel Halpern
Review result: Ready with Issues

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

[bess] Genart last call review of draft-ietf-bess… Joel Halpern via Datatracker