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

[Matt Griswold <[e-mail]>]

* Brian E Carpenter <[e-mail]> [170921 14:19 +1200]:
> 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

You're right, I will update it to MAY.

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

That's really by design, the document is for people who know and run
BGP, I think putting too much basic BGP knowledge would make it
monotonous. Any ideas on how to meet in the middle?

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

The updated language is:

  Throughout this document the "Caretaker" is defined to be in control
  of the lower layer network, while "Operators" directly administrate
  the BGP speakers.

I think that clears it up?

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

Again, that section is for IXP Caretakers so I don't think we need to
go into IXP operational details too much. Adding a brief scenario
paragraph should work, I'll write something up.

Thanks