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

[Brian E Carpenter <[e-mail]>]

On 21/09/2017 12:13, Matt Griswold wrote:
> * 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.

Understood, so perhaps it's a MAY not a SHOULD, but the text still
really only seems to say "do the right thing" without saying what
that is. To be honest the whole document is a bit like that - written
for members of the club who know how to run BGP, rather than for a
newcomer who wants to know how to run BGP.

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

Again: not clear to a newcomer. 

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

Yes, I realise that, but again you're assuming that the reader has
a complete picture in her mind. Maybe there's actually a need for
a scenario description in the Introduction, or at least a reminder
that in normal operation, paths through the fabric in question may be
known throughout the BGP realm, and the objective is to delete
those paths before starting maintenance.

> Thanks for your review!

You're welcome,
    Brian