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

[Thomas King <[e-mail]>]

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" <[e-mail]> 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