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 +, bruno.decra...@orange.com wrote:
> Hi Job,
>
> Thanks for the feedback.
> More inline
>
> > From: Job Snijders [mailto:j...@ntt.net] > Sent: Wednesday, March 15, 2017
> > 3:54 PM
> >
> > Hi Bruno,
> >
> > On Wed, Mar 15, 2017 at 02:00:37PM +, bruno.decra...@orange.com wrote:
> > > > From: GROW [mailto:grow-boun...@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.
>
> "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 con
