Jeff,
The point is about the right architecture, not a brute force method.
Do you see it as elegant to bombard 1000s PE with a probe every second ? I
do not. Especially considering that PEs rarely go down.
And that should be compared with even driven notification.
BGP: - Local BFD detect the failure in say 100-200 ms
- propagation via RR is max in ms (I recall in Cisco we measured
this to actually by much faster on dedicated control plane only RRs)
- then interesting PE (RT filter) can be notified about the
failure in less then 300 ms - be conservative 500 ms.
IGP: - Local BFD detect the failure in say 100-200 ms
- Failure get's flooded to local ABR(s)
- LSA/LSP get's generated and flooded hop by hop via say 20 hops
all over the network via say core and additional area.
Maybe the entire process takes also 500 ms ... I do not have any
estimate here, but I am sure folks on LSR do.
In any case the event driven notification is a much better choice.
Kind regards,
R.
On Wed, Oct 13, 2021 at 7:28 PM Jeff Tantsura <jefftant.i...@gmail.com>
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
>
> Cheers,
> Jeff
>
> On Oct 13, 2021, at 10:16, Robert Raszuk <rob...@raszuk.net> 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) <acee=
> 40cisco....@dmarc.ietf.org> wrote:
>
>> Hi Peter,
>>
>> See inline.
>>
>> On 10/13/21, 4:42 AM, "Peter Psenak" <ppsenak=40cisco....@dmarc.ietf.org>
>> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
