Dear Bruno, other gshut authors & GROW, If you'd like help editing draft-ietf-grow-bgp-gshut-06 to reflect the proposed changes discussed in the last 3 months in GROW, I'd be happy to help. I have ed the standard editor installed and ready to go.
Kind regards, Job On Wed, Mar 15, 2017 at 03:21:18PM +0000, [email protected] wrote: > Hi Job, > > Thanks for the feedback. > More inline > > > From: Job Snijders [mailto:[email protected]] > Sent: Wednesday, March 15, 2017 > > 3:54 PM > > > > Hi Bruno, > > > > On Wed, Mar 15, 2017 at 02:00:37PM +0000, [email protected] wrote: > > > > From: GROW [mailto:[email protected]] 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. > > "undesirable property" is a bit beyond the term that I would use, but who > cares now; it's not part of it. > > > 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. > > In sync. In particular in sync with the security considerations of the draft > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06#section-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. > > Indeed. That was specifically important for the VPN customers, with 1000s of > CE, some with "legacy" software which are difficult to upgrade. So the > possibility to use a vanilla CE with a BGP policy was part of the > requirements. This may be less of an issue for big SP routers, although > incremental deployment is always a plus, especially when more than one AS are > involved. > > > > > 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? > > I agree with you. > Until now, in order to capture all the options, waiting for > draft-ietf-idr-as4octet-extcomm-generic-subtype seemed reasonable (at the > cost of waiting for years, but this was not expected as we though vendors > would implement it to accommodate 4-octects AS deployments). It's not > anymore, so I guess we'll update the draft to follow this proposed path. > > Thanks, > Kind regards, > --Bruno > > > Kind regards, > > > > Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
