Hi, Robert: The deployment of IGP and BGP is decoupled. The solution can’t rely only on the limited assumption. And, actually, the PE are Provider Edge Router, we always locate them at the non-backbone area in large network , that is close to the customer. There maybe some small network that may satisfy your assumption. We will not deploy the RR on every IGP area.
Aijun Wang China Telecom > On Jan 25, 2022, at 19:46, Robert Raszuk <rob...@raszuk.net> wrote: > > > 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 <wangai...@tsinghua.org.cn> 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 <rob...@raszuk.net> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
