On 21/09/2017 12:13, Matt Griswold wrote:
> * Brian Carpenter <brian.e.carpen...@gmail.com> [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
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
