Correction related to SRv6 as if uses the native IPv6 data plane it does out of the box support summarization.
A gap still exists for MPLS and SR-MPLS. Kind Regards Gyan On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang <[email protected]> wrote: > > > Aijun Wang > China Telecom > > On Nov 22, 2021, at 18:44, Tony Przygienda <[email protected]> wrote: > > > Just to prop a voice of support to Tony Li's arguments which I have > nothing further to add really. He basically elucidated ;-) with flourishes > what I wrote in my short, terse email I think. > > As he says "you either make easy choices and get an operationally unstable > environment at scale/large disturbances or you make hard architectural > choices & scale much better over time". > > > [WAJ] Easy choices doesn’t definitely get operationally unstable > environment(we have explained in previous mails). And would you give some > examples to illustrate “hard architecture but scale much better over time?” > > Examples of that are abound in systems design but it's unfortunately often > RFC1295 (4). As a sidenote: IETF has no intention or mechanism to stop > people doing unscalable, poorly designed things with their specs > > > [WAJ] like RIFT or flood reflector solutions in IGP? > > and that was ok as long people did not try to push them onto the whole > world without listening to folks who took the scar tissue to get us the > IETF working specs we have today which seems to have become fashionable in > last couple of years. > > > And fast flooding is a red herring here IMO, it does nothing but > accelerate the control loop, if the control loop is positively stable, it's > good, if the control loops are oscillating or start to negatively amplify > accelerating things just melts everything faster. > > > [WAJ] There is no control loop oscillation. We track only the down event. > > > Ultimately, having followed this "discussion" my opinion is still that if > authors would like to abuse IGP as "domain wide broadcast" for liveliness > notification the "events" draft is far less fragile and convoluted but > should be kept in a service instance as basically "event based BFD > substitute" to not start to cause head-blocking on IGP resources. > > > [WAJ] Seems you are not listening other person’s discussion. Please refer > to Acee’s comments at > https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/ > > And AFAIR Robert observed it's still not a very good indication compared > to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD > PMSI (assuming UDP healthy = TCP healthy which is however far less an > assumption than "flooding feels transport is OK"). > > > [WAJ] Current solutions are not aimed only the BGP overlay service, but > also the tunnel services. For tunnel services how you build MP2MP PMSI? > > > -- tony > > On Mon, Nov 22, 2021 at 7:55 AM Tony Li <[email protected]> wrote: > >> >> Les, >> >> >> The problem is that restricting the prefix length does nothing to limit >> the number of advertisements that get flooded. In a high-scale situation, >> when there is a mass failure, it would lead to a flooding spike. That’s >> exactly not the time to stress the system. >> >> *[LES:] As I have stated previously, I share your concern about the >> behavior during massive events – and some care has to be taken to prevent >> making a bad situation worse.* >> *That said, the WG (including you and I) is taking on enhancements to >> support much faster flooding – on the order of hundreds (perhaps thousands) >> of LSPs/second. We believe this can be done safely (though proof has not >> yet been established).* >> >> >> >> And the point of doing that was to help improve IGP convergence time… >> >> >> *So, if you believe (as your active participation suggests) that IGPs can >> support faster flooding – why do you believe they cannot support liveness >> notification at a similar scale?* >> >> >> >> … not waste our time by inflating the LSDB by the same amount that we >> sped up flooding. >> >> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding >> negative liveness information is primary a scale issue. >> >> >> >> *I get that you consider such notifications as architecturally >> undesirable – we can agree to disagree on that point.* >> *But I don’t get why you think the IGP’s ability to handle large scale >> events is a showstopper in this case.* >> >> >> >> I am opposed to anything that adds to the scale of the LSDB. Doubly so if >> it does so during failures, when the IGP is already under stress. As you >> well know, making an IGP stable during normal operations is one thing. >> Ensuring that it is stable during worst case topological changes is quite >> another. Adding scale during a mass failure is pessimal timing. >> >> T >> >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
