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
