Yes that was it. On the part of scalability please observe that operators may configure summaries of their choice. See even if you scope summaries to be /24 only for IPv4 you still suppress lot's of /32s flooding. After all not one mandates that one area must be covered by a single summary.
Nice you brought IPv6 to this discussion :) If you think that one bit for IPv6 next hop in a summary makes the idea not usable what happens when you loose a dense POP and you need to pulse all atomic /128s being part of the POP's TORs or compute if not kubernetes PODs in the computes. Even with rate limit IGP may get hot pulsing ... Thx, R. On Fri, Nov 19, 2021 at 11:09 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > I believe you are referring to > https://datatracker.ietf.org/doc/html/draft-swallow-isis-detailed-reach-01 > . > > > > This doesn’t scale well for shorter summaries – even for IPv4. > > And for IPv6 I think this is simply not usable. > > > > The draft details a potential deployment scheme which depends upon a very > disciplined assignment of loopbacks by the network operator. You can > comment on how reasonable an assumption that is better than I. > > I also think the scale numbers discussed in the draft have increased > significantly over the years – which further stresses the use of this > approach. > > > > Les > > > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Friday, November 19, 2021 1:30 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Peter Psenak <[email protected]>; Tony Li < > [email protected]>; Gyan Mishra <[email protected]>; Christian Hopps < > [email protected]>; Aijun Wang <[email protected]>; lsr < > [email protected]>; Acee Lindem (acee) <[email protected]>; Tony Przygienda < > [email protected]> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > Hi Les, > > > > Ok if you say that this is going to be rate limit for pulses rather then > say drop it does sound promising. > > > > I think there are two parts to this. One is the definition of reachability > vs liveness. For some of us it is the same. Clearly dead node can not be > reachable :) > > > > The other part is however stability of the solution and deterministic > nature of it. Pulses are something really new and I guess getting > experience with it across zoo of vendors will be a significant effort. > > > > Have you consider a different approach ? I recall we spoke about it long > time back. At least I recall talking with Stefano about it :) Just to > advertise bit vector with each summary where each bit covers a summary > member. 1 would indicate presence of /32 reachability in the area, 0 would > indicate lack of such atomic prefix in an area. > > > > No matter what happens you still advertise the same amount of information. > It is predictable and while one can argue that it will make IGP more chatty > clearly it will not be ON by default. And all machinery of pacing LSP/LSA > generation would apply automagically. > > > > Further receiving node may act on this info in exactly the same way as it > would act on pulse. > > > > Thx, > R. > > > > > > > > > > On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Robert – > > > > For me dealing with “mass failure” is important – but is easily doable. > > It is basic to IGP flooding that we limit the rate at which new versions > of LSPs are generated. > > Analogous (but not identical) controls can be applied to pulse > advertisements – and should be. We will address that in the next version of > the draft. > > > > The substantive debate in my mind is that some people think it appropriate > for IGP to advertise loss of reachability to destinations covered by an IGP > originated summary advertisement and some folks do not. > > > > Thanx. > > > > Les > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Friday, November 19, 2021 12:25 PM > *To:* Peter Psenak <[email protected]> > *Cc:* Tony Li <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]>; Gyan Mishra <[email protected]>; Christian Hopps > <[email protected]>; Aijun Wang <[email protected]>; lsr < > [email protected]>; Acee Lindem (acee) <[email protected]>; Tony Przygienda < > [email protected]> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > Peter, > > > > yes, but it's not specific to flat areas. Even in multi-area deployments > the host routing is mandated by MPLS. > > > > In the early days of MPLS yes that was the case. > > > > But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :) > > > > https://datatracker.ietf.org/doc/html/rfc5283 > > > > In these multi-area deployments > the host routes are sent everywhere, updates are triggered regardless of > the failure type. IGPs are effectively providing liveness service > between PEs in any MPLS network. > > > > That is true too - as folks just do not know how to configure BGP properly > (if BGP is used for services). > > > > That leaves us the space what to do where there is no BGP carrying > services. Or BGP implementation is broken and can not do the right thing. > > > > For the pulse proposal - no one answered the question posted what is a > definition of mass failure. But maybe that will be the secret sauce of a > vendor :) ? > > > > The fact that we are all in agreement that some network events will not > work that well with the proposed solution seems to be a sufficient reason > for me to consider different solution(s). > > > > Thx, > > R. > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
