If you have so many PEs in an area that you must summarize then putting RR outside of this area I would call a bad design.
Thx R. On Tue, Jan 25, 2022, 11:37 Aijun Wang <[email protected]> wrote: > Hi, Robert: > How about when the RR locates in one area(for example, backbone area), but > the PEs locates in the attached non-backbone area? > In such scenario, the RR can only receive the summary prefixes of PEs. > > Aijun Wang > China Telecom > > On Jan 25, 2022, at 17:59, Robert Raszuk <[email protected]> wrote: > > > Aijun, > > [WAJ] X aims to how to withdraw the VPN prefixes with the mentioned >> extended communities, right? >> > > Extended communities have nothing to do with this discussion at all. > > >> Y aims to how assist the RR get the prefix cost from one node that other >> than the RR itself. Right? >> > > No. > > >> I think they all don’t answer the questions how to detect the failure of >> BGP peer. Right? For this requirement, you can only depend on the BGP hello >> timers, or BFD for BGP. Right? >> > > Wrong. Let me explain. > > PEs peer with iBGP sessions to a pair of RR in a local area. In the vast > majority of cases those RRs are IGP nodes. If so in exactly the same way as > ABRs, also RRs will be receiving local area link state flooding about PEs > going down. > > That along with next hop tracking (local feature) will trigger event > driven service path invalidation followed by immediate withdrawal. Note > that those withdraws will be propagated via one or max two RR hops before > reaching the destination PE(s). That propagation speed is in > milliseconds when measured with solid BGP implementation. It can be much > faster then flooding via 10s of IGP nodes across two areas. > > If RRs are running on x86 blades they do not need to be IGP nodes, but > nothing stops them from being passive IGP listeners. > > That is how you detect the failures local to your areas on the BGP RRs. > The trigger is exactly the same for RRs as is for ABRs. Has been done and > deployed for decades now and works perfectly fine. > > > >> [WAJ] For SRv6 tunnel services, which layer control? How? >> > > Something runs over those tunnels right ? If not we have no issue anyway > as there is no service to be protected or :). > > Thx, > R. > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
