Hi all, here is the summary of DE-CIX Tech Meeting [0] where I presented the BGP Session Culling approach [1]: The attendees appreciate the BGP session culling process as such and also the standardization of the maintenance procedures of different IXPs that will hopefully follow. The attendees also stressed the fact that involuntary BGP session culling applied by the IXP operator during maintenance must only apply to BGP sessions within the IXP LAN (= source and destination IP addresses of the BGP session are within the IXP LAN). So, other BGP sessions should not be affected (e.g. BGP Multihop sessions). This is already covered in section 3.2.1 of the Internet Draft.
DE-CIX is currently evaluating how involuntary BGP session culling can be implemented. If this is doable with our hardware we are planning to implement it. Best regards, Thomas [0]: https://de-cix.net/en/news-events/events/de-cix-technical-meeting [1]: https://de-cix.net/_Resources/Persistent/e307a1b2a99d979eb21ae590e7793a4c7a45c0ac/Thomas%20King%20-%20BGP%20Session%20Culling.pdf On 26.05.17, 16:05, "Job Snijders" <j...@ntt.net> wrote: 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
