Hi Tony, 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. > > How about s/with those ABRs for that prefix./with only those ABRs for that prefix./
*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? > 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. 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. > I think that can be a valid deployment model so spelling it out may not hurt IMHO. The receiving ABR needs to be prepared that it is receiving something without registering for it. 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 ? Thx, Robert
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
