Hi Tony, > You mean to show up in registration ? I guess there could be a triggering > threshold with some wisely chosen % of the min. number of host routes in > the summaries to avoid too much noise. > > That seems like a difficult condition to explain. How do you feel about > just always selecting the most specific prefix that is less specific than > the prefix? This gets you the /24 bur avoids 0/0. >
I think this is easiest and easiest is good. As this is actually a local matter perhaps we do not need to spend much time on that in the spec other then describing the general functionality of auto selecting less specific covering prefix for registration between ABRs. Then each vendor could add some extra logic or even ML twicks on what to register to differentiate themselves :) Or we could perhaps solve it very neatly and define ability to register for > all prefixes (within given mask range) with some form of a wildcard or > reserved prefix 0.0.0.0/32 or 0.0.0.0/24-32 in IPv4 case ? > > You can already register for 0/0, tho you would get everything. I don’t > recommend it, tho I can see that it might be useful for network monitoring. > Not sure if we should add ability to register for any prefix with a given mask or mask range (irrespective of the prefix itself). I think that could be pretty useful especially between ABRs to avoid chattiness if someone just wants to remote ABRs all notifications for /32s or /64s or /128s etc ... > I added explicit statements saying that an ABR should ignore unexpected > notifications that have no matching registration. That should always hold. > Cool ! > I then added a section that says that an ABR may create global > registrations for prefixes learned from the management plane. That should > cover the optional behavior that you’re thinking of. I’ve called this > “Autonomous Notificatin Mode”. > Ok. - - - While perhaps pretty obvious, it would be good to also highlight what implementation should do in the event of covering prefix changes in the LSDB if those are to happen after registrations have already gone out. Maybe as simple as de-register and re-register for the new covering prefix ? Kind regards, Robert
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
