Hi Robert,
> 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./ Sure. >> *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. 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. >> 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 <http://0.0.0.0/32> or 0.0.0.0/24-32 > <http://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. I added explicit statements saying that an ABR should ignore unexpected notifications that have no matching registration. That should always hold. 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”. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
