Hi Aijun, >> 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. > > [WAJ] Reachability is not equal to liveness, but the dead is equal to > unreachability.
Sorry, no. Dead is a lack of liveness. You still have reachability. You send packets and they still make it to the system. Ok, no one’s home and the packets fall on the floor, but they were delivered. > What we want is to alert other peer that some prefixes within the summary is > unreachable and they should do some thing, for example, fast reroute to other > nodes etc. > It is unreasonable that the ABR knows such unreachability but still claims > that it can reach all the prefixes the summary address covered. Again, the ABR is claiming (and providing) reachability. You’re asking for negative liveness. That’s not something that routing protocols do, and can’t do without surrendering abstraction and scalability. >> Our job is to not design in mechanisms that lead to these bad outcomes. > > [WAJ] I agree with you on this point. But how about your comments for such > considerations in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7 > > <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7>. > We have considered how to reaction to the mass outrage at the beginning. Those seem somewhat destructive. Not advertising the summary breaks all other services. Instant network disaster. Having a threshold for the number of negative advertisements indicates that you don’t have a general, scalable solution. >>> 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. > > [WAJ] The registration mechanism, like BFD? requires the configuration > overhead, is difficult to deploy in the large scale network. That the reason > we prefer to the automatic mechanism. No. You don’t need BFD. You want a notification from the ABR. This can be done automatically. The ABR advertises that it provides a liveness notitification service as part of router capabilities. Interested parties open a connection to the ABR and indicate the hosts/prefixes that it is interested in. When there’s a failure, the ABR provides that indication. It can also provide a positive indication when the system is back up. True liveness! Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
