Hi Tony, > Do you envision any form of aggregation to happen in the messaging > between ABRs (for both registrations and notifications) ? > > Well, as always, I try to generalize mechanisms and solutions. So while I > don’t see an immediate need or benefit to it, I did write the protocol so > that it is possible. I wasn’t comfortable with some of the implications of > non-host prefix liveness events, so I didn’t include those yet, but it is > certainl possible.
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. *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. Obviously there are few more low hanging fruits like those two ... > I think the pub-sub model is really cool, but I am not clear what are the > advantages to do it in the IGP from ABRs vs BGP from area RRs (note that in > the latter case no new protocol is required). > > It doesn’t add more burden to BGP. It also doesn’t require BGP for those > that aren’t using it. It might also be a bit faster than BGP as there’s > less overhead. > Well let's not forget that BGP will do it anyway :) Next hop tracking kicking in on the RRs will immediately trigger withdrawals. So clearly this is not like we are saving BGP in any way here ..... As discussed, what is getting withdrawn is a different discussion. /* I would be really curious to read some of those cases where BGP free network (to carry services) needs such speed-up */ > > Also if we do it from local area RRs we do not need registrations - > local RRs know which next hops are attached to local service routes. And it > would go only where the service route goes. > > I think you’re asking if ABRs can be co-located with a client. Yes, > certainly. An ABR could initiate a registration for its own purposes. I’ll > add a clarification. > Great ! 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. Could be an optional operational model. Kind regards, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
