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

[<[e-mail]>]

Hi Job,

Thanks for the comments.
Please see inline [Bruno]

> From: Job Snijders [mailto:[e-mail]]
 > Sent: Thursday, June 22, 2017 10:47 PM
> 
 > 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.

[Bruno] Will answer these technical points in separate threads.

 > 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.
 
[Bruno] I think this would be useful. (although CLI change over time)
 
 > -----
 > 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.
 
[Bruno] OK. Slightly reworded as "It defines a well-known BGP community, called gshut, to signal the graceful shutdown of paths to other Autonomous Systems."
 
 > 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.

[Bruno] OK.

 
 > 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.
 
[Bruno] OK.

 
 > 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).
 
[Bruno] Change delayed, as related to the 2 technical points to be discussed in separate threads.
 
 > 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.
 
[Bruno] Change delayed, as related to the 2 technical points to be discussed in separate threads.
Added text related to ID-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.
 
[Bruno] Change delayed, as related to the 2 technical points to be discussed in separate threads.
 
 > 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.

[Bruno] OK. except that in this document, the name "g-shut" is used. (rather than GRACEFUL_SHUTDOWN). So using the name g-shut.

Kind regards,
--Bruno
 > ------
 > 
 > Kind regards,
 > 
 > Job

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.