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

I would be very happy with that outcome.
We've been using this for ages, and would like to see it work more widely in our adjacent networks.

Although not truly a fix for the transitivity problem, when we match on gshut from a peer, in addition to setting a lower-than-usual LP, we also append no-export, which prevents gshut-ed prefixes from leaking at all.
I've never been hugely worried about the security consequences otherwise.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:      benm@workonline.co.za
SIP:          benm@workonline.co.za

-----Original Message-----
From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Job Snijders
Sent: Wednesday, March 15, 2017 4:54 PM
To: bruno.decraene@orange.com
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?

Hi Bruno,

On Wed, Mar 15, 2017 at 02:00:37PM +0000, bruno.decraene@orange.com wrote:
> > From: GROW [mailto:grow-bounces@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