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

Hi Job, GROW

> From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Job Snijders  > Sent: Wednesday, March 15, 2017 2:11 PM
> 
 > Hi group,
 > 
 > 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.
- 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. 

 > 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.

Kind regards,
--Bruno

 > Kind regards,
 > 
 > Job
 > 
 > _______________________________________________
 > GROW mailing list
 > GROW@ietf.org
 > https://www.ietf.org/mailman/listinfo/grow

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.