* Brian Carpenter <[email protected]> [170918 21:44 -0700]: > 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.
Graceful Shutdown is just one of multiple ways an Operator can accomplish that. > > 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...". Fixed! > 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? The Caretaker controls the layer 2 network, so yes, would do this as part of the maintenance process. > ... > > 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. Added. > > 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". Removed "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? They are the IXP LAN addresses, as explained above the examples. Thanks for your review! _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
