Skip to main content

Last Call Review of draft-ietf-grow-bgp-session-culling-04

Request Review of draft-ietf-grow-bgp-session-culling
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-09-25
Requested 2017-09-11
Authors Will Hargrave , Matt Griswold , Job Snijders , Nick Hilliard
I-D last updated 2017-09-18
Completed reviews Rtgdir Last Call review of -04 by Stig Venaas (diff)
Genart Last Call review of -04 by Brian E. Carpenter (diff)
Secdir Last Call review of -04 by Paul Wouters (diff)
Genart Telechat review of -05 by Brian E. Carpenter
Assignment Reviewer Brian E. Carpenter
State Completed
Request Last Call review on draft-ietf-grow-bgp-session-culling by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 05)
Result Ready w/issues
Completed 2017-09-18
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

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?