rtgwg (Routing Area Working Group) J. M. Rivadeneyra, Ed.
Internet-DraftEuskal Herriko Unibertsitatea (University of the Basque Country)
Intended status: Informational 15 June 2026
Expires: 17 December 2026
On iBGP Full-Mesh Requirements
draft-rivadeneyra-no-ibgp-full-mesh-00
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rivadeneyra Expires 17 December 2026 [Page 1]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Origin of the Confusion . . . . . . . . . . . . . . . . . . . 3
3. When iBGP Full Mesh (or Its Alternatives) Is Required . . . . 4
4. When iBGP Full Mesh Is Not Required . . . . . . . . . . . . . 5
4.1. Multihomed Stub AS . . . . . . . . . . . . . . . . . . . 5
4.2. Edge ISP . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 10
5.1. Applicability of iBGP partial-mesh design . . . . . . . . 10
5.2. Convergence Behaviour . . . . . . . . . . . . . . . . . . 10
5.3. Risk of Misconfiguration . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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.
Rivadeneyra Expires 17 December 2026 [Page 2]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
1.1. Requirements Language
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.
2. Origin of the Confusion
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:
Rivadeneyra Expires 17 December 2026 [Page 3]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
“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.
3. When iBGP Full Mesh (or Its Alternatives) Is Required
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.
Rivadeneyra Expires 17 December 2026 [Page 4]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
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.
4. When iBGP Full Mesh Is Not Required
4.1. Multihomed Stub AS
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).
Figure 1: Figure 1: AS stub multihomed without an iBGP full mesh
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:
Rivadeneyra Expires 17 December 2026 [Page 6]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
* 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.
4.2. Edge ISP
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).
Figure 2: Figure 2: Edge ISP without an iBGP full mesh
Such an ISP must conform to the following transit rules:
1. It MUST NOT provide transit between upstream providers.
2. It MUST NOT provide transit between peers and upstream providers
(in either direction).
3. 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.
Rivadeneyra Expires 17 December 2026 [Page 9]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
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.
5. Operational Considerations
5.1. Applicability of iBGP partial-mesh design
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.
5.2. Convergence Behaviour
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
Rivadeneyra Expires 17 December 2026 [Page 10]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
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.
5.3. Risk of Misconfiguration
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.
6. Conclusions
* 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.
Rivadeneyra Expires 17 December 2026 [Page 11]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
* 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.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
9.2. Informative References
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1105, DOI 10.17487/RFC1105, June 1989,
.
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1163, DOI 10.17487/RFC1163, June 1990,
.
Rivadeneyra Expires 17 December 2026 [Page 12]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
(BGP-3)", RFC 1267, DOI 10.17487/RFC1267, October 1991,
.
[RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway
Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July
1994, .
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, DOI 10.17487/RFC1771, March 1995,
.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
.
[Zhang-Bartell]
Zhang, R. and M. Bartell, "BGP Design and Implementation",
Cisco Press, ISBN 9781587058646,
.
Acknowledgements
This document uses extracts from templates written by Pekka Savola,
Elwyn Davies and Henrik Levkowetz.
Author's Address
Jose Maria Rivadeneyra (editor)
Euskal Herriko Unibertsitatea (University of the Basque Country)
Ibaetako Campusa
Donostia - Gipuzkoa - Basque Country
Rivadeneyra Expires 17 December 2026 [Page 13]
Internet-Draft On iBGP Full-Mesh Requirements June 2026
Email: jm.rivadeneyra@ehu.eus
Rivadeneyra Expires 17 December 2026 [Page 14]