Hi Bruno, On Wed, Mar 15, 2017 at 02:00:37PM +0000, bruno.decra...@orange.com wrote: > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders > > > Sent: Wednesday, March 15, 2017 2:11 PM > > > > I noticed that https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06 > > expired two years ago. Can anyone offer some insight why it lapsed? > > In order to signal the graceful shutdown over the EBGP session, gshut > uses a "well-know" BGP community. Compared to using a protocol > extension, this allows a vanillia sender/receiver to handle the > information using a regular BGP policy. > So far so good. This is specified, implemented both with BGP policy > and automated by some routers, tested (both options). > > Now, for some deployments, the use of a non-transitive community offer > a better assurance that the community has indeed be originated by the > connected eBGP peer. The issue is that currently there is no > implementation of non-transitive well-known communities. > draft-ietf-idr-reserved-extended-communities is a short draft to > define non-transitive well-known communities. It proposed to re-use an > "existing" non-transitive extended community, defined for four-octets > AS: draft-ietf-idr-as4octet-extcomm-generic-subtype. But it turns out > that this latter draft did not progress and has recently been replaced > by BGP large community. The later do no support non-transitive > community. > > So after waiting for some years for > draft-ietf-idr-as4octet-extcomm-generic-subtype, this path has just > been closed. As of today, the possible options seems: > > - forget about non-transitive community. In particular as during the > BGP large community discussions, the requirement for non-transitive > community has been discussed and explicitly called as not needed. So > let's listen to this and do the same.
I'd like to add a small nuance: For the use case of large communities, non-transitivity was considered an undesirable property. To be honest, if the 'gshut' community 'escapes' the adjacent ASN for which it was intended, what is the worst that can happen? That BGP speakers somewhere in the DFZ consider the path less desirable? This aligns with what is expected to happen in the near future anyway: the bgp session will be torn down and the path will cease to exist. In the case where no shutdown event follows (the gshut community is used as a traffic engineering trick), it kind of goes in the same category as intermediat networks prepending ASNs to the AS_PATH to make it less desirable, or fiddling with origin. If I were to consider "permanent use" of the gshut community a violation of my agreement with the adjacent network, this would be easy enough to monitor for and subsequently resolve at layer-8. > - have draft-ietf-idr-reserved-extended-communities use a different > extended community type. This is easy to write, but if this does not > get implemented, the value is limited/null. I concur. A similar consideration could be made whether gshut deserves its own path attribute or not. Usually the nice thing about well known rfc 1997 communities is their rapid implementation and deployability. > > What implementatations exist? A fellow operator told me that IOS, > > IOS XE has support for graceful shutdown, are there others? > > Same information on my side. With the restriction that those > implementations only implement the transitive community. ack. I'm somewhat inclined to proceed with the gshut concept as a well-known transitive rfc 1997 community. What do others think? Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
