Are you saying this draft is useless ? https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
Thx, R. On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra <[email protected]> wrote: > > 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
