Re: [GROW] draft-ietf-grow-bgp-gshut

[Job Snijders <[e-mail]>]

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