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

[Job Snijders <[e-mail]>]

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, [e-mail] wrote:
> Hi Job,
> 
> Thanks for the feedback.
> More inline
> 
> > From: Job Snijders [mailto:[e-mail]]  > Sent: Wednesday, March 15, 2017 3:54 PM
> > 
>  > 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.
> 
> "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