Hi Robert,
> Let me perhaps illustrate in two examples what I had in mind. I actually do > see immediate benefit to include it day one both in the spec and in the > protocol: > > *A* ABR locally (from it's own area) received registration requests for 100 > /32s next hops. It knows from reachability LSDB that summary for all of them > came from a single area. So it seems that sending (or rather relaying) such > registration to all ABRs instead of only to those serving said area would be > very unnecessary and suboptimal and the only effect would be to to grow their > RDB for no reason. Ok, this was the intent already. The current text says: If an ABR receives a Registration Message for a prefix that is being injected by a non-attached area, then it should determine the set of ABRs that are advertising that prefix or less specifics and register with those ABRs for that prefix. Apparently that’s not clear. What can I do to make it more obvious? I did a clarification about not duplicating registrations. > *B* The same ABR as in *A* instead of registering 100 /32s could observe > that all of them are part of /24 subnet X and instead of asking ABRs serving > egress area to get notification for all those next hops could just ask those > ABRs to send all events pertaining to entire /24 subnet hosts. Then upon > receiving such events will filter according to local registrations in his own > area. Yup, thought of this case and I like it. Is it sufficient if the ABR doesn’t wait for the 100 /32s to show up? When it receives the first one, it determines that the covering prefix is a /24 and just registers for that. The downside is that there could be many unnecessary notifications delivered. If the network operator does as Chris suggested and creates a single summary for PE loopbacks, then this all works very well. If not, there would be noise. I think we should go for it. I’m adding text saying that the ABR should register for the most specific covering prefix. > Obviously there are few more low hanging fruits like those two ... Please call them out. > Also what I had in mind was single filtering deployment model where ABRs > react on all host routes (within set ranges) going up and down and unicast it > to all other ABRs without any registration. Only the ingress area ABRs would > do local filtering from local ingress PE registrations. It seems to me that this can already be done with the existing protocol and is just undocumented ABR behavior. If folks feel this is worthwhile, we can certainly add that. I’m guessing it would add more configuration, which I was trying to avoid. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
