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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
