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 <rob...@raszuk.net> Sent: Friday, November 19, 2021 1:30 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Tony Li <tony...@tony.li>; Gyan Mishra <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda <tonysi...@gmail.com> 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) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> 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 <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Friday, November 19, 2021 12:25 PM To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Tony Przygienda <tonysi...@gmail.com<mailto:tonysi...@gmail.com>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
