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

[Nick Hilliard]

Dale R. Worley wrote:
> Section 3.1.1 seems to be uniquely short.  I would favor adding a list
> of the "multiple ways an Operator can accomplish that."  Even just
> listing the *names* of the methods that might be used is a useful guide
> -- a novice operator can use search engines to find tutorial information
> regarding the various methods.

Hi Dale,

At an IXP, it's fine for a client network operator to voluntarily shut
down their bgp sessions, as noted in section 3.1, and let traffic drain
off an interface.  This is the standard operational practice.

Graceful shutdown and Shutdown Communication could be used, but they're
new and are arguably overkill in many situations because for the most
part, network flaps are a part of life and people aren't interested in
what's going on in other peoples' networks unless it affects their own.

The point of the ID is that it's about session culling / involuntary
session drops initiated by the IXP Caretaker, and I think we need to
stay on topic in the draft, rather than get bogged down in tangential stuff.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Dale R. Worley]

Matt Griswold  writes:
>> >>> 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?

Section 3.1.1 seems to be uniquely short.  I would favor adding a list
of the "multiple ways an Operator can accomplish that."  Even just
listing the *names* of the methods that might be used is a useful guide
-- a novice operator can use search engines to find tutorial information
regarding the various methods.

Dale

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow