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

[<[e-mail]>]

Hi Job,

> From: Job Snijders [mailto:[e-mail]]  > Sent: Tuesday, June 13, 2017 1:41 AM
> 
 > 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.

Thanks for asking.
Over the last 2 months, I'm been delaying this update, taken by others tasks.
As of today, change seems relatively modest to me and ready. The current delay is due to the fact that we apparently lost the xml source file... 
If anyone has knowledge of a semi-automatic way to translate .txt into .xml, I'd be interested. Otherwise, I guess that I'll have to rewrite the xml file, which takes longer than I expected. I'm still allowing some days to see if the xml file can't be found.

Kind regards,
--Bruno
 
 > 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

_________________________________________________________________________________________________________________________

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.