> 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) <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
