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