Job, > From: Job Snijders [mailto:[email protected]] > Sent: Monday, June 26, 2017 5:31 PM > > On Mon, Jun 26, 2017 at 02:14:19PM +0000, [email protected] wrote: > > > From: Job Snijders [mailto:[email protected]] > > > 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
