Hi Aijun, > [WAJ] I have explained to Chris the differences between the usage of IGP > unreachable and BGP unreachable at > https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/ > <https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/> > BGP、Tunnel etc. overlay services are depending on the IGP, then knowing the > unreachable information can certainly accelerate their convergence and > switchover to the backup endpoints.
Yes, but you missed the point that BGP should carry the reachability in the first place and then the BGP withdraw would give you what you want. Yes, I certainly understand that you want to change the IGP behavior to accomodate tunnel convergence. That part is quite clear. We do not want to flood the negative liveness information in the IGP. That’s not its job, architecturally. > What I would like is if there was a centralized service, such as Google Maps, > that simply did the path computation for me and updated it in real time. :) > Interestingly, that information isn’t flooded. It’s built with a scalable > back end service and then unicast to the end user. > > > [WAJ] As I explained below, PUAM information is needed not only the PEs(for > BGP scenario), but may be used by P router within the network(for Tunnel > scenario). As also I explained previously, the implementation/operator can > limit the PUAM only for /32 or /128 loopback address, which will not > sacrifice the scalability of IGP, and at the same time, accelerate the > convergence of the overlay services that depends on it. > Comparing with utilizing the existing procedures, Introducing another > mechanism, such as centralize service, PUB/SUB mechanism as you proposed, > isn't it more complex and less efficient? All the procedures that we > considered will not omitted, the difference is only how to transfer the > message. The problem is that restricting the prefix length does nothing to limit the number of advertisements that get flooded. In a high-scale situation, when there is a mass failure, it would lead to a flooding spike. That’s exactly not the time to stress the system. Yes, it is more complex and harder than simply flooding things. It’s also much more likely to actually work well at scale and under stress. It’s pretty common that you can either do things the right way or you can do things the easy way. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
