[GROW] draft-ietf-grow-bgp-gshut-11
Hi all, -11 has just been uploaded. I believe it address all comments received so far: during WGLC and some private comments afterward. There have been significant editorial changes introduced, with a main goal to put the focus on the Graceful BGP session shutdown itself, and reduce/remove side text. In particular: - section 5 "Beyond EBGP graceful shutdown" has moved to Appendix C. - section 4 "Practices to avoid packet losses", which served as a longer introduction, has been removed or partly moved when applicable. Best regards, --Bruno > -Original Message- > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of > internet- > dra...@ietf.org > Sent: Thursday, September 21, 2017 11:02 AM > To: i-d-annou...@ietf.org > Cc: grow@ietf.org > Subject: I-D Action: draft-ietf-grow-bgp-gshut-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : Graceful BGP session shutdown > Authors : Pierre Francois > Bruno Decraene > Cristel Pelsser > Keyur Patel > Clarence Filsfils > Filename: draft-ietf-grow-bgp-gshut-11.txt > Pages : 10 > Date: 2017-09-21 > > Abstract: >This draft standardizes a new well-known BGP community >GRACEFUL_SHUTDOWN to signal the graceful shutdown of paths. This >draft also describes operational procedures which use this community >to reduce the amount of traffic lost when BGP peering sessions are >about to be shut down deliberately, e.g. for planned maintenance. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-11 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] draft-ietf-grow-bgp-gshut-09.txt
Hi all, > draft: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-09 > diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-09 This version is expected to address all comments received. >From a technical standpoint, the main changes are: a) g-shut community is not removed anymore b) LOCAL_PREF is set to low including on the g-shut receiver (and not just over IBGP sessions) Special thanks to Job for providing the configuration examples. Regards, --Bruno > -Original Message- > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of > internet- > dra...@ietf.org > Sent: Monday, July 03, 2017 7:20 PM > To: i-d-annou...@ietf.org > Cc: grow@ietf.org > Subject: I-D Action: draft-ietf-grow-bgp-gshut-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations of the IETF. > > Title : Graceful BGP session shutdown > Authors : Pierre Francois > Bruno Decraene > Cristel Pelsser > Keyur Patel > Clarence Filsfils > Filename: draft-ietf-grow-bgp-gshut-09.txt > Pages : 12 > Date: 2017-07-03 > > Abstract: >This draft describes operational procedures aimed at reducing the >amount of traffic lost during planned maintenances of routers or >links, involving the shutdown of BGP peering sessions. It defines a >well-known BGP community, called GRACEFUL_SHUTDOWN, to signal the >graceful shutdown of paths. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-09 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Fri, Jun 30, 2017 at 03:26:08PM +, bruno.decra...@orange.com: > > From: heasley [mailto:h...@shrubbery.net] > Sent: Thursday, June 29, 2017 > > 8:28 PM > > > > Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com: > > > > > > > > > > From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, > 2017 7:07 PM > > > > To: DECRAENE Bruno IMT/OLN > > > > Cc: grow@ietf.org > > > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > > > > > > > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > > > > > Suggestions: > > > > > > > > > > > > OLD Abstract: > > > > > >This draft describes operational procedures aimed at reducing > the > > > > > >amount of traffic lost during planned maintenances of routers > or > > > > > >links, involving the shutdown of BGP peering sessions. > > > > > > NEW Abstract: > > > > > >This draft describes operational procedures aimed at reducing > the > > > > > >amount of traffic lost during planned maintenances of routers > or > > > > > >links, involving the shutdown of BGP peering sessions. > Additionally > > > > > >this document describes the use of a well-known Border Gateway > > > > > >Protocol (BGP) community to signal that a graceful shutdown > has been > > > > > >initiated for the tagged prefix. > > > > > > > > > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP > community, called > > gshut, to > > > > signal the graceful shutdown of paths to other Autonomous Systems." > > > > > > > > s/paths to other Autonomous Systems./a path in the presence of other > paths./ > > > > > > > > ie: it does nothing when there is no other path and it may not move to > > > > anoter AS, just to another path. it is per-session, not per-AS. > > > > > > My sentence was misleading. Changing to: "It defines a well-known BGP > community, > > called g-shut, to signal over the EBGP session to be shutdown, the > graceful shutdown of > > paths." > > > > As Jakob mentioned, its not ebgp-only, as it also addresses shutting an > > ibgp or an entire speaker. > > The procedure is not limited to ebgp. However the BGP community is defined in > order to perform the signaling specifically over EBGP. > Over IBGP, we use LOCAL_PREF to lower the preference of the route. Even if > the community may be kept for information. you would still want to add the community; if you have no other path, you still want the community to be on routes to remote eBGP peers, if you have any in-bound iBGP policy that might affect the LP, you still want/need to communicate to the ibgp peers. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > Sent: Wednesday, June > 28, 2017 11:52 PM > > You're right Bruno. I misstated it. > > Still, node A will ever have no path available. > Whether Gshut initiator sends gshut or withdraws, the result is the same: > RR sends the new path to Node A. In the end, yes. But if the gshut initiator sends a withdraw to its RR, and its RR does not have the pre-knowledge of a backup path, the withdraw is first propagated to the RR clients. However this is a corner case as it would assume the gshut initiator to know more IBGP paths than its RR. Given that most people would prefer applying the low LOCAL_PREF on the gshut initiator itself, let's do this. Hopefully I'll upload a new version before the deadline (Monday) Thanks for the feedback --Bruno > Thanks, > Jakob. > > > > -Original Message- > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > > Sent: Wednesday, June 28, 2017 1:56 PM > > To: Jakob Heitz (jheitz) <jhe...@cisco.com> > > Cc: grow@ietf.org > > Subject: RE: [GROW] draft-ietf-grow-bgp-gshut > > > > Jakob, > > > > > > > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > > > Sent: Wednesday, June 28, 2017 10:13 PM > > > > > > Bruno, > > > > > > > > If they are available to the gshut initiating router, then they > > > > > are available to the other routers. > > > > > > > > Why? > > > > > > The advertising router advertised it. > > > Your example is iBGP. When one speaker advertises, the whole AS > > receives it. > > > > If you assume an IBGP full mesh, I agree. > > If you have a Route Reflector topology, without add-path, I disagree. > > Only one path is advertised by the RR. We can always find a node A, in the > > Initiator AS, > which uses the g-shut > > initiator as best path/Next Hop (otherwise, nobody uses the path > > advertised by the g- > shut initiator, and there is no > > need for g-shut). That node A received a single path from its RR (the path > > from the g-shut > initiator), hence it does > > not know an alternate path. Even if another node B advertises an alternate > > path thanks > to best-external or by > > preferring its EBGP path over an IBGP path (both paths having the same > > LOCAL_PREF, > aspath length, origin, MED) > > > > > > > Now suppose because of some weirdness, not every speaker in the AS > > receives it. > > > Then even a gshut community isn't going to make a difference. > > > Even after the gshut, this iBGP route isn't going to get any further. > > > > I'm not sure to follow your point. > > The route being gshut has a low local_pref hence the alternate route with > > become best > and propagated across the AS. > > > > Thanks > > --Bruno > > > > > > Thanks, > > > Jakob. > > > > > > > _ > ___ > > _ > > > > 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. _ 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'ex
Re: [GROW] draft-ietf-grow-bgp-gshut
> From: heasley [mailto:h...@shrubbery.net] > Sent: Thursday, June 29, 2017 > 8:28 PM > > Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com: > > > > > > > From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, > > 2017 7:07 PM > > > To: DECRAENE Bruno IMT/OLN > > > Cc: grow@ietf.org > > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > > > > > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > > > > Suggestions: > > > > > > > > > > OLD Abstract: > > > > >This draft describes operational procedures aimed at reducing > > the > > > > >amount of traffic lost during planned maintenances of routers or > > > > >links, involving the shutdown of BGP peering sessions. > > > > > NEW Abstract: > > > > >This draft describes operational procedures aimed at reducing > > the > > > > >amount of traffic lost during planned maintenances of routers or > > > > >links, involving the shutdown of BGP peering sessions. > > Additionally > > > > >this document describes the use of a well-known Border Gateway > > > > >Protocol (BGP) community to signal that a graceful shutdown has > > been > > > > >initiated for the tagged prefix. > > > > > > > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP > > community, called > gshut, to > > > signal the graceful shutdown of paths to other Autonomous Systems." > > > > > > s/paths to other Autonomous Systems./a path in the presence of other > > paths./ > > > > > > ie: it does nothing when there is no other path and it may not move to > > > anoter AS, just to another path. it is per-session, not per-AS. > > > > My sentence was misleading. Changing to: "It defines a well-known BGP > > community, > called g-shut, to signal over the EBGP session to be shutdown, the graceful > shutdown of > paths." > > As Jakob mentioned, its not ebgp-only, as it also addresses shutting an > ibgp or an entire speaker. The procedure is not limited to ebgp. However the BGP community is defined in order to perform the signaling specifically over EBGP. Over IBGP, we use LOCAL_PREF to lower the preference of the route. Even if the community may be kept for information. Thanks, Regards, --Bruno _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com: > > > > From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, 2017 > 7:07 PM > > To: DECRAENE Bruno IMT/OLN > > Cc: grow@ietf.org > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > > > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > > > Suggestions: > > > > > > > > OLD Abstract: > > > >This draft describes operational procedures aimed at reducing the > > > >amount of traffic lost during planned maintenances of routers or > > > >links, involving the shutdown of BGP peering sessions. > > > > NEW Abstract: > > > >This draft describes operational procedures aimed at reducing the > > > >amount of traffic lost during planned maintenances of routers or > > > >links, involving the shutdown of BGP peering sessions. Additionally > > > >this document describes the use of a well-known Border Gateway > > > >Protocol (BGP) community to signal that a graceful shutdown has > been > > > >initiated for the tagged prefix. > > > > > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, > called gshut, to > > signal the graceful shutdown of paths to other Autonomous Systems." > > > > s/paths to other Autonomous Systems./a path in the presence of other > paths./ > > > > ie: it does nothing when there is no other path and it may not move to > > anoter AS, just to another path. it is per-session, not per-AS. > > My sentence was misleading. Changing to: "It defines a well-known BGP > community, called g-shut, to signal over the EBGP session to be shutdown, the > graceful shutdown of paths." As Jakob mentioned, its not ebgp-only, as it also addresses shutting an ibgp or an entire speaker. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
You're right Bruno. I misstated it. Still, node A will ever have no path available. Whether Gshut initiator sends gshut or withdraws, the result is the same: RR sends the new path to Node A. Thanks, Jakob. > -Original Message- > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > Sent: Wednesday, June 28, 2017 1:56 PM > To: Jakob Heitz (jheitz) <jhe...@cisco.com> > Cc: grow@ietf.org > Subject: RE: [GROW] draft-ietf-grow-bgp-gshut > > Jakob, > > > > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > > Sent: Wednesday, June 28, 2017 10:13 PM > > > > Bruno, > > > > > > If they are available to the gshut initiating router, then they > > > > are available to the other routers. > > > > > > Why? > > > > The advertising router advertised it. > > Your example is iBGP. When one speaker advertises, the whole AS receives > it. > > If you assume an IBGP full mesh, I agree. > If you have a Route Reflector topology, without add-path, I disagree. > Only one path is advertised by the RR. We can always find a node A, in the > Initiator AS, which uses the g-shut > initiator as best path/Next Hop (otherwise, nobody uses the path advertised > by the g-shut initiator, and there is no > need for g-shut). That node A received a single path from its RR (the path > from the g-shut initiator), hence it does > not know an alternate path. Even if another node B advertises an alternate > path thanks to best-external or by > preferring its EBGP path over an IBGP path (both paths having the same > LOCAL_PREF, aspath length, origin, MED) > > > > Now suppose because of some weirdness, not every speaker in the AS > receives it. > > Then even a gshut community isn't going to make a difference. > > Even after the gshut, this iBGP route isn't going to get any further. > > I'm not sure to follow your point. > The route being gshut has a low local_pref hence the alternate route with > become best and propagated across the AS. > > Thanks > --Bruno > > > > Thanks, > > Jakob. > > > > _ > > 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Mon, Jun 26, 2017 at 05:39:12PM +0200, Job Snijders: > > As for my requirements, I'm considering that our ASes have the > > knowledge of the backup path. Hence I don't need for the extra > > coverage. Regarding the extra cost, I agree that one can hardly > > consider this unacceptable since this is the current behavior. > > > > TL;DR: it's a tradeoff between 2 secondary objectives: > > - reducing Internet churned (compared to today) > > - improving the g-shut coverage when the AS does not know the backup path > > + improve visibility into the operation +1 for that; and allows it to (possibly) enter the records of routeviews. & allows other ASes beyond the receiver to take action - even if the receiver does not have an alternate path ... which imiho ends this discussion about removing the community. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Jakob, > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > Sent: Wednesday, June 28, 2017 10:13 PM > > Bruno, > > > > If they are available to the gshut initiating router, then they > > > are available to the other routers. > > > > Why? > > The advertising router advertised it. > Your example is iBGP. When one speaker advertises, the whole AS receives it. If you assume an IBGP full mesh, I agree. If you have a Route Reflector topology, without add-path, I disagree. Only one path is advertised by the RR. We can always find a node A, in the Initiator AS, which uses the g-shut initiator as best path/Next Hop (otherwise, nobody uses the path advertised by the g-shut initiator, and there is no need for g-shut). That node A received a single path from its RR (the path from the g-shut initiator), hence it does not know an alternate path. Even if another node B advertises an alternate path thanks to best-external or by preferring its EBGP path over an IBGP path (both paths having the same LOCAL_PREF, aspath length, origin, MED) > Now suppose because of some weirdness, not every speaker in the AS receives > it. > Then even a gshut community isn't going to make a difference. > Even after the gshut, this iBGP route isn't going to get any further. I'm not sure to follow your point. The route being gshut has a low local_pref hence the alternate route with become best and propagated across the AS. Thanks --Bruno > > Thanks, > Jakob. _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Bruno, > > If they are available to the gshut initiating router, then they > > are available to the other routers. > > Why? The advertising router advertised it. Your example is iBGP. When one speaker advertises, the whole AS receives it. Now suppose because of some weirdness, not every speaker in the AS receives it. Then even a gshut community isn't going to make a difference. Even after the gshut, this iBGP route isn't going to get any further. Thanks, Jakob. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Jakob, > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > Sent: Wednesday, June 28, 2017 7:53 AM > > Bruno, > > To my mind, the purpose of graceful shutdown is to tease out the > hidden paths before sending the withdraw. In your cases, the > alternative paths are not hidden. They are already available. The purpose of the graceful shutdown is to reduce, possibly remove, the loss of connectivity when an EBGP session is shutdown. The main contribution is indeed the time taken to learn and install the backup paths. What is needed is an AS global convergence, not just the g-shut initiator. In this specific case, the alternative path is known to the g-shut initiator. That does not mean that it is known by all routers in the AS. > If they are available to the gshut initiating router, then they > are available to the other routers. Why? > Therefore a withdraw is ok. If we want to avoid any node to have a lack of path, avoiding withdraw is just safer. Especially considering the wide possibilities of BGP topologies inside the AS. > Now, consider a not uncommon case: > The gshut initiating router has 2 advertiseable paths. > Another router has an inferior path. > When the gshut is initiated for one path, the inferior path > from the other router will be chosen by the network. > When gshut is removed, the network will churn a second time > when it chooses the second path. Sure. >From a probability standpoint, there is more chance that the post convergence >path be advertised by one of the other (e.g. 100) routers than by this (ingle) >g-shut router. Especially assuming that most AS would want to protect against >node failure, the backup path would typically be connected on a different node >(if available of course). Note also that your "second churn" is part of IBGP path hunting and may happen in any case (i.e. the first alternate path found may not the best/post convergence one) > I think it's better for the gshut initiating router to just > advertise its next best path instead of gshut. OK. Thanks for the feedback. This seems to be the general sense of the GROW WG. I'll wait some more time to have a chance to collect all feedbacks, and we'll update the draft. Thanks --Bruno > Thanks, > Jakob. > > > > -Original Message- > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of > > bruno.decra...@orange.com > > Sent: Tuesday, June 27, 2017 6:15 AM > > I'm not following you, so I'll provide an example of "not allowed to be > > advertised on > IBGP" > > Topology: the g-shut initiator has an IBGP session with another ASBR > > (e.g. ASBR1 in the > same POP). This ASBR knows > > an alternate path and advertise it over IBGP. (e.g. best external, or > > EBGP>IBGP) > > g-shut convergence: If the g-shut initiator applies the low local_pref, it > > will switch to this > alternate path. As it > > can't advertise over IBGP a path learned over IBGP, it will send a > > withdraw to both its > Route Reflector and its own > > IBGP peer. > > Discussion: May be we could assume that its Route Reflector and IBGP peers > > also have the > pre-knowledge of this > > alternate path (from ASBR1) in which case this is not a big deal. But in > > theory, it's just > safer to never send a > > withdraw. _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Job, > From: Job Snijders [mailto:j...@ntt.net] > Sent: Monday, June 26, 2017 5:31 PM > > On Mon, Jun 26, 2017 at 02:14:19PM +, bruno.decra...@orange.com wrote: > > > From: Job Snijders [mailto:j...@ntt.net] > > > Sent: Thursday, June 22, 2017 10:47 PM > > > > [...] > > > > > the place where the low local preference is set > > > should move closer to the initiator of the gshut. Instead of setting > > > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set > > > during application of the local policy on the relevant Adj-RIB-In. > > > > Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out > > and not on the Loc_RIB. > > Yes, that should change. > > > This has a technical benefit as otherwise, the router may (locally) > > select a backup route which it is not allowed to advertise, which > > would trigger the sending of a withdraw of the original route. i.e. > > not a g-shut. > > Sure, but the reverse is true too. It may select a path that it is not > allowed to advertise and with the gshut community select something else. I'm not following you, so I'll provide an example of "not allowed to be advertised on IBGP" Topology: the g-shut initiator has an IBGP session with another ASBR (e.g. ASBR1 in the same POP). This ASBR knows an alternate path and advertise it over IBGP. (e.g. best external, or EBGP>IBGP) g-shut convergence: If the g-shut initiator applies the low local_pref, it will switch to this alternate path. As it can't advertise over IBGP a path learned over IBGP, it will send a withdraw to both its Route Reflector and its own IBGP peer. Discussion: May be we could assume that its Route Reflector and IBGP peers also have the pre-knowledge of this alternate path (from ASBR1) in which case this is not a big deal. But in theory, it's just safer to never send a withdraw. > This is not a strong argument. > > > This may be considered as a corner case, but I don't see why we would > > choose not cover > it. > > I suppose that one can also see some operational drawbacks: > > a) seems less intuitive. > > b) traffic received from external interfaces on this specific g-shut > > router (the egress in the AS) are forwarded on the "nominal"/g-shut > > path, rather than on the backup path. > > Yes, and avoiding the nominal path (using a backup path) has great > benefit that the operator can monitor whether convergence is finished, > which can be used in the decision making process when to proceed with > the maintenance. > > Operational expectation is that when one initiates a process to drain > traffic from a node or a link, that traffic is actually, visibly drained > away from a link. > > > IMO: > > - "a" is not a big concern as the related configuration is > > pre-configured once for all on the router. We are not discussing the > > configuration applied at maintenance time. > > - "b" has no impact on the customer loss of connectivity as this > > traffic may be locally rerouted in no time (up to zero packet loss) by > > the router which needs to update its FIB "in place". i.e. the > > destination IP prefix is never removed from the FIB. Only the outgoing > > interface is changed, and during this change, both outgoing interfaces > > are valid (both the old and the new). > > This assumes that all parties involved can actually locally reroute > without packetloss. I'm not sure what you mean by "parties". If you mean "routers in the AS", then we are only discussing the local convergence on one ASBR between 2 EBGP paths already known. So there are no other routers. If you mean "implementations", then I agree with you but there is nothing we can do about this. If one implementation lose 200ms of traffic when doing "in-place modify" in the FIB (i.e. in the best case when we know both the nominal and backup path at the same time and just replace the outgoing interface without touching the IP prefix) then the problem is the implementation. > One cannot know this. Also, what of the case where a > single ASN is composed of a single router (or a network is operated > without the concept of IBGP as defined by IETF). This cases works just fine. Including with no BGP graceful shutdown given that there is no IBGP path exploration to be done across the AS. > > So although some may see a tradeoff, I'd rather favor the generality > > of the mechanism. Specifically as not covering the corner cases may > > surprise the operator. > > Also, as it currently stands operators, are implementing it on Loc-RIB. > > Another argument in favor of adjustment on Loc-RIB rather then "On > Adj-RIB-Out but only for IBGP sessions", is that it is much easier to > explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is > expected to lower LOCAL_PREF as low as possible" (and simply forgo > explaining the particular conditionals of the current draft). > > Kind regards, > > Job
Re: [GROW] draft-ietf-grow-bgp-gshut
Job, > From: Job Snijders [mailto:j...@ntt.net] > Sent: Monday, June 26, 2017 5:39 > PM > > On Mon, Jun 26, 2017 at 01:58:40PM +, bruno.decra...@orange.com wrote: > > Hi Job, all > > > > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, > > > 2017 10:47 PM > > [...] > > > > > I think that the neighbor ASBR should _not_ strip the GSHUT > > > well-known community. > > > > I'm personally open to both options. > > Discussing this further: > > > > - First of all, stripping the g-shut well-known community fits the > > goal of the document and its requirements (RFC 6198). The main > > motivation is to have a g-shut solution with no required BGP protocol > > extension, and where the backup path is known to the AS. i.e. we are > > not looking for an Internet wide convergence/g-shut. We are primarily > > interested in a g-shut within the responsibility of the AS. IOW, when > > it's "my fault" if my customer experiences a packet loss. In this > > case, there is no need to propagate the g-shut community further. > > > > - removing the g-shut community reduces Internet wide churns, > > including compared to when g-shut is not used. > > Here are the 3 cases, focusing on the first step of the BGP > > convergence (searching for the backup path) > > - No g-shut: a WITHDRAW is propagated to other ASes > > - g-shut propagating the community: an UDPDATE is propagated to > > others ASes (same path, adding the community) > > - g-shut removing the community: no BGP messages propagated to > > others ASes (same path, same communities/attribute) > > > > In general, reducing the BGP churn is considered as a feature. By > > removing the g-shut community, we are at the same time: > > a) g-shut in both affected ASes > > b) reducing Internet churn. > > > > Now if we choose to not remove the community, we improve "a" by > > covering the cases where the backup path is unknown to the AS. And we > > keep "b" unchanged compared to today (but degrade it compare to > > current g-shut draft). > > I don't think we really have a say in whether BGP Communities are > removed or not. This is outside our control. If we remove the hard > requirement to remove the community, the behaviour falls back to > https://tools.ietf.org/html/rfc7454#section-11 which imho is fine: leave > the choice with the operator. Perhaps the draft does not need to define > whether to strip or not. > > I have to admit that the first time I used a a 'g-shut -06 compliant' > automated process, I was surprised that that I didn't see the community > on the IBGP outbound announcements. Removing the community somewhat > reduces visibility to those involved with the operation. > > > As for my requirements, I'm considering that our ASes have the > > knowledge of the backup path. Hence I don't need for the extra > > coverage. Regarding the extra cost, I agree that one can hardly > > consider this unacceptable since this is the current behavior. > > > > TL;DR: it's a tradeoff between 2 secondary objectives: > > - reducing Internet churned (compared to today) > > - improving the g-shut coverage when the AS does not know the backup path > > + improve visibility into the operation > > > Draft can possibly discuss both options, at the cost of additional > > reading complexity. But this possibly could be discussed in a > > different section. > > > > I'd welcome more opinion, before choosing the main text. > > Bruno, perhaps my interpretation of the above sentence's phrasing is > somewhat mangled because neither of us are a native speaker, but keep in > mind this is a GROW working group document. :-) To rephrase: I'd welcome more feedback from the GROW WG before reflecting the consensus in the document. --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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
> From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, 2017 > 7:07 PM > To: DECRAENE Bruno IMT/OLN > Cc: grow@ietf.org > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > > Suggestions: > > > > > > OLD Abstract: > > >This draft describes operational procedures aimed at reducing the > > >amount of traffic lost during planned maintenances of routers or > > >links, involving the shutdown of BGP peering sessions. > > > NEW Abstract: > > >This draft describes operational procedures aimed at reducing the > > >amount of traffic lost during planned maintenances of routers or > > >links, involving the shutdown of BGP peering sessions. Additionally > > >this document describes the use of a well-known Border Gateway > > >Protocol (BGP) community to signal that a graceful shutdown has been > > >initiated for the tagged prefix. > > > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, > > called gshut, to > signal the graceful shutdown of paths to other Autonomous Systems." > > s/paths to other Autonomous Systems./a path in the presence of other paths./ > > ie: it does nothing when there is no other path and it may not move to > anoter AS, just to another path. it is per-session, not per-AS. My sentence was misleading. Changing to: "It defines a well-known BGP community, called g-shut, to signal over the EBGP session to be shutdown, the graceful shutdown of paths." Thanks, --Bruno _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Hi all, In-line as [BM] On Mon, 2017-06-26 at 17:39 +0200, Job Snijders wrote: > On Mon, Jun 26, 2017 at 01:58:40PM +, bruno.decra...@orange.com > wrote: > > Hi Job, all > > > > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June > > > 22, 2017 10:47 PM > > > > [...] > > > > > I think that the neighbor ASBR should _not_ strip the GSHUT > > > well-known community. > > > > I'm personally open to both options. > > Discussing this further: > > > > - First of all, stripping the g-shut well-known community fits the > > goal of the document and its requirements (RFC 6198). The main > > motivation is to have a g-shut solution with no required BGP > > protocol > > extension, and where the backup path is known to the AS. i.e. we > > are > > not looking for an Internet wide convergence/g-shut. We are > > primarily > > interested in a g-shut within the responsibility of the AS. IOW, > > when > > it's "my fault" if my customer experiences a packet loss. In this > > case, there is no need to propagate the g-shut community further. > > [BM] However, if by propagating the community we get reasonable Internet-wide g-shut coverage, then why prevent that? > > - removing the g-shut community reduces Internet wide churns, > > including compared to when g-shut is not used. > > Here are the 3 cases, focusing on the first step of the BGP > > convergence (searching for the backup path) > > - No g-shut: a WITHDRAW is propagated to other ASes > > - g-shut propagating the community: an UDPDATE is propagated to > > others ASes (same path, adding the community) [BM] This generates an "interim" UPDATE (adding the community) only where the propagating AS has no alternate path. In that case, the additional UPDATE provides the remote AS an opportunity to re-converge around the shutdown at the AS-graph level, and therefore seems to me to have value. Alternatively, if the receiving AS does have an alternate path then: a) the alternate path is eligible for export, then an UPDATE may be generated if the alt-path has differing attributes. This UPDATE would eventually be generated at shutdown-time anyway, so no additional churn here; or b) the alternative path is not eligible for export, then a WITHDRAW is generated, which would be generated eventually at shutdown-time anyway, so no additional churn here either. > > - g-shut removing the community: no BGP messages propagated to > > others ASes (same path, same communities/attribute) [BM] Correct, but also no opportunity to reroute traffic around the AS that will shortly be sending a WITHDRAW anyway. > > > > In general, reducing the BGP churn is considered as a feature. By > > removing the g-shut community, we are at the same time: > > a) g-shut in both affected ASes > > b) reducing Internet churn. > > > > Now if we choose to not remove the community, we improve "a" by > > covering the cases where the backup path is unknown to the AS. And > > we > > keep "b" unchanged compared to today (but degrade it compare to > > current g-shut draft). > > I don't think we really have a say in whether BGP Communities are > removed or not. This is outside our control. If we remove the hard > requirement to remove the community, the behaviour falls back to > https://tools.ietf.org/html/rfc7454#section-11 which imho is fine: > leave > the choice with the operator. Perhaps the draft does not need to > define > whether to strip or not. [BM] Agreed. I don't see a case for treating this community differently from any other 1997 community in this respect. > > I have to admit that the first time I used a a 'g-shut -06 compliant' > automated process, I was surprised that that I didn't see the > community > on the IBGP outbound announcements. Removing the community somewhat > reduces visibility to those involved with the operation. > > > As for my requirements, I'm considering that our ASes have the > > knowledge of the backup path. Hence I don't need for the extra > > coverage. Regarding the extra cost, I agree that one can hardly > > consider this unacceptable since this is the current behavior. > > > > TL;DR: it's a tradeoff between 2 secondary objectives: > > - reducing Internet churned (compared to today) > > - improving the g-shut coverage when the AS does not know the > > backup path > > + improve visibility into the operation > [BM] In particular, a 3rd party that is trying to self-service an answer to the question "why did the traffic move" will be looking at a looking-glass rather than a router CLI. More visibility is particularly helpful in this case. Cheers, Ben > > Draft can possibly discuss both options, at the cost of additional > > reading complexity. But this possibly could be discussed in a > > different section. > > > > I'd welcome more opinion, before choosing the main text. > > Bruno, perhaps my interpretation of the above sentence's phrasing is > somewhat mangled because neither of us are a native speaker, but keep > in > mind this is a
Re: [GROW] draft-ietf-grow-bgp-gshut
Local pref should be reduced when the route is received. Consider router that learns a route on 2 interfaces. The best path is on the interface that will go down. The right thing to do is to change the best path to the other one. Lowering local pref at the incomming interface will do that. Thanks, Jakob. > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders > Sent: Monday, June 26, 2017 8:31 AM > To: bruno.decra...@orange.com > Cc: grow@ietf.org > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > On Mon, Jun 26, 2017 at 02:14:19PM +, bruno.decra...@orange.com wrote: > > > From: Job Snijders [mailto:j...@ntt.net] > > > Sent: Thursday, June 22, 2017 10:47 PM > > > > [...] > > > > > the place where the low local preference is set > > > should move closer to the initiator of the gshut. Instead of setting > > > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set > > > during application of the local policy on the relevant Adj-RIB-In. > > > > Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out > > and not on the Loc_RIB. > > Yes, that should change. > > > This has a technical benefit as otherwise, the router may (locally) > > select a backup route which it is not allowed to advertise, which > > would trigger the sending of a withdraw of the original route. i.e. > > not a g-shut. > > Sure, but the reverse is true too. It may select a path that it is not > allowed to advertise and with the gshut community select something else. > This is not a strong argument. > > > This may be considered as a corner case, but I don't see why we would > > choose not cover it. > > I suppose that one can also see some operational drawbacks: > > a) seems less intuitive. > > b) traffic received from external interfaces on this specific g-shut > > router (the egress in the AS) are forwarded on the "nominal"/g-shut > > path, rather than on the backup path. > > Yes, and avoiding the nominal path (using a backup path) has great > benefit that the operator can monitor whether convergence is finished, > which can be used in the decision making process when to proceed with > the maintenance. > > Operational expectation is that when one initiates a process to drain > traffic from a node or a link, that traffic is actually, visibly drained > away from a link. > > > IMO: > > - "a" is not a big concern as the related configuration is > > pre-configured once for all on the router. We are not discussing the > > configuration applied at maintenance time. > > - "b" has no impact on the customer loss of connectivity as this > > traffic may be locally rerouted in no time (up to zero packet loss) by > > the router which needs to update its FIB "in place". i.e. the > > destination IP prefix is never removed from the FIB. Only the outgoing > > interface is changed, and during this change, both outgoing interfaces > > are valid (both the old and the new). > > This assumes that all parties involved can actually locally reroute > without packetloss. One cannot know this. Also, what of the case where a > single ASN is composed of a single router (or a network is operated > without the concept of IBGP as defined by IETF). > > > So although some may see a tradeoff, I'd rather favor the generality > > of the mechanism. Specifically as not covering the corner cases may > > surprise the operator. > > Also, as it currently stands operators, are implementing it on Loc-RIB. > > Another argument in favor of adjustment on Loc-RIB rather then "On > Adj-RIB-Out but only for IBGP sessions", is that it is much easier to > explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is > expected to lower LOCAL_PREF as low as possible" (and simply forgo > explaining the particular conditionals of the current draft). > > Kind regards, > > Job > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
It works for iBGP links too. An iBGP link is not to another AS. Thanks, Jakob. > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley > Sent: Monday, June 26, 2017 10:07 AM > To: bruno.decra...@orange.com > Cc: grow@ietf.org > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > > Suggestions: > > > > > > OLD Abstract: > > >This draft describes operational procedures aimed at reducing the > > >amount of traffic lost during planned maintenances of routers or > > >links, involving the shutdown of BGP peering sessions. > > > NEW Abstract: > > >This draft describes operational procedures aimed at reducing the > > >amount of traffic lost during planned maintenances of routers or > > >links, involving the shutdown of BGP peering sessions. Additionally > > >this document describes the use of a well-known Border Gateway > > >Protocol (BGP) community to signal that a graceful shutdown has been > > >initiated for the tagged prefix. > > > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, > > called gshut, to signal the graceful > shutdown of paths to other Autonomous Systems." > > s/paths to other Autonomous Systems./a path in the presence of other paths./ > > ie: it does nothing when there is no other path and it may not move to > anoter AS, just to another path. it is per-session, not per-AS. > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com: > > Suggestions: > > > > OLD Abstract: > >This draft describes operational procedures aimed at reducing the > >amount of traffic lost during planned maintenances of routers or > >links, involving the shutdown of BGP peering sessions. > > NEW Abstract: > >This draft describes operational procedures aimed at reducing the > >amount of traffic lost during planned maintenances of routers or > >links, involving the shutdown of BGP peering sessions. Additionally > >this document describes the use of a well-known Border Gateway > >Protocol (BGP) community to signal that a graceful shutdown has been > >initiated for the tagged prefix. > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, > called gshut, to signal the graceful shutdown of paths to other Autonomous > Systems." s/paths to other Autonomous Systems./a path in the presence of other paths./ ie: it does nothing when there is no other path and it may not move to anoter AS, just to another path. it is per-session, not per-AS. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
On Mon, Jun 26, 2017 at 01:58:32PM +, bruno.decra...@orange.com wrote: > > I think section 6 for link up should stay. > > The cases desctibed are real, whether corner or not. > > [Bruno] agreed. I agree it is valuable text, but the draft is about "SHUTDOWN" - not about "Link Up". Perhaps spin it off into a more complete draft focussing specifically on this topic? Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
On Mon, Jun 26, 2017 at 01:58:40PM +, bruno.decra...@orange.com wrote: > Hi Job, all > > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, 2017 > > 10:47 PM > [...] > > > I think that the neighbor ASBR should _not_ strip the GSHUT > > well-known community. > > I'm personally open to both options. > Discussing this further: > > - First of all, stripping the g-shut well-known community fits the > goal of the document and its requirements (RFC 6198). The main > motivation is to have a g-shut solution with no required BGP protocol > extension, and where the backup path is known to the AS. i.e. we are > not looking for an Internet wide convergence/g-shut. We are primarily > interested in a g-shut within the responsibility of the AS. IOW, when > it's "my fault" if my customer experiences a packet loss. In this > case, there is no need to propagate the g-shut community further. > > - removing the g-shut community reduces Internet wide churns, > including compared to when g-shut is not used. > Here are the 3 cases, focusing on the first step of the BGP > convergence (searching for the backup path) > - No g-shut: a WITHDRAW is propagated to other ASes > - g-shut propagating the community: an UDPDATE is propagated to > others ASes (same path, adding the community) > - g-shut removing the community: no BGP messages propagated to > others ASes (same path, same communities/attribute) > > In general, reducing the BGP churn is considered as a feature. By > removing the g-shut community, we are at the same time: > a) g-shut in both affected ASes > b) reducing Internet churn. > > Now if we choose to not remove the community, we improve "a" by > covering the cases where the backup path is unknown to the AS. And we > keep "b" unchanged compared to today (but degrade it compare to > current g-shut draft). I don't think we really have a say in whether BGP Communities are removed or not. This is outside our control. If we remove the hard requirement to remove the community, the behaviour falls back to https://tools.ietf.org/html/rfc7454#section-11 which imho is fine: leave the choice with the operator. Perhaps the draft does not need to define whether to strip or not. I have to admit that the first time I used a a 'g-shut -06 compliant' automated process, I was surprised that that I didn't see the community on the IBGP outbound announcements. Removing the community somewhat reduces visibility to those involved with the operation. > As for my requirements, I'm considering that our ASes have the > knowledge of the backup path. Hence I don't need for the extra > coverage. Regarding the extra cost, I agree that one can hardly > consider this unacceptable since this is the current behavior. > > TL;DR: it's a tradeoff between 2 secondary objectives: > - reducing Internet churned (compared to today) > - improving the g-shut coverage when the AS does not know the backup path + improve visibility into the operation > Draft can possibly discuss both options, at the cost of additional > reading complexity. But this possibly could be discussed in a > different section. > > I'd welcome more opinion, before choosing the main text. Bruno, perhaps my interpretation of the above sentence's phrasing is somewhat mangled because neither of us are a native speaker, but keep in mind this is a GROW working group document. :-) Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
On Mon, Jun 26, 2017 at 02:14:19PM +, bruno.decra...@orange.com wrote: > > From: Job Snijders [mailto:j...@ntt.net] > > Sent: Thursday, June 22, 2017 10:47 PM > > [...] > > > the place where the low local preference is set > > should move closer to the initiator of the gshut. Instead of setting > > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set > > during application of the local policy on the relevant Adj-RIB-In. > > Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out > and not on the Loc_RIB. Yes, that should change. > This has a technical benefit as otherwise, the router may (locally) > select a backup route which it is not allowed to advertise, which > would trigger the sending of a withdraw of the original route. i.e. > not a g-shut. Sure, but the reverse is true too. It may select a path that it is not allowed to advertise and with the gshut community select something else. This is not a strong argument. > This may be considered as a corner case, but I don't see why we would choose > not cover it. > I suppose that one can also see some operational drawbacks: > a) seems less intuitive. > b) traffic received from external interfaces on this specific g-shut > router (the egress in the AS) are forwarded on the "nominal"/g-shut > path, rather than on the backup path. Yes, and avoiding the nominal path (using a backup path) has great benefit that the operator can monitor whether convergence is finished, which can be used in the decision making process when to proceed with the maintenance. Operational expectation is that when one initiates a process to drain traffic from a node or a link, that traffic is actually, visibly drained away from a link. > IMO: > - "a" is not a big concern as the related configuration is > pre-configured once for all on the router. We are not discussing the > configuration applied at maintenance time. > - "b" has no impact on the customer loss of connectivity as this > traffic may be locally rerouted in no time (up to zero packet loss) by > the router which needs to update its FIB "in place". i.e. the > destination IP prefix is never removed from the FIB. Only the outgoing > interface is changed, and during this change, both outgoing interfaces > are valid (both the old and the new). This assumes that all parties involved can actually locally reroute without packetloss. One cannot know this. Also, what of the case where a single ASN is composed of a single router (or a network is operated without the concept of IBGP as defined by IETF). > So although some may see a tradeoff, I'd rather favor the generality > of the mechanism. Specifically as not covering the corner cases may > surprise the operator. Also, as it currently stands operators, are implementing it on Loc-RIB. Another argument in favor of adjustment on Loc-RIB rather then "On Adj-RIB-Out but only for IBGP sessions", is that it is much easier to explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is expected to lower LOCAL_PREF as low as possible" (and simply forgo explaining the particular conditionals of the current draft). Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Hi Job ,all > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, 2017 10:47 PM [...] > the place where the low local preference is set > should move closer to the initiator of the gshut. Instead of setting > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set > during application of the local policy on the relevant Adj-RIB-In. Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out and not on the Loc_RIB. This has a technical benefit as otherwise, the router may (locally) select a backup route which it is not allowed to advertise, which would trigger the sending of a withdraw of the original route. i.e. not a g-shut. This may be considered as a corner case, but I don't see why we would choose not cover it. I suppose that one can also see some operational drawbacks: a) seems less intuitive. b) traffic received from external interfaces on this specific g-shut router (the egress in the AS) are forwarded on the "nominal"/g-shut path, rather than on the backup path. IMO: - "a" is not a big concern as the related configuration is pre-configured once for all on the router. We are not discussing the configuration applied at maintenance time. - "b" has no impact on the customer loss of connectivity as this traffic may be locally rerouted in no time (up to zero packet loss) by the router which needs to update its FIB "in place". i.e. the destination IP prefix is never removed from the FIB. Only the outgoing interface is changed, and during this change, both outgoing interfaces are valid (both the old and the new). So although some may see a tradeoff, I'd rather favor the generality of the mechanism. Specifically as not covering the corner cases may surprise the operator. Thanks, Regards, --Bruno _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Hi Job, all > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, 2017 > 10:47 PM [...] > I think that the neighbor ASBR should _not_ strip the GSHUT well-known > community. I'm personally open to both options. Discussing this further: - First of all, stripping the g-shut well-known community fits the goal of the document and its requirements (RFC 6198). The main motivation is to have a g-shut solution with no required BGP protocol extension, and where the backup path is known to the AS. i.e. we are not looking for an Internet wide convergence/g-shut. We are primarily interested in a g-shut within the responsibility of the AS. IOW, when it's "my fault" if my customer experiences a packet loss. In this case, there is no need to propagate the g-shut community further. - removing the g-shut community reduces Internet wide churns, including compared to when g-shut is not used. Here are the 3 cases, focusing on the first step of the BGP convergence (searching for the backup path) - No g-shut: a WITHDRAW is propagated to other ASes - g-shut propagating the community: an UDPDATE is propagated to others ASes (same path, adding the community) - g-shut removing the community: no BGP messages propagated to others ASes (same path, same communities/attribute) In general, reducing the BGP churn is considered as a feature. By removing the g-shut community, we are at the same time: a) g-shut in both affected ASes b) reducing Internet churn. Now if we choose to not remove the community, we improve "a" by covering the cases where the backup path is unknown to the AS. And we keep "b" unchanged compared to today (but degrade it compare to current g-shut draft). As for my requirements, I'm considering that our ASes have the knowledge of the backup path. Hence I don't need for the extra coverage. Regarding the extra cost, I agree that one can hardly consider this unacceptable since this is the current behavior. TL;DR: it's a tradeoff between 2 secondary objectives: - reducing Internet churned (compared to today) - improving the g-shut coverage when the AS does not know the backup path Draft can possibly discuss both options, at the cost of additional reading complexity. But this possibly could be discussed in a different section. I'd welcome more opinion, before choosing the main text. Thanks, Regards, --Bruno _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Hi Jakob, Thanks for the comments. Please see inline [Bruno] > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz) > Sent: Monday, June 26, 2017 2:16 AM > > I agree with Job's proposals. > > In particular, the removal of the g-shut community should be carefully > considered. On the one hand, the g-shut community may not be originated > by the neighbor and is valid wherever the route may be advertised. > On the other hand, in the IPv4 and IPv6 address families, if an alternate > route is not available, the g-shut community can be spread throughout > all routers in the world, causing excessive churn. > I understand that this issue has been discussed in the working group, > but the concerns should be written into the RFC. [Bruno] I'll initiate a thread to rediscuss this point. Then we'll see the outcome to update the draft. > I think section 6 for link up should stay. > The cases desctibed are real, whether corner or not. [Bruno] agreed. > It does not even need route reflectors to happen. > All that is required is for a withdraw message to be processed by a router > before the new announcement. > > Consider: > R2 is announcing the best-path. > R1 was under maintenance and is coming up. > R1 advertises the new path to R2. > R2 withdraws its path. > R1 advertises the new path to R3. > R3 receives or processes the withdrawal from R2 before the advertisement > from R1. [Bruno] Indeed. In the draft, we presented the IBGP Route Reflector case, as we though that RR is more common than full mesh. Note that both cases are essentially the same: - IBGP full mesh between ASBR in your example - IBGP full mesh between RR in the draft In both cases, we have: - a distributed convergence with 2 nodes involved, - multiple/many IBGP sessions, creating multiple signaling paths, where a BGP UPDATE flowing along a 'long' path (2 sessions) may arrive after a BGP session flowing along a 'short' path (1 session). (Unfortunately) I agree that this is not theoretical. > "4.2.3 Router g-shut" should make it clear that the behavior is in addition > to the behavior of the links being shut down. Shutting down a router means > all its > links are going down too. In addition, the gshut community should be tagged > onto the originated routes. [Bruno] Agreed. Proposed text: OLD: In the case of a shutdown of a router, a reconfiguration of the outbound BGP route policies of the g-shut initiator SHOULD be performed to set a low LOCAL_PREF value for the paths originated by the g-shut initiator (e.g, BGP aggregates redistributed from other protocols, including static routes). This behavior is equivalent to the recommended behavior for paths "redistributed" from eBGP sessions to iBGP sessions in the case of the shutdown of an ASBR. NEW: In the case of a shutdown of the whole router, in addition to the g-shut of all EBGP sessions, there is a need to g-shut the routes originated by this router (e.g, BGP aggregates redistributed from other protocols, including static routes). This can be performed by tagging such routes with the g-shut community. Thanks, Regards, --Bruno > Thanks, > Jakob. > > > > -Original Message- > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Will Hargrave > > Sent: Saturday, June 24, 2017 3:46 AM > > To: Job Snijders <j...@ntt.net> > > Cc: grow@ietf.org > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > > > On 22 Jun 2017, at 21:47, Job Snijders wrote: > > > > Hi all, a few comments below: > > > > > NEW (in Pre-configuration): > > >On each ASBR supporting the g-shut procedure, an inbound BGP route > > >policy is applied on all BGP sessions of the ASBR, that: > > >o matches the g-shut community > > >o sets the LOCAL_PREF attribute of the paths tagged with the > > > g-shut > > > community to a low value (a value of zero is recommended). > > > > Since we define some terminology in 2., we should use it: > > > > On each g-shut neighbor ASBR, an inbound BGP route policy is applied on > > all BGP sessions of the ASBR, that: > > > > > > I don’t think the ‘neighbor’ / ‘initiator’ terminology is very > > clear, but I struggle to find more appropriate terms right now. > > ‘g-shut receiver’? > > > > > NEW (in Operations at maintenance time): > > >On the g-shut initiator, upon maintenance time, it is required to: > > >o apply an outbound BGP route policy on the maintained EBGP > > > session > > > to tag the paths propagated over the session with the g-shut
Re: [GROW] draft-ietf-grow-bgp-gshut
Hi Job, Thanks for the comments. Please see inline [Bruno] > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, 2017 10:47 PM > > Dear working group, > > > > BGP g-shut (possible action for Bruno et al) > > > > > > > > > Bruno promised a new, fresh version of draft-ietf-grow-bgp-gshut which > > > would focus on the rfc1997 well-known community 65535:0 - I would > > > appreciate if this is posted at some point so we can make an Informative > > > reference to a non-zombie draft. NTT (as2914) & Coloclue (as8283) > > > implemented experimental rfc1997 gshut support for customers and it > > > appears to work as advertise (no pun intended ;-). > > > > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-07 has just been > > posted and > addresses the above point. > > > > As previously discussed on the list, the main technical change is the > > focus, for the eBGP signaling, on the use of a well-known BGP > > community. In other word, the alternative option to use a > > non-transitive community has been removed, following latest IDR > > discussion on community and the lack of implementation (hence IDR WG > > progress) of draft-ietf-idr-reserved-extended-communities / > > draft.ietf-idr-as4octet-extcomm-generic-subtype. As a benefit, this > > draft is now aligned with: - the BGP gshut/planned maintenance > > implementations disclosed on this list > > https://mailarchive.ietf.org/arch/msg/grow/ReJtavkJDlyrDo5qoD7u9iJDLXs > > - the deployed usage > > fantastic! > > I have some comments: > > Summary: > > I think that the neighbor ASBR should _not_ strip the GSHUT well-known > community, additionally, the place where the low local preference is set > should move closer to the initiator of the gshut. Instead of setting > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set > during application of the local policy on the relevant Adj-RIB-In. [Bruno] Will answer these technical points in separate threads. > The above changes would align with current operational practises, i've > learned from numerous people that they use AS-specific "lower LOCAL_PREF > as low as possible" communities from their peers and upstream providers > to trigger path hunting. In current deployments those communities are > often not stripped (in context of IBGP), and the lower LOCAL_PREF is set > on "ebgp-in" rather then "ibgp-out". > > Optionally an appendix with an actual router configuration can be > supplied, if there is interest in this I am happy to provide that. [Bruno] I think this would be useful. (although CLI change over time) > - > Suggestions: > > OLD Abstract: >This draft describes operational procedures aimed at reducing the >amount of traffic lost during planned maintenances of routers or >links, involving the shutdown of BGP peering sessions. > NEW Abstract: >This draft describes operational procedures aimed at reducing the >amount of traffic lost during planned maintenances of routers or >links, involving the shutdown of BGP peering sessions. Additionally >this document describes the use of a well-known Border Gateway >Protocol (BGP) community to signal that a graceful shutdown has been >initiated for the tagged prefix. [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, called gshut, to signal the graceful shutdown of paths to other Autonomous Systems." > OLD (in introduction): >Still, it explains why reserving a community value for the purpose of >BGP session graceful shutdown would reduce the management overhead >bound with the solution. It would also allow vendors to provide an >automatic graceful shutdown mechanism that does not require any >router reconfiguration at maintenance time. > NEW (in introduction): >This document defines a well-known community value for the purpose of >reducing the management overhead of gracefully shutting down BGP >sessions. The well-known community allows implementers to provide an >automated graceful shutdown mechanism that does not require any >router reconfiguration at maintenance time. [Bruno] OK. > OLD (in Make before break convergence: g-shut): >This section describes configurations and actions to be performed for >the graceful shutdown of eBGP sessions, iBGP sessions or a whole BGP >speaker. > NEW: >This section describes configurations and actions to be performed for >the graceful shutdown of BGP sessions. [Bruno] OK. > OLD (in Pre-configuration): >On each ASBR supporting the g-shut procedure, an outbound BGP route >policy is applied on all iBGP sessions of the ASBR, that: >o matches the g-shut community >o sets the LOCAL_PREF attribute of the paths tagged with the g-shut > community to a low value >o removes the g-shut community
Re: [GROW] draft-ietf-grow-bgp-gshut
I agree with Job's proposals. In particular, the removal of the g-shut community should be carefully considered. On the one hand, the g-shut community may not be originated by the neighbor and is valid wherever the route may be advertised. On the other hand, in the IPv4 and IPv6 address families, if an alternate route is not available, the g-shut community can be spread throughout all routers in the world, causing excessive churn. I understand that this issue has been discussed in the working group, but the concerns should be written into the RFC. I think section 6 for link up should stay. The cases desctibed are real, whether corner or not. It does not even need route reflectors to happen. All that is required is for a withdraw message to be processed by a router before the new announcement. Consider: R2 is announcing the best-path. R1 was under maintenance and is coming up. R1 advertises the new path to R2. R2 withdraws its path. R1 advertises the new path to R3. R3 receives or processes the withdrawal from R2 before the advertisement from R1. "4.2.3 Router g-shut" should make it clear that the behavior is in addition to the behavior of the links being shut down. Shutting down a router means all its links are going down too. In addition, the gshut community should be tagged onto the originated routes. Thanks, Jakob. > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Will Hargrave > Sent: Saturday, June 24, 2017 3:46 AM > To: Job Snijders <j...@ntt.net> > Cc: grow@ietf.org > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > On 22 Jun 2017, at 21:47, Job Snijders wrote: > > Hi all, a few comments below: > > > NEW (in Pre-configuration): > >On each ASBR supporting the g-shut procedure, an inbound BGP route > >policy is applied on all BGP sessions of the ASBR, that: > >o matches the g-shut community > >o sets the LOCAL_PREF attribute of the paths tagged with the > > g-shut > > community to a low value (a value of zero is recommended). > > Since we define some terminology in 2., we should use it: > > On each g-shut neighbor ASBR, an inbound BGP route policy is applied on > all BGP sessions of the ASBR, that: > > > I don’t think the ‘neighbor’ / ‘initiator’ terminology is very > clear, but I struggle to find more appropriate terms right now. > ‘g-shut receiver’? > > > NEW (in Operations at maintenance time): > >On the g-shut initiator, upon maintenance time, it is required to: > >o apply an outbound BGP route policy on the maintained EBGP > > session > > to tag the paths propagated over the session with the g-shut > > community. This will trigger the BGP implementation to re- > > advertise all active routes previously advertised, and tag them > > with the g-shut community. > >o apply an inbound BGP route policy on the maintained EBGP session > > to tag the paths received over the session with the g-shut > > community and set a low LOCAL_PREF value. > > ‘Maintained’ (in ‘maintained EBGP session’) is not a useful word > to use here, since ultimately the session is not to be maintained at > all! Perhaps “eBGP session” is clear enough, or use ‘impacted’ > or ‘relevant’. > > > I have a further comment on section 6. Link Up cases. I rather feel this > is a separate body of work, and belongs in some sort of ‘gshut-bis’ > where we can extend on this technique. Certainly there is nothing in the > rest of the draft which prevents the use of gshut technique to improve > link-up behaviour, so I would remove sections 6/6.1/6.2 for clarity. > > Behaviour in relation to next-hop reachability across a multi-access > network is of particular interest to me as an IXP operator, and is > probably a whole topic of its own. > > > -- > Will Hargrave > Technical Director > LONAP Ltd > +44 114 303 > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
On 22 Jun 2017, at 21:47, Job Snijders wrote: Hi all, a few comments below: NEW (in Pre-configuration): On each ASBR supporting the g-shut procedure, an inbound BGP route policy is applied on all BGP sessions of the ASBR, that: o matches the g-shut community o sets the LOCAL_PREF attribute of the paths tagged with the g-shut community to a low value (a value of zero is recommended). Since we define some terminology in 2., we should use it: On each g-shut neighbor ASBR, an inbound BGP route policy is applied on all BGP sessions of the ASBR, that: I don’t think the ‘neighbor’ / ‘initiator’ terminology is very clear, but I struggle to find more appropriate terms right now. ‘g-shut receiver’? NEW (in Operations at maintenance time): On the g-shut initiator, upon maintenance time, it is required to: o apply an outbound BGP route policy on the maintained EBGP session to tag the paths propagated over the session with the g-shut community. This will trigger the BGP implementation to re- advertise all active routes previously advertised, and tag them with the g-shut community. o apply an inbound BGP route policy on the maintained EBGP session to tag the paths received over the session with the g-shut community and set a low LOCAL_PREF value. ‘Maintained’ (in ‘maintained EBGP session’) is not a useful word to use here, since ultimately the session is not to be maintained at all! Perhaps “eBGP session” is clear enough, or use ‘impacted’ or ‘relevant’. I have a further comment on section 6. Link Up cases. I rather feel this is a separate body of work, and belongs in some sort of ‘gshut-bis’ where we can extend on this technique. Certainly there is nothing in the rest of the draft which prevents the use of gshut technique to improve link-up behaviour, so I would remove sections 6/6.1/6.2 for clarity. Behaviour in relation to next-hop reachability across a multi-access network is of particular interest to me as an IXP operator, and is probably a whole topic of its own. -- Will Hargrave Technical Director LONAP Ltd +44 114 303 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Dear working group, > > BGP g-shut (possible action for Bruno et al) > > > > > > Bruno promised a new, fresh version of draft-ietf-grow-bgp-gshut which > > would focus on the rfc1997 well-known community 65535:0 - I would > > appreciate if this is posted at some point so we can make an Informative > > reference to a non-zombie draft. NTT (as2914) & Coloclue (as8283) > > implemented experimental rfc1997 gshut support for customers and it > > appears to work as advertise (no pun intended ;-). > > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-07 has just been posted > and addresses the above point. > > As previously discussed on the list, the main technical change is the > focus, for the eBGP signaling, on the use of a well-known BGP > community. In other word, the alternative option to use a > non-transitive community has been removed, following latest IDR > discussion on community and the lack of implementation (hence IDR WG > progress) of draft-ietf-idr-reserved-extended-communities / > draft.ietf-idr-as4octet-extcomm-generic-subtype. As a benefit, this > draft is now aligned with: - the BGP gshut/planned maintenance > implementations disclosed on this list > https://mailarchive.ietf.org/arch/msg/grow/ReJtavkJDlyrDo5qoD7u9iJDLXs > - the deployed usage fantastic! I have some comments: Summary: I think that the neighbor ASBR should _not_ strip the GSHUT well-known community, additionally, the place where the low local preference is set should move closer to the initiator of the gshut. Instead of setting the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set during application of the local policy on the relevant Adj-RIB-In. The above changes would align with current operational practises, i've learned from numerous people that they use AS-specific "lower LOCAL_PREF as low as possible" communities from their peers and upstream providers to trigger path hunting. In current deployments those communities are often not stripped (in context of IBGP), and the lower LOCAL_PREF is set on "ebgp-in" rather then "ibgp-out". Optionally an appendix with an actual router configuration can be supplied, if there is interest in this I am happy to provide that. - Suggestions: OLD Abstract: This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. NEW Abstract: This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. Additionally this document describes the use of a well-known Border Gateway Protocol (BGP) community to signal that a graceful shutdown has been initiated for the tagged prefix. OLD (in introduction): Still, it explains why reserving a community value for the purpose of BGP session graceful shutdown would reduce the management overhead bound with the solution. It would also allow vendors to provide an automatic graceful shutdown mechanism that does not require any router reconfiguration at maintenance time. NEW (in introduction): This document defines a well-known community value for the purpose of reducing the management overhead of gracefully shutting down BGP sessions. The well-known community allows implementers to provide an automated graceful shutdown mechanism that does not require any router reconfiguration at maintenance time. OLD (in Make before break convergence: g-shut): This section describes configurations and actions to be performed for the graceful shutdown of eBGP sessions, iBGP sessions or a whole BGP speaker. NEW: This section describes configurations and actions to be performed for the graceful shutdown of BGP sessions. OLD (in Pre-configuration): On each ASBR supporting the g-shut procedure, an outbound BGP route policy is applied on all iBGP sessions of the ASBR, that: o matches the g-shut community o sets the LOCAL_PREF attribute of the paths tagged with the g-shut community to a low value o removes the g-shut community from the paths. o optionally, adds an AS specific g-shut community on these paths to indicate that these are to be withdrawn soon. If some ingress ASBRs reset the LOCAL_PREF attribute, this AS specific g-shut community will be used to override other LOCAL_PREF preference changes. NEW (in Pre-configuration): On each ASBR supporting the g-shut procedure, an inbound BGP route policy is applied on all BGP sessions of the ASBR, that: o matches the g-shut community o sets the LOCAL_PREF attribute of the paths tagged with the g-shut community to a low value (a value of zero is recommended). OLD (in Operations at maintenance time): On the g-shut initiator, upon maintenance time, it is
[GROW] draft-ietf-grow-bgp-gshut
Hi all, > From: Job Snijders [mailto:j...@ntt.net] > Sent: Friday, May 26, 2017 4:05 PM > > Hi GROW, > > I've compiled a todo list to outline the next steps for the > draft-ietf-grow-bgp-session-culling document. > [...] > BGP g-shut (possible action for Bruno et al) > > > Bruno promised a new, fresh version of draft-ietf-grow-bgp-gshut which > would focus on the rfc1997 well-known community 65535:0 - I would > appreciate if this is posted at some point so we can make an Informative > reference to a non-zombie draft. NTT (as2914) & Coloclue (as8283) > implemented experimental rfc1997 gshut support for customers and it > appears to work as advertise (no pun intended ;-). https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-07 has just been posted and addresses the above point. As previously discussed on the list, the main technical change is the focus, for the eBGP signaling, on the use of a well-known BGP community. In other word, the alternative option to use a non-transitive community has been removed, following latest IDR discussion on community and the lack of implementation (hence IDR WG progress) of draft-ietf-idr-reserved-extended-communities / draft.ietf-idr-as4octet-extcomm-generic-subtype. As a benefit, this draft is now aligned with: - the BGP gshut/planned maintenance implementations disclosed on this list https://mailarchive.ietf.org/arch/msg/grow/ReJtavkJDlyrDo5qoD7u9iJDLXs - the deployed usage Thanks to Job for the in-depth review, comments, and reminders to update the draft. --Bruno _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
On Tue, Jun 13, 2017 at 07:07:24AM +, bruno.decra...@orange.com wrote: > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Tuesday, June 13, 2017 > > 1:41 AM > > > > 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. I've used the -04 XML file which was luckily enough was posted [1]. I've editted the file to comply with current xml2rfc standards and updated the references. It is a faithful reproduction of what the XML for -06 could've been. It is now on github: https://github.com/bgp/draft-ietf-grow-bgp-gshut Kind regards, Job [1]: https://tools.ietf.org/id/draft-ietf-grow-bgp-gshut-04.xml ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
there is an rfc to xml converter somewhere. i once used it. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Job, > From: Job Snijders [mailto:j...@ntt.net] > 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 +, 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
Re: [GROW] draft-ietf-grow-bgp-gshut status?
On Wed, Mar 15, 2017 at 03:21:18PM +, bruno.decra...@orange.com wrote: > > 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. I have no issues with a well known RFC 1997 community. The generic as4-octet could be used as well. It's just an extended community code point. End of the day, it's whatever gets the feature shipped.[1] -- Jeff [1] You've been able to do arbitrary extended communities in Junos for a while. They don't necessarily display right in show commands, but the transitivity flag is respected. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 2:09 PM To: DECRAENE Bruno IMT/OLN Cc: Ben Maddison; grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? [Bruno] The benefit of using a well-known community is that everyone uses the same. Otherwise, the operator shutting down/reloading a node with 50 EBGP sessions would need to attach 50 different communities. Nope. You send only one .. the one you told your peers that means your g-shut. But to respect your peer's g-shuts you may end up matching on a few ... not that each VPN site will have it's own but your upstreams or peers sure could. [Bruno2] I hope that in the end, we’ll agree that using a single community for all EBGP sessions is just easier. But in the worst case, we don’t have to. Registration policy is FCFS and the g-shut community is already allocated. In any case as far as RFC 1997 there was big discussion in July and August of 2008 in IDR started by Dave on how to reserve new values. I do not recall what was the final outcome of that. https://mailarchive.ietf.org/arch/msg/idr/U6mR4hST3ZX-Ai5jyRKabhB9n8o [Bruno2] https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml Range [https://www.iana.org/assignments/_support/sort_none.gif] Registration Procedures [https://www.iana.org/assignments/_support/sort_none.gif] 0x-0x8000 First Come First Served 0x8001-0x Standards Action _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
> [Bruno] The benefit of using a well-known community is that everyone uses > the same. Otherwise, the operator shutting down/reloading a node with 50 > EBGP sessions would need to attach 50 different communities. > Nope. You send only one .. the one you told your peers that means your g-shut. But to respect your peer's g-shuts you may end up matching on a few ... not that each VPN site will have it's own but your upstreams or peers sure could. In any case as far as RFC 1997 there was big discussion in July and August of 2008 in IDR started by Dave on how to reserve new values. I do not recall what was the final outcome of that. https://mailarchive.ietf.org/arch/msg/idr/U6mR4hST3ZX-Ai5jyRKabhB9n8o ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi, On Fri, Mar 17, 2017 at 01:52:56PM +0100, Robert Raszuk wrote: > > > ???Not that long ago we went via tsunami ???of IDR on and offline emails > > when > > > discussing large communities which contained "operators" voice stating > > > *NO* to any well known or predefined meaning to the communities nor > > > welcomed any predefined actions associated with the communities. > > > > You're taking this out of context. We disagreed to having a fixed format > > and fixed rules what to do with large communities. > > ???Large communities have fixed format. There is no TLV there. ???Which > proposal was more of fixed format then large comms ??? "fixed format" and "there is no flexibily in *usage*" is not the same thing. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Robert, From: Robert Raszuk Sent: Friday, March 17, 2017 12:30 PM Hi Ben & Bruno, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ? If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. [Bruno] The benefit of using a well-known community is that everyone uses the same. Otherwise, the operator shutting down/reloading a node with 50 EBGP sessions would need to attach 50 different communities. And update this list of communities as peer are configured/unconfigured. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. [Bruno] - The sending of community may be automated just like the sending of another message. - Again, whatever type of message you use over the EBGP session, on the receiving peer it needs to be translated in deprefering each route and sending N updates to peers. And yes, some peers may converge quicker than others, but there is nothing you can do about this. A clever implementation could use heuristic to evaluate the BGP convergence of its peer (e.g. by measuring inbound traffic). But typically a single timer is enough, because in all cases, people will not wait/delay their maintenance forever. So if they can afford to wait 5 minutes, they wait 5 minutes and then close the BGP session regardless the speed of their peer. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. Best, R. On Fri, Mar 17, 2017 at 12:14 PM, Ben Maddison <b...@workonline.co.za<mailto:b...@workonline.co.za>> wrote: Hi Robert, There is no requirement that peers implement anything at all. In the absence of any configured policy, the community gets ignored, and no action is taken prior to shutdown – which is exactly the status-quo without the draft, so no harm done. Each network is free to implement whatever ingress policy is sensible in their own view, which should be to take the same action as when receiving an IXP list mail saying “we’re gonna shut x,y,z down shortly…”. The difference is they can now handle that in BGP policy to avoid the manual NOC activity. Also, there is no additional code required (assuming support for 1997) in order to implement the bare bones of the functionality – e.g. match on 65535:0, set local-pref. The automation features around it (such as neighbor shutdown graceful on XE) need new software, but are also trivial to recreate in an in house EMS if people are that pathological about touching their routers. The only problem scenario that I can see is where someone is using 65535:0 for a different purpose in eBGP. But some people are beyond help! Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000<tel:+27%2021%20200%209000> Mobile: +27 (0) 82 415 5545<tel:+27%2082%20415%205545> Email: b...@workonline.co.za<mailto:b...@workonline.co.za> SIP: b...@workonline.co.za<mailto:b...@workonline.co.za> [Workonline Communications]<http://www.workonline.co.za/> From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 12:39 PM To: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? Hi Bruno, [Bruno] The goal was to be able to use gshut even if both EBGP peer are not enhanced to support it. The benefit of flagging routes with a community is that gshut may be implemented on vanilla routers using a BGP route map/policy. Sure thing. However peers need to be consistently configured with the same policy to understand the meaning of the community. If you think this is easy - great. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years. Well it is not router replacement .. it is software upgrade. But sure if you can convince peers to setup same error free policy that is perfect. No objections at all :). Best, R. _ Ce
Re: [GROW] draft-ietf-grow-bgp-gshut status?
> > > ???Not that long ago we went via tsunami ???of IDR on and offline emails > when > > discussing large communities which contained "operators" voice stating > > *NO* to any well known or predefined meaning to the communities nor > > welcomed any predefined actions associated with the communities. > > You're taking this out of context. We disagreed to having a fixed format > and fixed rules what to do with large communities. > Large communities have fixed format. There is no TLV there. Which proposal was more of fixed format then large comms ??? And no proposal suggested only fixed rules. Wide Communities supported TLV and local rules exactly as you would do with current large comms. Also they proposed in parallel to full operator's flexibility set of well known values as documented here: https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02 Thx, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi, On Fri, Mar 17, 2017 at 01:33:34PM +0100, Robert Raszuk wrote: > > ???> ??? > > The primary benefit is the use of a well-known community > > > > > ???Not that long ago we went via tsunami ???of IDR on and offline emails when > discussing large communities which contained "operators" voice stating > *NO* to any well known or predefined meaning to the communities nor > welcomed any predefined actions associated with the communities. You're taking this out of context. We disagreed to having a fixed format and fixed rules what to do with large communities. Nobody objected to having a set of well-known communities for a well-known purpose (as can be seen by the consensus on 7999). But this is not what was discussed in large community context. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
> > > The primary benefit is the use of a well-known community > > Not that long ago we went via tsunami of IDR on and offline emails when discussing large communities which contained "operators" voice stating *NO* to any well known or predefined meaning to the communities nor welcomed any predefined actions associated with the communities. Everyone wants to assign his own and inform interested parties about such meaning. Has that already changed just few weeks after the RFC was issued :-) ? 1.the peer initiating the shutdown (A) sends its peer (B) a > NOTIFICATION with a new error code that means “I’m going away shortly, > please start re-converging and let me know when you’re done”. > > 2.B attempts to re-converge around the paths learnt from A (possibly > needing to initiate a route-refresh in the process?), and once it no longer > has any of those routes in its FIB sends A back a further NOTIFICATION > saying “I’m finished” and then shuts the session down. > > 3.If A hasn’t heard back within a configurable timeout, then it yanks > the session anyway. > Yes that's good summary. > If so, that sounds like a hell of a lot of new protocol spec > I don't think this is that complex. And use of NOTIFICATION message was just an example. One could also put it in new OPERATIONAL message. Anyhow just a suggestion how to improve protocol if there is real need. If this however as you said "fairly marginal issue" then let's not bother. Cheers, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Robert, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ? If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. [BEN] Nothing is stopping them. The primary benefit is the use of a well-known community that can be matched in generically constructed policies without prior knowledge of whether the peer makes use of this procedure, and what community they use for the purpose if they do. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. [BEN] From a quick read of RFC4271: “A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.” I can’t find any updates that contradict that. If I understand your suggestion correctly, you mean: 1.the peer initiating the shutdown (A) sends its peer (B) a NOTIFICATION with a new error code that means “I’m going away shortly, please start re-converging and let me know when you’re done”. 2.B attempts to re-converge around the paths learnt from A (possibly needing to initiate a route-refresh in the process?), and once it no longer has any of those routes in its FIB sends A back a further NOTIFICATION saying “I’m finished” and then shuts the session down. 3.If A hasn’t heard back within a configurable timeout, then it yanks the session anyway. If so, that sounds like a hell of a lot of new protocol spec and router code, to solve a fairly marginal issue. The determinism that you gain only goes one hop into the remote network (as B’s other peers may still be converging when the session goes down), and is therefore only guaranteed to be useful if that network tunnels between ASBRs. It is also unclear what a BGP speaker that didn’t understand the new code would do when receiving a NOTIFICATION that wasn’t immediately followed by a session reset. I suspect that would vary widely by implementation and be the source of some fairly nasty bugs! Compared to a line in an RFC suggesting reasonable timer values between gshut and shutdown, this seems to be a lot more work for very little benefit. Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: b...@workonline.co.za<mailto:b...@workonline.co.za> SIP: b...@workonline.co.za<sip:b...@workonline.co.za> [Workonline Communications]<http://www.workonline.co.za/> From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 1:30 PM To: Ben Maddison <b...@workonline.co.za> Cc: bruno.decra...@orange.com; grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? Hi Ben & Bruno, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ? If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. Best, R. On Fri, Mar 17, 2017 at 12:14 PM, Ben Maddison <b...@workonline.co.za<mailto:b...@workonline.co.za>> wrote: Hi Robert, There is no requirement that peers implement anything at all. In the absence of any configured policy, the community gets ignored, and no action is taken prior to shutdown – which is exactly the status-quo without the dr
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Ben & Bruno, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ? If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. Best, R. On Fri, Mar 17, 2017 at 12:14 PM, Ben Maddison <b...@workonline.co.za> wrote: > Hi Robert, > > > > There is no requirement that peers implement anything at all. In the > absence of any configured policy, the community gets ignored, and no action > is taken prior to shutdown – which is exactly the status-quo without the > draft, so no harm done. Each network is free to implement whatever ingress > policy is sensible in their own view, which should be to take the same > action as when receiving an IXP list mail saying “we’re gonna shut x,y,z > down shortly…”. The difference is they can now handle that in BGP policy to > avoid the manual NOC activity. > > > > Also, there is no additional code required (assuming support for 1997) in > order to implement the bare bones of the functionality – e.g. match on > 65535:0, set local-pref. > > The automation features around it (such as neighbor shutdown graceful on > XE) need new software, but are also trivial to recreate in an in house EMS > if people are that pathological about touching their routers. > > > > The only problem scenario that I can see is where someone is using 65535:0 > for a different purpose in eBGP. But some people are beyond help! > > > > Cheers, > > > > Ben Maddison > > > > *Director* > > Workonline Communications (Pty) Ltd > > > > Office: +27 (0) 21 200 9000 <+27%2021%20200%209000> > > Mobile: +27 (0) 82 415 5545 <+27%2082%20415%205545> > > Email: b...@workonline.co.za > > SIP: b...@workonline.co.za > > > > [image: Workonline Communications] <http://www.workonline.co.za/> > > > > *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Friday, March 17, 2017 12:39 PM > *To:* bruno.decra...@orange.com > *Cc:* grow@ietf.org > *Subject:* Re: [GROW] draft-ietf-grow-bgp-gshut status? > > > > Hi Bruno, > > > > [Bruno] The goal was to be able to use gshut even if both EBGP peer are > not enhanced to support it. The benefit of flagging routes with a community > is that gshut may be implemented on vanilla routers using a BGP route > map/policy. > > > > Sure thing. However peers need to be consistently configured with the > same policy to understand the meaning of the community. > > > > If you think this is easy - great. > > > > Incremental deployment in a benefit, in particular between > AS/organisations, and in particular on small/low end routers which are not > replaced every 4 years. > > > > Well it is not router replacement .. it is software upgrade. But sure if > you can convince peers to setup same error free policy that is perfect. No > objections at all :). > > > > Best, > R. > > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Robert, There is no requirement that peers implement anything at all. In the absence of any configured policy, the community gets ignored, and no action is taken prior to shutdown – which is exactly the status-quo without the draft, so no harm done. Each network is free to implement whatever ingress policy is sensible in their own view, which should be to take the same action as when receiving an IXP list mail saying “we’re gonna shut x,y,z down shortly…”. The difference is they can now handle that in BGP policy to avoid the manual NOC activity. Also, there is no additional code required (assuming support for 1997) in order to implement the bare bones of the functionality – e.g. match on 65535:0, set local-pref. The automation features around it (such as neighbor shutdown graceful on XE) need new software, but are also trivial to recreate in an in house EMS if people are that pathological about touching their routers. The only problem scenario that I can see is where someone is using 65535:0 for a different purpose in eBGP. But some people are beyond help! Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: b...@workonline.co.za<mailto:b...@workonline.co.za> SIP: b...@workonline.co.za<sip:b...@workonline.co.za> [Workonline Communications]<http://www.workonline.co.za/> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 12:39 PM To: bruno.decra...@orange.com Cc: grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? Hi Bruno, [Bruno] The goal was to be able to use gshut even if both EBGP peer are not enhanced to support it. The benefit of flagging routes with a community is that gshut may be implemented on vanilla routers using a BGP route map/policy. Sure thing. However peers need to be consistently configured with the same policy to understand the meaning of the community. If you think this is easy - great. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years. Well it is not router replacement .. it is software upgrade. But sure if you can convince peers to setup same error free policy that is perfect. No objections at all :). Best, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Robert, From: Robert Raszuk Hi Bruno, [Bruno] The goal was to be able to use gshut even if both EBGP peer are not enhanced to support it. The benefit of flagging routes with a community is that gshut may be implemented on vanilla routers using a BGP route map/policy. Sure thing. However peers need to be consistently configured with the same policy to understand the meaning of the community. If you think this is easy - great. [Bruno2] On the receiver side, this is regular use of BGP community between 2 ASes. I’m not trying to evaluate simplicity or easiness. That being said, community is a pretty common tool, including between ASes. So definitely doable IMHO. On the sender side (gshut initiator), there is a need to attach a new community, e.g. though the application of the gshut BGP policy. Difficulty is implementation dependent. This part is clearly easier when implemented by the OS as part of the shutdown of the BGP session. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years. Well it is not router replacement .. it is software upgrade. [Bruno2] I do make the distinction. Indeed, this is a control plane only feature, which can be implemented by a software upgrade. Yet, even software upgrade may be costly when it involves thousands of CE routers in 1000 of locations and 100s of actors. Especially for small CE routers which do not support High Availability features. Then you have “legacy” plateform, i.e. vendors not providing software upgrade anymore. But sure if you can convince peers to setup same error free policy that is perfect. No objections at all :). [Bruno2] I do believe that peers are capable of configuring a BGP policy matching one BGP community. My intention is not to convince unwilling peers, but to provide this as a service for peers willing to reduce the impact of a BGP session shutdown. Actually, the request was coming from my peers which were affected by my maintenance operations requiring the eBGP session shutdown. Best, Bruno Best, R. _ 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Bruno, [Bruno] The goal was to be able to use gshut even if both EBGP peer are not > enhanced to support it. The benefit of flagging routes with a community is > that gshut may be implemented on vanilla routers using a BGP route > map/policy. > Sure thing. However peers need to be consistently configured with the same policy to understand the meaning of the community. If you think this is easy - great. > Incremental deployment in a benefit, in particular between > AS/organisations, and in particular on small/low end routers which are not > replaced every 4 years. > Well it is not router replacement .. it is software upgrade. But sure if you can convince peers to setup same error free policy that is perfect. No objections at all :). Best, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Hi Robert, Please see inline [Bruno] From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 9:42 AM To: DECRAENE Bruno IMT/OLN Cc: grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? 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 ? [Bruno] The goal was to be able to use gshut even if both EBGP peer are not enhanced to support it. The benefit of flagging routes with a community is that gshut may be implemented on vanilla routers using a BGP route map/policy. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years. 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. [Bruno] There is no issue. The goal _is_ to trigger BGP path hunting in search for the back up path, before shutting down the BGP session: - If the remote EBGP peer is already aware of the back up route, the message/churn is not propagated in the peer’s ASes not beyond - If the remote EBGP peer is not aware of the back up route, the message/churn is indeed propagated in the peer’s ASes and possibly beyond, but that is the goal and the feature. Note that this is also the case when you perform a vanilla BGP shut. There is no free lunch: you do need to search for the back up paths. Plus with gshut, you replace “urgent” BGP message by non-urgent BGP messages. Or do you want to came back to concept of defining a beacon prefix acting as semaphore for entire session :) [Bruno] No. This is not what is described in the draft. Cheers, --Bruno Cheers, R. On Wed, Mar 15, 2017 at 4:26 PM, <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Thanks for the useful feedback. --Bruno > -Original Message- > From: Ben Maddison > [mailto:b...@workonline.co.za<mailto:b...@workonline.co.za>] > Sent: Wednesday, March 15, 2017 4:23 PM > To: Job Snijders; DECRAENE Bruno IMT/OLN > Cc: grow@ietf.org<mailto:grow@ietf.org> > 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<tel:%2B27%20%280%29%2021%20200%209000> > Mobile: +27 (0) 82 415 5545<tel:%2B27%20%280%29%2082%C2%A0415%205545> > Email: b...@workonline.co.za<mailto:b...@workonline.co.za> > SIP: b...@workonline.co.za<mailto:b...@workonline.co.za> > > > > > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On > Behalf Of Job Snijders > Sent: Wednesday, March 15, 2017 4:54 PM > To: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> > Cc: grow@ietf.org<mailto:grow@ietf.org> > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? > > Hi Bruno, > > On Wed, Mar 15, 2017 at 02:00:37PM +, > bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote: > > > From: GROW [mailto:grow-boun...@ietf.org<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 > >
Re: [GROW] draft-ietf-grow-bgp-gshut status?
Thanks for the useful feedback. --Bruno > -Original Message- > From: Ben Maddison [mailto:b...@workonline.co.za] > Sent: Wednesday, March 15, 2017 4:23 PM > To: Job Snijders; DECRAENE Bruno IMT/OLN > Cc: grow@ietf.org > 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: b...@workonline.co.za > SIP: b...@workonline.co.za > > > > > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders > Sent: Wednesday, March 15, 2017 4:54 PM > To: bruno.decra...@orange.com > Cc: grow@ietf.org > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? > > 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. > > 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
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: b...@workonline.co.za SIP: b...@workonline.co.za -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders Sent: Wednesday, March 15, 2017 4:54 PM To: bruno.decra...@orange.com Cc: grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? 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. 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut status?
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 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
Re: [GROW] draft-ietf-grow-bgp-gshut status?
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. 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] draft-ietf-grow-bgp-gshut status?
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? What implementatations exist? A fellow operator told me that IOS, IOS XE has support for graceful shutdown, are there others? Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] draft-ietf-grow-bgp-gshut
Robert, [Changing the title of the thread to better reflect the subject] From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, May 10, 2012 11:25 AM Hello Bruno, Excellent - this is exactly what we discussed in the past. But when I read the draft before sending email yesterday unfortunately it does not say so that clearly at all - regarding the IBGP case ;( If the draft is not clear enough, we always welcome comments. Do you have specific comments that we should add in the draft? The following section of the draft recaps the actions to be performed. 4.2.1.3. BGP implementation support for G-Shut [...] Upon a session shutdown specified as graceful by the operator, a BGP implementation supporting a g-shut feature SHOULD: 1. Update all the paths propagated over the corresponding eBGP session, tagging the GSHUT community to them. Any subsequent update sent to the session being gracefully shut down would be tagged with the GSHUT community. 2. Lower the local preference value of the paths received over the eBGP session being shut down, upon their propagation over iBGP sessions. Optionally, also tag these paths with an AS specific g-shut community. Note that alternatively, the local preference of the paths received over the eBGP session can be lowered on the g-shut initiator itself, instead of only when propagating over its iBGP sessions. At least to me, seems clear that the community is used on the eBGP side and LOCAL_PREF is used on the iBGP side. Eventually we could to the following change: - :s/local preference/LOCAL_PREF - May be start the sentence of 1. and 2. with: on the eBGP side, on the iBGP side Others comments welcomed. iBGP eBGP PE1 P PE2 == PE3 The scenario I had in mind was we are receiving errored UPDATE msg from PE3 to PE2, PE2 treats as withdraw the parsable NLRIs then for the reast the thread so far indicated to inject g-shut community. While injecting G_SHUT would not hurt and would allow for example PE1 to propagate it downstream in the same time error handling draft should IMHO me explicit to say we are advertising from PE2 towards it's AS with lowest LOCAL_PREF and G_SHUT. Example: 4.2.1.1. Pre-configuration On each ASBR supporting the g-shut procedure, an outbound BGP route policy is applied on all iBGP sessions of the ASBR, that: omatches the g-shut community osets the local-pref of the paths tagged with the g-shut community to a low value Here in out case we do not match on g-shut as g-shut is not received from EBGP. Also perhaps it would be great to just copy and paste the quote from the previous email directly to a deployment section of the draft. Sorry the given the amount of emails, could you please be a little more specific? (e.g. which quote). Thanks for the useful comments. Best regards, Bruno Best regards, R. Robert, From: Robert Raszuk Sent: Wednesday, May 09, 2012 11:00 PM Jeff, I do not understand why we are not going to re-advertise good routes with lowest local preference which would not result in holes of some boxes understanding g-shut community and some not. What you propose (using LOCAL_PREF) is what the g-shut draft also propose. In fact I spoke to Bruno in the past on that and I was hoping we all converged that g-shut community would be used only on the EBGP side to indicate to the peer that it should in turn lower local pref on his side. The g-shut community has always been used to signal the ghsut only on the eBGP side. On the iBGP side, LOCAL_PREF has always been used. Apparently g-shut draft still calls for this new community to be used both on iBGP and eBGP side. On the iBGP side, LOCAL_PREF is used to lower the preference of the g-shut draft. In _addition_ to this, the g-shut community is attached for _informational_ purpose. Because some AS internal BGP policy may have a need to know that the route is being g-shut. And it's cleaner to use a community to provide the root cause rather than try to guess from the low LOCAL_PREF the root cause. Regards, Bruno Regards, R. On Wed, May 09, 2012 at 03:32:52PM -0500, Tony Li wrote: Understood. I have no issues with withdrawn routes. The issue is with g- shut routes that continue to sink traffic. Perhaps I'm unclear on your reservations. If we don't go through something like graceful shutdown and leave the peering session up, we're potentially going to pull significantly more traffic toward the bad peering session than if we didn't do such a thing. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Bruno, 2. Lower the local preference value of the paths received over the eBGP session being shut down, upon their propagation over iBGP sessions. Looking at the definition of upon: upon - immediately or very soon after http://dictionary.reference.com/browse/upon What is the point of lowering local pref after their propagation over ibgp session ? To repropagate again ? Shouldn't it s/upon/before/ ? r. Robert, [Changing the title of the thread to better reflect the subject] From: Robert Raszuk [mailto:rob...@raszuk.net]Sent: Thursday, May 10, 2012 11:25 AM Hello Bruno, Excellent - this is exactly what we discussed in the past. But when I read the draft before sending email yesterday unfortunately it does not say so that clearly at all - regarding the IBGP case ;( If the draft is not clear enough, we always welcome comments. Do you have specific comments that we should add in the draft? The following section of the draft recaps the actions to be performed. 4.2.1.3. BGP implementation support for G-Shut [...] Upon a session shutdown specified as graceful by the operator, a BGP implementation supporting a g-shut feature SHOULD: 1. Update all the paths propagated over the corresponding eBGP session, tagging the GSHUT community to them. Any subsequent update sent to the session being gracefully shut down would be tagged with the GSHUT community. 2. Lower the local preference value of the paths received over the eBGP session being shut down, upon their propagation over iBGP sessions. Optionally, also tag these paths with an AS specific g-shut community. Note that alternatively, the local preference of the paths received over the eBGP session can be lowered on the g-shut initiator itself, instead of only when propagating over its iBGP sessions. At least to me, seems clear that the community is used on the eBGP side and LOCAL_PREF is used on the iBGP side. Eventually we could to the following change: - :s/local preference/LOCAL_PREF - May be start the sentence of 1. and 2. with: on the eBGP side, on the iBGP side Others comments welcomed. iBGP eBGP PE1 P PE2 == PE3 The scenario I had in mind was we are receiving errored UPDATE msg from PE3 to PE2, PE2 treats as withdraw the parsable NLRIs then for the reast the thread so far indicated to inject g-shut community. While injecting G_SHUT would not hurt and would allow for example PE1 to propagate it downstream in the same time error handling draft should IMHO me explicit to say we are advertising from PE2 towards it's AS with lowest LOCAL_PREF and G_SHUT. Example: 4.2.1.1. Pre-configuration On each ASBR supporting the g-shut procedure, an outbound BGP route policy is applied on all iBGP sessions of the ASBR, that: omatches the g-shut community osets the local-pref of the paths tagged with the g-shut community to a low value Here in out case we do not match on g-shut as g-shut is not received from EBGP. Also perhaps it would be great to just copy and paste the quote from the previous email directly to a deployment section of the draft. Sorry the given the amount of emails, could you please be a little more specific? (e.g. which quote). Thanks for the useful comments. Best regards, Bruno Best regards, R. Robert, From: Robert Raszuk Sent: Wednesday, May 09, 2012 11:00 PM Jeff, I do not understand why we are not going to re-advertise good routes with lowest local preference which would not result in holes of some boxes understanding g-shut community and some not. What you propose (using LOCAL_PREF) is what the g-shut draft also propose. In fact I spoke to Bruno in the past on that and I was hoping we all converged that g-shut community would be used only on the EBGP side to indicate to the peer that it should in turn lower local pref on his side. The g-shut community has always been used to signal the ghsut only on the eBGP side. On the iBGP side, LOCAL_PREF has always been used. Apparently g-shut draft still calls for this new community to be used both on iBGP and eBGP side. On the iBGP side, LOCAL_PREF is used to lower the preference of the g-shut draft. In _addition_ to this, the g-shut community is attached for _informational_ purpose. Because some AS internal BGP policy may have a need to know that the route is being g-shut. And it's cleaner to use a community to provide the root cause rather than try to guess from the low LOCAL_PREF the root cause. Regards, Bruno Regards, R. On Wed, May 09, 2012 at 03:32:52PM -0500, Tony Li wrote: Understood. I have no issues with withdrawn routes. The issue is with g- shut routes that continue to sink traffic. Perhaps I'm unclear on your reservations. If we don't go through something like graceful shutdown and leave the peering session up, we're potentially going to
Re: [GROW] draft-ietf-grow-bgp-gshut
Robert, From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, May 10, 2012 3:23 PM Bruno, 2. On the iBGP side, (re-) advertises the path received over the eBGP session being shutdown with a low LOCAL_PREF. Sounds good. Great. Btw what is low ? Low enough such as a backup path will be preferred. We can add this in the draft. Is 0 low ? Is 5 low ? Should we at least recommend some value if you are assuming automation in g-shut to local pref translation ? Local pref value are choosen independantly by each AS. There is no way we can pick a value -except 0 may be- which will work all the time. Even 0 may not be perfect: - 0 could already be used by others path we should never be choosen even during a ghsut. - In an Internet network, to optimize the convergence steps and the transient behavior we should/may pick the lower value assigned to the kind of relationship being gshut (e.g. peer). Indeed, if we gshut an eBGP session with a peering policy, BGP may transiently pick any path including a path from a transit provider. This would lead to a transient withdraw to peers due to policy restriction (transit path are not advertised to peer). This is suboptimal. OTOH an ISP may not want to spend time/money to optimize this... In short: local_pref value are a local policy. We can clearly discuss this in the draft, but OTOH a least one person had commented that the draft was too long and could fit in 1-2 pages. Bruno Jakob, Jeff, This is for ebgp only, not ibgp. right? I was assuming this is mostly for ibgp. If this is also for ebgp are you suggesting that we will receive from the peer a single error in UPDATE message for SAFI X/X and then it will trigger full re-advertisement of all of our routes for all of our SAFIs over such session to this peer with g-shut ? The way I read what Jeff proposed is this: 1. We are receiving N errors and just treat-as-withdraw or drop errored optional attributes when applicable 2. When N becomes more then X send g-shut to eBGP peer and lower local pref towards iBGP then re-advertise 3. After time T shut EBGP session. Questions: What is value of X and T above ? Thx, R. _ 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
