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
