| Internet-Draft | On iBGP Full-Mesh Requirements | June 2026 |
| Rivadeneyra | Expires 17 December 2026 | [Page] |
A common misconception within the Internet community is that internal BGP (iBGP) strictly requires a full mesh or alternatives such as Route Reflectors. In reality, a full mesh is an architectural design choice driven by route visibility needs, rather than a protocol mandate. This document analyzes the historical origins of this misunderstanding and clarifies the specific scenarios—multihomed stub Autonomous Systems (ASes)— where an iBGP full mesh is unnecessary and operationally undesirable.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
It is widely believed that all BGP routers within an Autonomous System (AS) must be connected in a full iBGP mesh, or, when this becomes impractical, that route reflectors or confederations must be used. However, a full mesh is not always necessary, and in some scenarios it may even be undesirable.¶
This document explains why the belief that iBGP full mesh is mandatory has become so widespread, and clarify when it is actually necessary to interconnect all BGP routers within an AS — and when it is better not to do so.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Much of the confusion surrounding the supposed requirement for a full iBGP mesh stems from the wording in early, now obsolete, versions of the BGP specification. In the first version of the protocol ([RFC1105]), it was stated:¶
"...in order to maintain consistent routing information, these gateways MUST have direct BGP sessions with each other (the BGP sessions should form a complete graph)."¶
And further:¶
“If the BGP UPDATE was received over the INTERNAL link, it is not propagated over any other INTERNAL link. This restriction is due to the fact that all BGP gateways within a single AS form a completely connected graph.”¶
It is reasonable to assume that the authors focused on transit providers, which, at that time (June 1989), were essentially the only networks deploying BGP. Subsequent versions of the protocol retained similar wording:¶
In [RFC1163] and [RFC1267], the first statement was removed, but the second remained largely unchanged.¶
In [RFC1654] and [RFC1771], the wording evolved, but the idea of a full mesh requirement remained:¶
“When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE message.”¶
All these historical documents have since been obsoleted by the current standard, [RFC4271], from which any explicit mandate for a full mesh has been removed. The relevant rule now reads:¶
“When a BGP speaker receives an UPDATE message from an internal peer, it SHALL NOT re-distribute that routing information to other internal peers (unless acting as a route reflector).”¶
Unfortunately, the RFCs defining alternatives to full mesh — route reflection ([RFC4456]) and confederations ([RFC5065]) — still contain legacy wording that can be interpreted as implying such a requirement. For example, [RFC4456] states:¶
"Typically, all BGP speakers within a single AS must be fully meshed..."¶
While this wording reflects common operational practice rather than a protocol constraint, subsequent passages reinforce the perception that a full mesh is mandatory. This is particularly evident in [RFC5065], which includes statements such as:¶
"As originally defined, BGP requires that all BGP speakers within a single AS must be fully meshed."¶
"[BGP-4] requires BGP speakers in the same autonomous system to establish a full mesh of TCP connections among all speakers for the purpose of exchanging exterior routing information."¶
These statements, although historically accurate regarding early design assumptions, perpetuate the misconception that a full mesh is a protocol requirement rather than a network design choice.¶
In most ASes, multiple border routers maintain eBGP sessions with external peers. The AS must then determine which border router should be used to reach each external destination. While multiple mechanisms exist to achieve this, iBGP is the most common solution.¶
However, using iBGP introduces the risk of routing loops within the AS, since BGP’s loop detection mechanism (based on AS_PATH attribute) only works between autonomous systems, not within them.¶
That's why, to prevent loops within the AS, BGP prohibits re-advertising routes learned via iBGP to other internal peers. Consequently, a full-mesh will be required between all BGP routers in the AS. But this operational reasoning relies on a key assumption:¶
Every BGP router in the AS is expected to have full visibility of all external routes.¶
While this assumption is valid for transit providers, it does not necessarily apply to stub ASes or edge ISPs. Therefore, it can be concluded that maintaining an iBGP full-mesh is a requirement only for transit ASes.¶
Consider a multihomed stub AS with two border routers (BR1 and BR2), each connected to a different upstream ISP (Figure 1). Internally, the AS consists of three campus networks, each with an internal core router (IR1, IR2, IR3).¶
<svg width="21cm" height="22cm" viewBox="609 170 408 421" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="Background">
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="893.4" y="366.96">
<tspan x="893.4" y="366.96">BR2</tspan>
</text>
<g>
<rect style="fill: #ffffff; fill-opacity: 1; stroke: none" x="721.6" y="181.747" width="49.8" height="26.7287"/>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="721.6" y="203.06">
<tspan x="721.6" y="203.06">ISP1</tspan>
</text>
</g>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="609.6" y="407.614">
<tspan x="609.6" y="407.614">STUB</tspan>
</text>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 2; stroke: #000000" x1="750" y1="230" x2="750.986" y2="343.994"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 2; stroke: #000000" x1="918" y1="228" x2="916.508" y2="342.194"/>
<text font-size="14.6078" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="705" y="267">
<tspan x="705" y="267">Ebgp</tspan>
</text>
<text font-size="14.6078" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="927.6" y="269.86">
<tspan x="927.6" y="269.86">Ebgp</tspan>
</text>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="732" y1="379" x2="635" y2="490"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="927" y1="379" x2="987.514" y2="490.576"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="754" y1="384" x2="815" y2="558"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="905" y1="384" x2="834.69" y2="560.01"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="777.444" y1="379.61" x2="971.622" y2="494.314"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="888.478" y1="376.494" x2="671" y2="490"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="698" y="172" width="106" height="49" rx="0" ry="0"/>
<g>
<rect style="fill: #ffffff; fill-opacity: 1; stroke: none" x="888.813" y="179.434" width="49.8" height="26.7287"/>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="888.813" y="200.747">
<tspan x="888.813" y="200.747">ISP2</tspan>
</text>
</g>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="861.912" y="172.375" width="106" height="49" rx="0" ry="0"/>
<text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="914.912" y="196.875">
<tspan x="914.912" y="196.875"></tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="882" y="347" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="731" y="367.26">
<tspan x="731" y="367.26">BR1</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="719.6" y="347.3" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="809.6" y="581.56">
<tspan x="809.6" y="581.56">IR2</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="798.2" y="561.6" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="634.2" y="513.86">
<tspan x="634.2" y="513.86">IR1</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="622.8" y="493.9" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="964.8" y="516.16">
<tspan x="964.8" y="516.16">IR3</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="953.4" y="496.2" width="63" height="29" rx="0" ry="0"/>
</g>
</svg>
The figure shows two routers connected by a solid line when there is an iBGP session between them. As can be seen, in STUB there is no full iBGP mesh between all the BGP routers; there is no iBGP session between BR1 and BR2, nor between IRs.¶
Are those iBGP sessions necessary?¶
In a stub AS that does not provide transit between its upstream providers, inbound traffic entering through one border router must always be forwarded toward internal core routers, never toward the other border router. In the event of an upstream link failure, internal core routers will withdraw the BGP paths associated with the affected BR and shift outbound traffic toward the remaining operational BR. This mechanism renders it unnecessary for border routers to be aware of alternative external BGP paths held by other internal border routers.¶
Similarly, outbound traffic flows strictly from internal core routers to border routers, never between internal core routers.¶
Consequently, regarding iBGP topology:¶
Border routers only need to learn internal destinations to export towards ISPs. They do not require visibility into external routes learned by other border routers since transit traffic is prohibited. Thus, an iBGP session between BR1 and BR2 is unnecessary.¶
Internal core routers (IRs) must learn external routes imported by both border routers (BRs). However, they have no operational need to exchange routes with each other; hence, iBGP sessions between IRs are unnecessary.¶
Furthermore, establishing an iBGP session between BR1 and BR2 noticeably increases the operational risk of accidentally re-advertising external routes, which could inadvertently turn the stub AS into an unintended transit provider.¶
This example shows that in multihomed stub ASes, an iBGP full mesh is not strictly necessary and can be operationally detrimental.¶
A similar situation can arise in an edge ISP. This is illustrated in Figure 2, which depicts an ISP featuring:¶
Two upstream connections (Up1, Up2),¶
Three Points of Presence (PoPs) serving downstream customers,¶
One peering router (P) connected to an Internet Exchange Point (IXP).¶
<svg width="29cm" height="22cm" viewBox="399 170 570 421" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="Background">
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="861.912" y="173.988" width="106" height="49" rx="0" ry="0"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="698" y="172" width="106" height="49" rx="0" ry="0"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="684.037" y="513.287" width="63" height="29" rx="0" ry="0"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="903.4" y="514.2" width="63" height="29" rx="0" ry="0"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="798.2" y="561.6" width="63" height="29" rx="0" ry="0"/>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="882" y="347" width="63" height="29" rx="0" ry="0"/>
<text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="1367.24" y="275.322">
<tspan x="1367.24" y="275.322"></tspan>
</text>
<g>
<rect style="fill: #ffffff; fill-opacity: 1; stroke: none" x="737.6" y="181.747" width="28.65" height="26.7287"/>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="737.6" y="203.06">
<tspan x="737.6" y="203.06">T1</tspan>
</text>
</g>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="650.6" y="381.614">
<tspan x="650.6" y="381.614">ISP</tspan>
</text>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 2; stroke: #000000" x1="750" y1="230" x2="750.986" y2="343.994"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 2; stroke: #000000" x1="918" y1="228" x2="916.508" y2="342.194"/>
<text font-size="14.6078" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="705" y="267">
<tspan x="705" y="267">Ebgp</tspan>
</text>
<text font-size="14.6078" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="927.6" y="269.86">
<tspan x="927.6" y="269.86">Ebgp</tspan>
</text>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="732" y1="379" x2="731" y2="509"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="927" y1="379" x2="927" y2="508"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="753.462" y1="380.237" x2="823.462" y2="555.237"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="908.664" y1="379.069" x2="834.69" y2="560.01"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="777.444" y1="379.61" x2="909" y2="509"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="888.478" y1="376.494" x2="748" y2="508"/>
<g>
<rect style="fill: #ffffff; fill-opacity: 1; stroke: none" x="905.775" y="183.087" width="28.65" height="26.7287"/>
<text font-size="22.9616" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="905.775" y="204.4">
<tspan x="905.775" y="204.4">T2</tspan>
</text>
</g>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="721.75" y="344.075" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="736.913" y="362.422">
<tspan x="736.913" y="362.422">Up1</tspan>
</text>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="892.6" y="367.06">
<tspan x="892.6" y="367.06">Up2</tspan>
</text>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="803.6" y="580.06">
<tspan x="803.6" y="580.06">PoP2</tspan>
</text>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="689.362" y="533.822">
<tspan x="689.362" y="533.822">PoP1</tspan>
</text>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="907.6" y="533.56">
<tspan x="907.6" y="533.56">PoP3</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="621.6" y="411.3" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="648.1" y="430.8">
<tspan x="648.1" y="430.8">P</tspan>
</text>
<rect style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x="400.6" y="413.3" width="63" height="29" rx="0" ry="0"/>
<text font-size="16.9785" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="419.1" y="432.8">
<tspan x="419.1" y="432.8">IXP</tspan>
</text>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="688.608" y1="435.308" x2="718" y2="510"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="691.208" y1="425.608" x2="812" y2="559"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="689" y1="416" x2="898.808" y2="517.908"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="898" y1="529" x2="751.8" y2="529.4"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="723.008" y1="548.508" x2="793" y2="581"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #000000" x1="933.608" y1="546.808" x2="864" y2="583"/>
<line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 4; stroke: #000000" x1="620.6" y1="425.8" x2="466" y2="427"/>
<text font-size="14.6078" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="510" y="418">
<tspan x="510" y="418">n x Ebgp</tspan>
</text>
</g>
</svg>
Such an ISP must conform to the following transit rules:¶
It MUST NOT provide transit between upstream providers.¶
It MUST NOT provide transit between peers and upstream providers (in either direction).¶
It MUST only provide transit to its downstream customers.¶
Under these constraints, the routing requirements dictate that:¶
PoP routers must maintain full visibility of routes from upstreams (via Up1/Up2), peering points (via P), and other PoPs.¶
Upstream routers (Up1/Up2) and the peering router (P) only need to learn customer routes via the PoPs, and external routes via eBGP. They do not require visibility into each other's external routes.¶
Therefore, the optimized iBGP architecture establishes that:¶
PoP routers maintain iBGP sessions with all other BGP routers in the AS.¶
Up1, Up2, and P maintain iBGP sessions exclusively with the PoP routers, but not among themselves.¶
This design (see Figure 2) is simpler than a full mesh and reduces operational risk, particularly the risk of unintended transit between upstreams or peers.¶
As in the stub AS case, the failure of an upstream or peering link does not require alternative path visibility at the affected border router, because the PoP routers will autonomously stop forwarding traffic toward it once the failure triggers a route withdrawal.¶
Note that adopting a design based on Route Reflectors (RRs) can further simplify the iBGP topology, even for relatively small edge ISPs. For example, in the scenario shown in Figure 2, utilizing a central route reflector with iBGP sessions to all other routers in the AS would require only six iBGP sessions. This contrasts with the twelve sessions required by the partial-mesh design and the twenty-one sessions demanded by a traditional full mesh. Furthermore, with an adequate community-based configuration, the same isolation between router groups achieved by removing unnecessary iBGP sessions can be replicated within a route-reflector architecture.¶
While deploying an iBGP partial mesh is technically feasible in any AS that does not require full route visibility across all internal BGP speakers (i.e., non-transit ASes), its implementation is only recommended for stub ASes. For edge ISPs, although the partial-mesh option is viable and superior to a full mesh, utilizing route reflectors generally remains the best approach.¶
The use of an iBGP partial mesh in stub ASes is not a novel technique, but it has rarely been documented (for example, see the case described in Figure 5.21 in [Zhang-Bartell]. Currently, the dominant view in available documentation is that it is unacceptable to have multiple BGP routers in the same AS that are not connected via iBGP, even though it is common practice in stub ASes to forgo iBGP sessions between border routers for security and simplicity reasons.¶
In designs where border routers (BRs) do not maintain iBGP sessions between them, internal core routers (IRs) act as the focal points for route visibility and path selection. In such a design, in the event of an upstream failure affecting a specific BR, a transient time lag occurs between the detection of the link failure by the BR and the moment the IRs cease forwarding outbound traffic to that BR. In a traditional full-mesh or RR topology, traffic arriving at the affected BR during this window is dynamically rerouted to alternative BRs via internal iBGP paths. This convergence behavior could be considered an operational advantage of full-mesh or RR architectures over a partial mesh. However:¶
If a default backup route (as a floating static route) is configured on the affected BR, the behavior aligns with a full-mesh/RR topology; the BR immediately redirects outbound traffic toward the alternate BR upon losing its upstream link.¶
In any case, the time lag between link failure detection at the BR and route convergence at the IRs is minimal —on the order of milliseconds— rendering it insignificant in most enterprise and edge scenarios. This is because the BR will immediately send route withdraws to the IRs via iBGP, since the MRAI (Minimum Route Advertisement Interval) for iBGP is 0 seconds by default across modern routing platforms.¶
A main argument in favour of avoiding unnecessary iBGP sessions is the reduction of potential misconfiguration scenarios (e.g. unintended transit). However, topological simplification should be viewed as a complementary defense-in-depth measure, and not as a complete substitute for rigorous routing policy design enforced by well-defined prefix filters and export rules.¶
iBGP full mesh is not a protocol requirement, but a design choice driven by the need for route visibility and operational considerations.¶
iBGP full mesh is only strictly necessary among routers that must have full visibility of all external routes. This is, in transit ASes.¶
In multihomed stub ASes, deploying an iBGP full mesh violates the KISS principle ([RFC1958]) and introduces unnecessary operational risk.¶
In edge ISPs, an iBGP partial mesh offers a more robust deployment model than a full mesh, though route reflection remains the best practice.¶
The legacy assumption of a mandatory full-mesh design found in several foundational RFCs dates back to an era when transit providers constituted the vast majority of BGP deployments. Given the modern internet landscape, where multihoming and BGP utilization are standard requirements for enterprises, clarifying some RFCs would benefit the community, preventing the perpetuation of this architectural misconception about iBGP full-mesh requirement.¶
This memo includes no request to IANA.¶
This document does not modify the underlying security properties of any existing Internet protocol. However, adherence to the Simplicity Principle ([RFC1958]) directly enhances the stability and security of network architectures. Minimizing unnecessary iBGP sessions explicitly reduces the internal configuration surface, thereby mitigating risks associated with human error, such as accidental transit provisioning.¶
This document uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz.¶