On Mar 30, 2009, at 7:39 AM, Iljitsch van Beijnum wrote:
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%.
Indeed, I noted already that there are likely dynamics
within a cluster that change this for a given route set,
and those likely vary widely based on interconnect
topology and network architecture.
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.
In large networks it's extremely difficult to 'turn the steam
valves' in this manner. Also, one might argue that you do get
the inter-cluster implicit aggregation benefits if other paths
are sourced from BGP speakers within the cluster.
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.
How's that the case, because they're not stored in a RIB-In?
All other resource consumption and processing would be the same,
in particular because a path reflected back may well be a
withdraw, and it has to be processed like any other update.
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.
How do you figure? Again, because it can be an implicit
withdraw you can't simply discard it.
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.
Well, to be clear, some implementations at least used to
not reflect routes back to clients (e.g., JUNOS) - I hope
they haven't blindly changed default behavior to enable
capabilities such as that of ACCEPT_OWN, and they they only
reflect necessary routes back to originating clients.
Bottom line - at some point systemic effects of this will
result in something breaking, or convergence delays, or scaling
issues. Local optimizations that result in extraneous system
state aren't ideal.
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
