Re: [GROW] draft-ietf-grow-bgp-gshut
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. If they are available to the gshut initiating router, then they are available to the other routers. Therefore a withdraw is ok. 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. I think it's better for the gshut initiating router to just advertise its next best path instead of gshut. 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. ___ 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
