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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
