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

[Job Snijders <[e-mail]>]

Hi Bruno,

On Wed, Mar 15, 2017 at 02:00:37PM +0000, [e-mail] wrote:
> > From: GROW [mailto:[e-mail]] 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