Hi, Tony: Aijun Wang China Telecom
> On Nov 19, 2021, at 23:51, Tony Li <tony...@tony.li> wrote: > > > 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. [WAJ] Reachability is not equal to liveness, but the dead is equal to unreachability. 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. > > >> 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. [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. > > >> 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. > > Tony >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
