Dear working group, > > 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 ;-). > > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-07 has just been posted > and addresses the above point. > > As previously discussed on the list, the main technical change is the > focus, for the eBGP signaling, on the use of a well-known BGP > community. In other word, the alternative option to use a > non-transitive community has been removed, following latest IDR > discussion on community and the lack of implementation (hence IDR WG > progress) of draft-ietf-idr-reserved-extended-communities / > draft.ietf-idr-as4octet-extcomm-generic-subtype. As a benefit, this > draft is now aligned with: - the BGP gshut/planned maintenance > implementations disclosed on this list > https://mailarchive.ietf.org/arch/msg/grow/ReJtavkJDlyrDo5qoD7u9iJDLXs > - the deployed usage
fantastic! I have some comments: Summary: I think that the neighbor ASBR should _not_ strip the GSHUT well-known community, additionally, the place where the low local preference is set should move closer to the initiator of the gshut. Instead of setting the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set during application of the local policy on the relevant Adj-RIB-In. The above changes would align with current operational practises, i've learned from numerous people that they use AS-specific "lower LOCAL_PREF as low as possible" communities from their peers and upstream providers to trigger path hunting. In current deployments those communities are often not stripped (in context of IBGP), and the lower LOCAL_PREF is set on "ebgp-in" rather then "ibgp-out". Optionally an appendix with an actual router configuration can be supplied, if there is interest in this I am happy to provide that. ----- Suggestions: OLD Abstract: This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. NEW Abstract: This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. Additionally this document describes the use of a well-known Border Gateway Protocol (BGP) community to signal that a graceful shutdown has been initiated for the tagged prefix. OLD (in introduction): Still, it explains why reserving a community value for the purpose of BGP session graceful shutdown would reduce the management overhead bound with the solution. It would also allow vendors to provide an automatic graceful shutdown mechanism that does not require any router reconfiguration at maintenance time. NEW (in introduction): This document defines a well-known community value for the purpose of reducing the management overhead of gracefully shutting down BGP sessions. The well-known community allows implementers to provide an automated graceful shutdown mechanism that does not require any router reconfiguration at maintenance time. OLD (in Make before break convergence: g-shut): This section describes configurations and actions to be performed for the graceful shutdown of eBGP sessions, iBGP sessions or a whole BGP speaker. NEW: This section describes configurations and actions to be performed for the graceful shutdown of BGP sessions. OLD (in Pre-configuration): On each ASBR supporting the g-shut procedure, an outbound BGP route policy is applied on all iBGP sessions of the ASBR, that: o matches the g-shut community o sets the LOCAL_PREF attribute of the paths tagged with the g-shut community to a low value o removes the g-shut community from the paths. o optionally, adds an AS specific g-shut community on these paths to indicate that these are to be withdrawn soon. If some ingress ASBRs reset the LOCAL_PREF attribute, this AS specific g-shut community will be used to override other LOCAL_PREF preference changes. NEW (in Pre-configuration): On each ASBR supporting the g-shut procedure, an inbound BGP route policy is applied on all BGP sessions of the ASBR, that: o matches the g-shut community o sets the LOCAL_PREF attribute of the paths tagged with the g-shut community to a low value (a value of zero is recommended). OLD (in Operations at maintenance time): On the g-shut initiator, upon maintenance time, it is required to: o apply an outbound BGP route policy on the maintained eBGP session to tag the paths propagated over the session with the g-shut community. This will trigger the BGP implementation to re- advertise all active routes previously advertised, and tag them with the g-shut community. o apply an inbound BGP route policy on the maintained eBGP session to tag the paths received over the session with the g-shut community. o wait for convergence to happen. o perform a BGP session shutdown. NEW (in Operations at maintenance time): On the g-shut initiator, upon maintenance time, it is required to: o apply an outbound BGP route policy on the maintained EBGP session to tag the paths propagated over the session with the g-shut community. This will trigger the BGP implementation to re- advertise all active routes previously advertised, and tag them with the g-shut community. o apply an inbound BGP route policy on the maintained EBGP session to tag the paths received over the session with the g-shut community and set a low LOCAL_PREF value. o wait for convergence to happen. o shutdown the EBGP session, optionally using [RFC-To-Be draft-ietf-idr-shutdown] to signal the reason of the shutdown. OLD (in BGP implementation support for g-Shut): 1. On the eBGP side, update all the paths propagated over the corresponding eBGP session, tagging the g-shut community to them. Any subsequent update sent to the session being gracefully shut down would be tagged with the g-shut community. 2. On the iBGP side, lower the LOCAL_PREF value of the paths received over the eBGP session being shut down, upon their propagation over iBGP sessions. Optionally, also tag these paths with an AS specific g-shut community. NEW (in BGP implementation support for g-Shut): 1. On the EBGP side, update all the paths propagated over the corresponding eBGP session, tagging the g-shut community to them. Any subsequent update sent to the session being gracefully shut down would be tagged with the g-shut community. 2. lower the LOCAL_PREF value of the paths received over the EBGP session being shut down. OLD: 7. IANA assigned g-shut BGP community Applying the g-shut procedure is rendered much easier with the use of a single g-shut BGP community value [RFC1997] which could be used on all eBGP sessions, for both inbound and outbound signaling. The community value 0xFFFF0000 has been assigned by IANA for this purpose. 8. IANA Considerations This document has no actions for IANA. NEW: 7. IANA Considerations The IANA has assigned the value 0xFFFF0000 to the planned-shut community in the "BGP Well-known Communities" registry. IANA is requested to change the name planned-shut to GRACEFUL_SHUTDOWN. ------ Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow