[GROW] draft-ietf-grow-bgp-session-culling next steps

[Job Snijders <[e-mail]>]

Hi GROW,

I've compiled a todo list to outline the next steps for the
draft-ietf-grow-bgp-session-culling document.

IXP Community feedback (possible action for Thomas, Yuya)
---------------------------------------------------------

After the initial version of this Internet-Draft was published, a few
IXPs have expressed interest in implementing the 'involuntary culling'
mechanism to reduce the negative impact of maintenance on their
platform. I hope we'll receive feedback from them on the readability and
structure of the document. As was stated before there are a number of
IXPs which have already implemented the mechanism, but they did that
before this document existed, I think feedback from new users will be
very valuable, so I'd like to try and collect some of that.

To shut or not to shut (possible action for Jen)
------------------------------------------------

Jen Linkova wanted to add text to offer an alternative to
administratively shutting down EBGP sessions: she advocated to withdraw
all routes & stop using received routes. Conceptually this would align
with simply removing policies associated with a EBGP peer before
commencing maintenance if the platform supports
draft-ietf-grow-bgp-reject.

While I look forward to a text proposal, I'm not sure if this should be
part of the BCP: the operator lacks visibility of the maintenance event
in their syslog (most implementions won't log that all routes were
withdrawn), and it precludes the use of draft-ietf-idr-shutdown to
inform others on what is going on.

Or perhaps this is a subjective matter driven by local considerations
and we should describe both approaches. If we describe both:

    o how do we facilitate a newcomer reading the document, how to
      decide which of the two to use?

    o What terminology would we use to contrast from "Voluntary BGP
      Session Teardown"?

    o if you choose a deny-import/deny-export approach, shouldn't you
      ideally start with a gshut 65535:0 approach and subsequently
      withdraw, to prevent hyper local blackholing?

    o What do other operators think about deny-import/deny-export rather
      then shutting?

So... should this I-D include the method at all?

We can also accept that the BCP is to administratively shut, but that
some operators will have their own methods.

BGP g-shut (possible action for Bruno et al)
--------------------------------------------

Bruno promised a new, fresh version of draft-ietf-grow-bgp-gshut which
would focus on the rfc1997 well-known community 65535:0 - I would
appreciate if this is posted at some point so we can make an Informative
reference to a non-zombie draft.  NTT (as2914) & Coloclue (as8283)
implemented experimental rfc1997 gshut support for customers and it
appears to work as advertise (no pun intended ;-).

Add examples for more platforms (everyone)
------------------------------------------

We're tracking examples of culling configs in this repository
https://github.com/bgp/bgp-session-culling-config-examples - if you see
a missing implementation and know how to configure involuntary culling,
please consider adding an example through a pull-request or an email to
the authors. Thanks!

Kind regards,

Job