Hi Ron, Let's go via your points ...
*> Rapid deactivation of all routes that resolve through an ANH when the ANH is withdrawn* I was providing real config samples indicating that the above is possible to be done today in shipping implementations. So I think while encouraging community for using next hop indirection is not a bad thing in a form of BCP calling it as "abstract next hop" vs "virtual next hop" or basically "loopback next hop" is debatable. In other words at min document should more focus on the concept of logical next hop along with options available to invalidate it as opposed to endorse any particular flavor of its implementation. *> Reduction in churn when one or more (but not all) of the BGP sessions that map to an ANH terminates* I don't think this is really accomplished or guaranteed in general. BGP advertises entire paths not just NLRIs and next hops and any changes in the best path advertised will result in churn when such best path goes away. Only in the case when all path attributes are identical such churn can be avoided, but it will also avoided today with vanilla nhs on ASBR. I do not see any extra magic ANH brings to this reduction of churn. *> Reduction the number of routes advertised to the RR* Not sure how this is reduced. By default with nhs you advertise best paths only from any ASBR. Same with ANH. If you use add-paths you may advertise more then best. So I do not see how ANH reduces RR control plane load nor I see that such reduction is really so much necessary for control plane reflector. Bottom line is that other then the above the proposed document imposes new terminology for well known best common practices of BGP deployments. Many thx, RR. On Fri, Mar 8, 2019 at 10:59 PM Ron Bonica <[email protected]> wrote: > Robert, Rafal, > > > > Can we summarize this thread by saying that abstract-nh has the following > goals (listed in order of importance) : > > > > 1. Rapid deactivation of all routes that resolve through an ANH when > the ANH is withdrawn > 2. Reduction in churn when one or more (but not all) of the BGP > sessions that map to an ANH terminates > 3. Reduction the number of routes advertised to the RR > > > > These benefits are not without cost. Because fewer routes are advertised > to the RR, some information is lost. > > > > Do I have this much right? > > > > If Rafal points out this issue in the draft, might network operators be > able to make informed decisions regarding whether the costs outweigh the > benefits in their network? > > > > Ron > > > > *From:* GROW <[email protected]> *On Behalf Of * Robert Raszuk > *Sent:* Monday, March 4, 2019 4:19 PM > *To:* Rafal Jan Szarecki <[email protected]> > *Cc:* [email protected]; Natrajan Venkataraman <[email protected]> > *Subject:* Re: [GROW] Review request for > draft-szarecki-grow-abstract-nh-scaleout-peering-00 > > > > > > [RJS] What if eBGP goes down while BFD stays up, for whatever reason? IMO > tracking BGP session state is correct think to do. > > > > Not a problem :) Add as many as you like additional tracking rules. > > > > Example: > > > > event syslog pattern “.*%BGP-5-ADJCHANGE:neighbor x.x.x.x DOWN” > > > > [RJS] It is matter of opinion. I see drawback of “READ_ONLY” – it delays > propagation of (potentially) large data set à make entire BGP convergence > slower. W/ technique described in draft I propagate large data set ASAP but > prevent other speaker from use it, until ANH become active in IGP. > > > > The main point of READ_ONLY mode is to reduce control plane churn when > paths learned first would not keep the "best path" status upon other peers > coming up and bringing better paths on the given ASBR. > > > > Besides it matters only during the initial session bring-up.. As you have > many peers giving you similar set of routes anyway it really does not > affect your reachability at all. > > > > Thx, > > R. > > > > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
