Summarization has always been a best practice for network scalability thereby reducing the size of the RIB and LSDB.
So in this case as Dan pointed out, the summary route is an abstraction of the area and so if a component prefix of the summary became unreachable we need a way to signal that the PE next hop is no longer reachable to help optimize convergence. We are just trying to make summarization work better then it does today so we don’t have to rely on domain wide flooding of host routes. Thanks Gyan On Wed, Jun 15, 2022 at 4:42 PM Voyer, Daniel <daniel.voyer= [email protected]> wrote: > Hi Gunter, > > Thanks for your comments, > > The idea, here, with summarization is to "reduce" the LSDB quite a lots > and make a given backbone much more scalable / flexible and allow to > simplify NNI's within that given backbones considerably. > Summarization is "needed" for better scale and, in the context of IPv6, > will help in preventing blowing up the IGP. With the size of an IPv6 > prefix range (ex. /64) allocated per domain - summarization will help to > contain the LSDB to that domain. > > What we are "highlighting" in > draft-ppsenak-lsr-igp-ureach-prefix-announce-00, is an easy way to overcome > the fact that PEs are hidden behind a summary route and need a fast way to > notify other PEs when they become unreachable. > > I don't see "over-engineering" here, I see "optimal-engineering" instead. > > Thanks > Dan > > On 2022-06-14, 4:59 AM, "Van De Velde, Gunter (Nokia - BE/Antwerp)" < > [email protected]> wrote: > > Hi All, > > When reading both proposals about PUA's: > * draft-ppsenak-lsr-igp-ureach-prefix-announce-00 > * draft-wang-lsr-prefix-unreachable-annoucement-09 > > The identified problem space seems a correct observation, and indeed > summaries hide remote area network instabilities. It is one of the > perceived benefits of using summaries. The place in the network where this > hiding takes the most impact upon convergence is at service nodes (PE's for > L3/L2/transport) where due to the summarization its difficult to detect > that the transport tunnel end-point suddenly becomes unreachable. My > concern however is if it really is a problem that is worthy for LSR WG to > solve. > > To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is > not a preferred solution due to the expectation that all nodes in an area > must be upgraded to support the IGP capability. From this operational > perspective the draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is > more elegant, as only the A(S)BR's and particular PEs must be upgraded to > support PUA's. I do have concerns about the number of PUA advertisements in > hierarchically summarized networks (/24 (site) -> /20 (region) -> /16 > (core)). More specific, in the /16 backbone area, how many of these PUAs > will be floating around creating LSP LSDB update churns? How to control the > potentially exponential number of observed PUAs from floating everywhere? > (will this lead to OSPF type NSSA areas where areas will be purged from > these PUAs for scaling stability?) > > Long story short, should we not take a step back and re-think this > identified problem space? Is the proposed solution space not more evil as > the problem space? We do summarization because it brings stability and > reduce the number of link state updates within an area. And now with PUA we > re-introduce additional link state updates (PUAs), we blow up the LSDB with > information opaque to SPF best-path calculation. In addition there is > suggestion of new state-machinery to track the igp reachability of > 'protected' prefixes and there is maybe desire to contain or filter updates > cross inter-area boundaries. And finally, how will we represent and track > PUA in the RTM? > > What is wrong with simply not doing summaries and forget about these > PUAs to pinch holes in the summary prefixes? this worked very well during > last two decennia. Are we not over-engineering with PUAs? > > G/ > > ------------------------------------------------------------------------------ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > _______________________________________________ > 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
