Hi Aijun, > 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. > [WAJ] The IGP advertises the summary reachability. The overlay service(BGP or > tunnel) established based on this information. But when the endpoint of these > overlay service is unreachable, the IGP still advertises the summary > reachability. IGP should leak the actual information in such situation, > doesn't insist that it can reach these failed address. > And, as we have presented in the IETF meeting, the ABR Need Not advertise > such information once there is prefix unreachable. The operator can configure > the tracked/interested prefixes on the ABR.
Again, you’re confusing reachability with liveness. A summary address does NOT imply liveness. If you have a prefix 1/8, that does not mean that 1.1.1.1 is up and will accept a TCP connection or reply to a ping. > We want scalability. That implies abstraction and that means that you can’t > get a full link state database everywhere. > [WAJ] Yes. Current solution will not scarify the IGP scalability. As stated > above, Not all link/prefix failures information will be delivered. You can’t guarantee that. What we’ve seen is that when we provide features in protocols, they are (ab)used in the worst ways imaginable. And then the implementers are held responsible for the outcomes. In this case, it’s pretty clear that there could easily be a mass failure resulting in the bulk advertisement of a whole lot of negative information all at once. One of the other things that we’ve learned is that step (and spike) responses are problematic. Frequently they are more of an issue than scale because the operator can’t see it coming. We end up with cascade failures (see the recent Facebook failure). Our job is to not design in mechanisms that lead to these bad outcomes. > There’s a reason that we’ve never gone down the path of hole punching before. > And yes, it’s been discussed before, decades ago. > [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such > solutions will be needed more and more. I think it is different from the > situation existing decades ago. Nothing has changed except the encoding. We’ve been tunneling for decades. We’ve been summarizing for decades. We’ve been rejecting hole punching for decades. We’ve even been tunneling using source routing and other high overhead mechanisms for decades. That ended up rejected too. If you really want the service, please change the architecture to a registration mechanism as I outlined. This can and should be done outside of the IGP. You’re asking for a proxy liveness service and that’s entirely doable. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
