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? --