> On Dec 1, 2017, at 2:16 AM, Elmar K. Bins <e...@4ever.de> wrote: > > na...@studio442.com.au (Julien Goodwin) wrote: > >>> The first optimisation is to remove any supplied prefixes which are >>> superfluous because they are already included in another supplied >>> prefix. For example, 2001:67c:208c:10::/64 would be removed if >>> 2001:67c:208c::/48 was also supplied. >>> >>> The second optimisation identifies adjacent prefixes that can be >>> combined under a single, shorter-length prefix. For example, >>> 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the >>> single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and >>> 10.0.1.0/24 can be joined into 10.0.0.0/23. >> >> Will it catch cases like: >> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22 > > I guess the developers will have implemented a loop that runs until no > more optimizations have been found. Which would of course catch it as > > Iteration 1 > 10.0.0.0/24 + 10.0.1.0/24 > -> 10.0.0.0/23 > > Iteration 2 > 10.0.0.0/23 + 10.0.2.0/23 > -> 10.0.0.0/22 >
The usual trick is to build a prefix tree then walk the tree, which catches this sort of case in one step. Cheers, Steve
