Hello Ryan,
Correct me if I am wrong..the iBGP full mesh requirement stems from maintaining a loop free topology?
Not directly. As you know, there is a rule in iBGP that says that "a route learned via iBGP will not be advertised via iBGP". Some people like to call it the "iBGP split horizon rule" although I personally dislike this name. This rule was created to prevent routing loops, because within iBGP, no special attribute is added to a prefix to identify the sequence of iBGP routers the prefix went through - as opposed to eBGP where the ASN is prepended to the AS_PATH list. An iBGP speaker has therefore no clue whether the prefix it is receiving is a prefix it originally advertised itself, or if it is an alternate path to the same destination. Hence, the easiest way to prevent routing loops in iBGP is simply - to keep an iBGP-learned route just to yourself and to not advertise it to any other iBGP peer.
Surely, however, any iBGP speaker may learn about a prefix that needs to be known by all other iBGP speakers. However, with this iBGP rule in place - and with no additional mechanisms such as RRs or confederations - the only way to have all other iBGP speakers know it is to tell them directly. And because any iBGP speaker can at any time learn about a topology change and tell about to all other iBGP peers, we need the iBGP full mesh. Hence the full mesh requirement.
So the sequence of consequences is: we want loop-free routing -> iBGP has no attribute to prevent routing loops -> iBGP will not further advertise iBGP-learned routes -> we need iBGP full mesh
I am not sure if I answered your question so please feel welcome to continue the discussion.
Best regards,
Peter
