Bruno, BGP session can carry multiple messages. One is UPDATE MSG
Why do you want to nest indicator about session going down in the UPDATE msg rather then just using new NOTIFICATION subcode say "Gracefull shutdown" ? Clearly it would not be backwards compatible but I guess this is no longer a goal is it ? The issue with sending it in UPDATE MSG is that you effectively need to re-advertise the entire table just before going down which will in turn could cause more churn in your peer's ASes and beyond. Or do you want to came back to concept of defining a beacon prefix acting as semaphore for entire session :) Cheers, R. On Wed, Mar 15, 2017 at 4:26 PM, <[email protected]> wrote: > Thanks for the useful feedback. > > --Bruno > > > -----Original Message----- > > From: Ben Maddison [mailto:[email protected]] > > Sent: Wednesday, March 15, 2017 4:23 PM > > To: Job Snijders; DECRAENE Bruno IMT/OLN > > Cc: [email protected] > > Subject: 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: [email protected] > > SIP: [email protected] > > > > > > > > > > -----Original Message----- > > From: GROW [mailto:[email protected]] On Behalf Of Job Snijders > > Sent: Wednesday, March 15, 2017 4:54 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? > > > > Hi Bruno, > > > > On Wed, Mar 15, 2017 at 02:00:37PM +0000, [email protected] > wrote: > > > > From: GROW [mailto:[email protected]] 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 > > [email protected] > > 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. > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
