Peter, Not “ALL” but these that share a service (import each other routes).
I agree that this is a brute force solution that isn’t necessarily to win a beauty contest. However this is deployable and implementable. Back to LSR scoop ;-) in general i agree with Les’ points Cheers, Jeff > On Oct 13, 2021, at 12:04, Peter Psenak <[email protected]> wrote: > > Hi Jeff, > >> On 13/10/2021 19:28, Jeff Tantsura wrote: >> 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 > > sure, but do you really want to maintain a full mesh of MH BFD sessions > between all PEs? I guess no. > > thanks, > Peter > >> 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] <mailto:[email protected]>> >>>> wrote: >>> >>> Hi Peter, >>> >>> See inline. >>> >>> On 10/13/21, 4:42 AM, "Peter Psenak" >>> <[email protected] >>> <mailto:[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] <mailto:[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
