[Gen-art] Genart last call review of draft-ietf-grow-bgp-session-culling-04

Brian Carpenter <brian.e.carpenter@gmail.com> Tue, 19 September 2017 04:44 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA44E1342C0; Mon, 18 Sep 2017 21:44:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Carpenter <brian.e.carpenter@gmail.com>
To: gen-art@ietf.org
Cc: grow@ietf.org, draft-ietf-grow-bgp-session-culling.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150579629891.15651.17244647188709040958@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 21:44:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/XKDyjuUlp7S0E3_d4eQwd00wGdo>
Subject: [Gen-art] Genart last call review of draft-ietf-grow-bgp-session-culling-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2017 04:44:59 -0000

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-grow-bgp-session-culling-04

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-grow-bgp-session-culling-04.txt
Reviewer: Brian Carpenter
Review Date: 2017-09-19
IETF LC End Date: 2017-09-25
IESG Telechat date: 

Summary: Ready with issues
--------

Minor Issues:
-------------

> 3.1.1.  Maintenance Considerations
>
>  Initiators of the administrative shutdown could consider using
>  Graceful Shutdown [I-D.ietf-grow-bgp-gshut] to facilitate smooth
>  drainage of traffic prior to session tear down, and the Shutdown
>  Communication [I-D.ietf-idr-shutdown]...

This strikes me as vague. "Could consider"? Surely if this is
a BCP, they MUST use some mechanisms and perhaps SHOULD use these
particular mechanisms. Otherwise the document doesn't specify
anything much at all for this case.

> 3.2.  Involuntary BGP Session Teardown Recommendations
...
>  In the absence notifications from the lower layer (e.g. ethernet link
>  down) consistent with the planned maintenance activities in a
>  switched layer-2 fabric, the Caretaker of the fabric could choose to
>  cull BGP sessions on behalf of the Operators connected to the fabric.

This seems incomplete. Firstly, I'm assuming that it should start
"In the absence of notifications...". Secondly, if there are no
fault indications, what causes the Caretaker to cull sessions?
What's the trigger? Is the Caretaker supposed to know by magic
that layer 2 maintenance is planned?
...
>  In this scenario, BGP Session Culling is accomplished through the
>  application of a combined layer-3 and layer-4 packet filter deployed
>  in the switched fabric itself.

Please add "as described in the next sub-section" because otherwise
the reader can easily be confused.

> 3.2.1.  Packet Filter Considerations
>
>  The following considerations apply to the packet filter design:
>
>  o  The packet filter MUST only affect BGP traffic specific to the
>     layer-2 fabric, i.e. forming part of the control plane of the
>     system described, rather than multihop BGP traffic which merely
>     transits

That's a goal, but it doesn't tell me how to achieve the goal.
What packet signature tells me which packets are specific to the
fabric? I suspect this might overlap with the last bullet - if so,
you might consider re-ordering the bullets.
...
>  o  The packet filter MUST affect all relevant Address Family
>     Identifiers

Define "relevant". And in Appendix A, explain precisely how
the example prefixes are used: what makes them relevant? Are they
normally announced by BGP to all the IXP's BGP peers?

--