Hi Danny, All, I agree that there are/could be efficiencies in some implementations or could be made. We are still bound by the #BGP updates on the wire though.
Consider 3 RR-clients R1, R2, R3 advertising 3 prefixes P1, P2, P3 respectively to an RR. Further, R1 & R2 advertise P12, R2 & R3 advertise P23 and R3 & R1 advertise P31 to the RR. In the case you describe where the RR advertises the client routes back to the clients, all the prefixes - P1, P2, P3, P12, P23 & P31 would be advertised in 1 packet which gets replicated to all 3 clients (assuming all 3 are in a peer-group and the rest of the attributes are same). Now if we change it so that the RR does not advertise the client's own routes back to it, the RR would end up formatting & sending - in the best case, 3 BGP updates instead of 1. My point is - no matter what efficiencies we build into an implementation - mandating that the RR not advertise client routes back to clients, would increase the #BGP updates processed by the RR and all the "n" RR-clients as well as on the wire by n-fold in the worst case. -Gargi ________________________________________ From: [email protected] [[email protected]] On Behalf Of Danny McPherson [[email protected]] Sent: Thursday, March 26, 2009 6:23 PM To: Iljitsch van Beijnum Cc: [email protected] [email protected] Subject: Re: [GROW] RR reflection to clients On Mar 26, 2009, at 4:24 PM, Iljitsch van Beijnum wrote: > > Then again, this is only an issue for the prefixes the router itself > sends to the RRs and then are reflected back. You mentioned some > really large numbers in your talk which seem atypical to me: in a > network large enough to have RRs I would assume that most routers > are only responsible for a relatively small number of best prefixes > in the global table. Yes, this multiplies by the number of RRs but > then again so do all the prefixes that the router isn't considered > best for, which require significant more resources. Those numbers are likely to be reflective of the aggregate set of unique prefixes (best routes) from ALL external peers in an Internet table, as the local eBGP route is _usually the best. > In the case where a router would indeed get back 100k if its own > prefixes from RRs it would make more sense to make that router a non > client peer of the RRs and make the problem go away in that way. I don't grok that? > Considering all of the above and the fact that avoiding > backreflection means breaking groupwise processing on the RRs which > means extra processing for ALL prefixes times ALL clients for each > RR I'd say that we shouldn't make changes here, but limit ourselves > to documenting the issue so that vendors and operators can make sure > the additional processing for backreflection is reduced. So I've taken a few minutes to illustrate the problem in a couple slides in more detail. The PDF is available here at the link below, and I've attached (I hope this doesn't cause problems for anyone): http://www.tcb.net/rr-thing.pdf To summarize some more thoughts on this, and best illustrated in slide 3 in the deck above: 1) all best paths learned from the client are reflected back to the client 2) this is multiplied by the number of RRs to which that client peers 3) client processing of updates results in placement of ALL updates in [serialized?] BGP input processing queue with ALL other updates {m, 1..n} *Input processing queue typically scheduled in round robin model 4) if n is sufficiently large, many of these updates may very well still be in the process of being learned from the external peer(s) (r) and initial convergence function, and processed behind extraneous reflected routes 5) Serialized processing means all Address Families likely effected. 6) Reflected route MAY be legitimate withdraw if alternative best previously advertised from RR - therefore it must be processed normally IF received - this is likely one of the more interesting bits for the RR implementer. I believe this is AN issue that implementers should look at. I understand that there may be efficiencies in some implementations to copy and it's more complex to not reflect to client IF Originator == client RID. -danny _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
