On 27 mrt 2009, at 2:23, Danny McPherson wrote:
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.
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.
Yes, a router thinks its own eBGP route is best--but the RR wouldn't
necessarily agree. Suppose 4 eBGP routers and an RR, the average
backreflection would be 25%. Now maybe it's 85% for one and 5% for the
three others, but the average can only be 25%.
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?
If a router is responsible for a very large number of best prefixes
that are then reflected back to that router by the route reflectors,
it would make sense to make that router NOT a route reflector client.
If the router in question isn't an RR client, the RRs don't reflect
any information back to the router. Of course this means that the
router in question must have a full iBGP mesh with other other non-RR-
client routers as well as with all the RRs.
1) all best paths learned from the client are reflected
back to the client
Right. Note that the average number of those paths is (table size) /
(# eBGP routers).
2) this is multiplied by the number of RRs to which that
client peers
Right again, but since EVERYTHING multiplies by the number of RRs this
is not unexpected or worthy of special concern, especially as
backreflected paths actually use up less resources than other paths.
3) client processing of updates results in placement of ALL
updates in [serialized?] BGP input processing queue with ALL
other updates {m, 1..n}
Depends on implementation. Again, other paths require more processing
than backreflected ones so I don't see the issue.
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
See above.
5) Serialized processing means all Address Families likely
effected.
See above.
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.
Yes, the whole notion that a BGP router must track which updates were
sent to which peer is a big design flaw.
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.
Agree with that, but what action do you suggest?
I think the issue is sufficiently complex and unexpected that a good
writeup would benefit the community, but I don't think imposing any
new rules would be helpful, if only because implementations must
expect the current behavior for many years to come anyway.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
