Number of BGP peers isn’t representative here, classical deployments would have a number of RR’s to circumvent full mesh. What counts is the total number of PEs (next-hops) that originate the prefix that is locally imported (needs to be tracked). For further optimization, only multihomed prefixes are of interest (if a PE that has a CE that is single-homed to goes away, there’s no convergence). A possible solution (discussed a number of times here) is to extract next-hop from an UPDATE, compare to the list of next-hops already learnt and establish multi-hop BFD session according to the business logic. Modern mid-high end platforms can easily run a 1000 MH BFD session @1sec
Cheers, Jeff > On Oct 13, 2021, at 10:16, Robert Raszuk <[email protected]> wrote: > > > > > How many other PEs does a BGP edge PE maximally peer with? > > Typically on IBGP side you will see 2-4 peers. Those are RRs. > > Due to no autodiscovery of BGP sessions no many people do iBGP full mesh > between PEs. > > Best, > R. > >> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) >> <[email protected]> wrote: >> Hi Peter, >> >> See inline. >> >> On 10/13/21, 4:42 AM, "Peter Psenak" <[email protected]> >> wrote: >> >> Hi Acee, >> >> On 12/10/2021 21:05, Acee Lindem (acee) wrote: >> > Speaking as WG Chairs: >> > >> > The authors of “Prefix Unreachable Announcement” have requested an >> > adoption. The crux of the draft is to signal unreachability of a >> prefix >> > across OSPF or IS-IS areas when area summarization is employed and >> > prefix is summarised. We also have “IS-IS and OSPF Extension for Event >> > Notification” which can be used to address the same use case. The >> drafts >> > take radically different approaches to the problem and the authors of >> > both drafts do not wish to converge on the other draft’s method so it >> is >> > understandable that merging the drafts really isn’t an option. >> >> just for the record, I offered authors of "Prefix Unreachable >> Announcement" co-authorship on "Event notification" draft, arguing the >> the event base solution addresses their use case in a more elegant and >> scalable way. They decided to push their idea regardless. >> >> One solution to this problem would have definitely been better. >> >> > Before an adoption call for either draft, I’d like to ask the WG: >> > >> > 1. Is this a problem that needs to be solved in the IGPs? The use case >> > offered in both drafts is signaling unreachability of a BGP peer. >> > Could this better solved with a different mechanism (e.g., BFD) >> > rather than flooding this negative reachability information across >> > the entire IGP domain? >> >> we have looked at the various options. None of the existing ones would >> fit the large scale deployment with summarization in place. Using BFD >> end to end to track reachability between PEs simply does not scale. >> >> It seems to me that scaling of BFD should be "roughly" proportional to BGP >> session scaling but I seem to be in the minority. My opinion is based on >> SDWAN tunnel scaling, where BFD is used implicitly in our solution. How many >> other PEs does a BGP edge PE maximally peer with? >> Thanks, >> Acee >> >> >> Some people believe this should be solved by BGP, but it is important to >> realize that while the problem statement at the moment is primarily >> targeted for egress PE reachability loss detection for BGP, the >> mechanism proposed is generic enough and can be used to track the peer >> reachablity loss for other cases (e.g GRE endpoint, etc) that do not >> involve BGP. >> >> We went even further and explored the option to use completely out of >> band mechanism that do not involve any existing protocols. >> >> Simply, the advantage of using IGP is that it follows the existing MPLS >> model, where the endpoint reachability is provided by IGPs. Operators >> are familiar with IGPs and know how to operate them. >> >> On top of the above, IGP event notification can find other use cases in >> the future, the mechanism defined in draft is generic enough. >> >> >> > 2. Assuming we do want to take on negative advertisement in the IGP, >> > what are the technical merits and/or detriments of the two >> approaches? >> >> we have listed some requirements at: >> >> >> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3 >> >> From my perspective the solution should be optimal in terms of amount >> of data and state that needs to be maintained, ideally separated from >> the traditional LS data. I also believe that having a generic mechanism >> to distribute events has it own merits. >> >> thanks, >> Peter >> >> > >> > We’ll reserve any further discussion to “WG member” comments on the >> two >> > approaches. >> > >> > Thanks, >> > Acee and Chris >> > >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
