Hi, Tony: The ABR should do the summary work based on the liveness, right? If most of addresses within the summary are unreachable/dead as it knows, should it advertise the detail reachable/liveness instead of the misleading summary address? From this POV, we think the ABR or IGP should advertise as precise as liveness information, not the reachable but dead information. Pub/Sub style notification seems promising, but it will require the ABR store the subscription state which will certainly degrade its performance. On the other hand, let the receiver decides whether to utilize such information is distributed design and more robust? There is no much work to be done when they receive the PUAM message. Just to judge the originator of the prefix is valid or not.
Aijun Wang China Telecom > On Nov 21, 2021, at 01:40, Tony Li <tony...@tony.li> wrote: > > > > 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. >> 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
