Re: [GROW] Genart last call review of draft-ietf-grow-bgp-session-culling-04

[Matt Griswold <[e-mail]>]

* Brian Carpenter <[e-mail]> [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!