Hi, Tony:
-----Original Message----- From: [email protected] <[email protected]> On Behalf Of Tony Li Sent: Friday, November 19, 2021 9:08 AM To: Aijun Wang <[email protected]> Cc: Tony Przygienda <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra <[email protected]>; [email protected]; Christian Hopps <[email protected]>; Acee Lindem (acee) <[email protected]> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Hi Aijun, At the risk of Tony confusion… [WAJ] Will not confuse due to the different speaking and wording style. >> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the >> confusion here is that a presence of a /32 route is used as SSAP liveliness >> AFAIS and that's simply not what IGPs are here for if you consider their >> main job to be fastest possible convergence in network _reachability_ only >> and not signalling of service failures. > > [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. [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. 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. If you’re willing to forgo scalability, then do so. Don’t use areas. Just have a flat routing domain. Hole punching is going to put you in exactly the same place, sooner or later. You’re sacrificing scalability and adding another mechanism to do so. Why bother? >> Alternately resolving BGP over BGP as Robert suggests (if I read that >> correctly) and use RR to scale out the SSAP nhop availability is possible I >> think architecturally without garbage-canning IGPs as "network-wide fast >> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence >> ;-) but can be simpler hardware wise than trying to scale up BFD to large >> number of very fast sessions. > > > [WAJ] The operator doesn’t also want the network is filled with various queer > designs or solutions. Then why are you proposing one? [BTW, I realize that you intended no offense, that’s probably NOT the best choice of words.] 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. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
