Hi Peter, >>> [WAJ] The problem is arose from the summary action of IGP, why let other >>> protocols solve it? >> There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. >> That’s not a property that it was meant to provide. > > today IGPs provide reachability for the host route of remote PEs. Both up and > down events are propagated everywhere. If such host route becomes > unreachable, it is being used by BGP PIC to trigger the reroute. > > When summarization is in place, to help IGP to scale, the remote PEs' > reachability is announced in a form of a summary and host routes are > suppressed. Providing down notification for the host prefix covered by the > summary is similar in nature to what happens without the summarization. And > if that down notification can be done in smart way, we are still better off > compared to what we do today without a summarization.
And if it was done in a smart way, you could do so without ANY impact to scalability. I outlined the mechanism for you already. > You can call it liveness or something else, but IGPs are already doing so > without the summarization. Arguing that it's not a property that IGPs were > meant to provide is misleading. This is incorrect. Liveness is a side-effect in a flat area. It is NOT something that the routing layer provides. Consider the case of a host that is not participating in the IGP. You have reachability information for it and path computation, as the IGP is designed to provide, but you do not have liveness. If you are not willing to have an architectural discussion, then there’s not much of a point in having a working group. If you’re going to call every argument misleading, there’s also not much point in a working group. Les asked me for a clear explanation. I’ve done my best to provide that and apparently, I haven’t earned enough respect for it to be seriously considered. Ok, so be it. I was not looking for the Argument Clinic (https://www.dailymotion.com/video/x2hwqn9 <https://www.dailymotion.com/video/x2hwqn9>). Let’s agree to disagree. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
