| Internet-Draft | Inter-Domain IBGP | August 2026 |
| Szarkowicz, et al. | Expires 18 February 2027 | [Page] |
This document describes the building of Inter-domain L3VPN architecture with internal BGP, applying the multi-domain options specified in BGP/MPLS IP Virtual Private Networks (VPNs) within a single Autonomous System, where route reflectors set the NEXT_HOP attribute to self as described in BGP Route Reflector with Next Hop Self.¶
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 18 February 2027.¶
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.¶
Service providers often partition (or divide) a large network into smaller IGP (Interior Gateway Protocol) domains that are interconnected via BGP (Border Gateway Protocol) only. This might be required for various reasons; for example:¶
The advantage of dividing the large network into smaller IGP domains can be numerous, with important examples like:¶
At the same time, dividing the network can be impactful and result in unwanted behavior for both the operator and its customers. For example, some BGP attributes, such as LOCAL_PREF, are not sent to the EBGP (external BGP) peers but are sent to IBGP (internal BGP) peers. Also, depending on the actual requirements, operators can selectively choose if they keep the originator NEXT_HOP attribute or change the NEXT_HOP attribute to some local address. Further, Constrained Route Distribution ( [RFC4684]) can be used to prevent DBR from sending VPN (Virtual Private Network) prefixes for VRFs (Virtual Routing and Forwarding instances) that are not locally attached to each region.¶
[RFC4364], in Section 10, describes three multi-domain L3VPN (Layer 3 Virtual Private Network) architectures - commonly referenced as Option 10A, Option 10B, and Option 10C - restricted to the use cases, where the domains are distinct BGP domains and use different AS (Autonomous System) numbers, therefore, these architectures use EBGP peerings between the domains. However, many operators might segment the network into multiple IGP domains while maintaining a single BGP domain, with one AS number used across the IGP domains. This is especially the case when migrating an existing network into multiple IGP domains (brownfield deployment). Operationally, it is often too complex to migrate separated domains to new AS numbers. As a result, IBGP peers are used between IGP domains. In multi-domain architecture there might be a need to modify the NEXT_HOP path attribute at the domain boundary. While this is the default behavior for EBGP ( [RFC4271], Section 5.1.3), it is not recommended behavior for IBGP ( [RFC4456], Section 10, recommends keeping NEXT_HOP path attribute unmodified when reflecting the NLRIs - Network Layer Reachability Information - between IBGP peers).¶
In a network scenario where domains are interconnected using IBGP, and the same BGP AS number is used across multiple domains, the Accumulated IGP AIGP metric (as specified in [RFC7311]) remains preserved across domain boundaries. This preservation is due to IBGP sessions maintaining internal BGP attributes, including AIGP, ensuring the expected path selection based on accumulated internal IGP metrics.¶
The underlying protocol behavior, a route reflector reflecting routes with the NEXT_HOP attribute set to self, together with approaches to avoid forwarding loops between redundant reflectors, is described in [I-D.ietf-idr-bgp-fwd-rr]. This document describes the use case: applying the Inter-AS Options 10A, 10B, and 10C of [RFC4364] between IGP domains of a single AS, over IBGP peerings.¶
This document introduces no new BGP protocol extensions or AFI/SAFI assignments. It documents deployment guidance for single-AS, multi-IGP-domain environments where IBGP is used between domains and where DBRs/RRs intentionally modify NEXT_HOP while preserving other IBGP attributes (including AIGP) for predictable path selection.¶
The procedures in this document are described for VPN-IPv4 and VPN-IPv6 (SAFI=128) services. The underlying mechanism, IBGP peerings between IGP domains with the DBR acting as an on-the-path route reflector that sets NEXT_HOP to self, is not specific to these address families and can also apply to other BGP service families, such as EVPN ([RFC7432]). However, EVPN defines additional procedures that interact with the next-hop rewrite at a domain boundary, for example multi-homing aliasing and mass withdrawal. EVPN-specific procedures are outside the scope of this document.¶
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.¶
Inter-domain L3VPN architecture based on so called Option 10A ( [RFC4364], Section 10, "a)" bullet point) relies on multiple logical interfaces (typically, sub-interfaces with unique VLAN - Virtual Local Area Network - per sub-interface) and multiple single-hop external BGP (SH-EBGP) peerings (single peering per sub-interface) between ASBRs (autonomous system boundary router), in an architecture as outlined in Figure 1. Each SH-EBGP peering is responsible for exchanging unicast IPv4 (AFI/SAFI=1/1) or unicast IPv6 (AFI/SAFI=2/1) NLRIs for single L3VPN service. Essentially, in this architecture ASBRs consider each other as CE (Customer Edge) devices. RRs within each AS depicted in Figure 1 SHOULD be used. However, in small scale domains (for example, small access rings with few PEs), RR function could be placed on ASBRs, where multi-hop internal BGP (MH-IBGP) peerings are directly established between PEs and ASBRs.¶
SH-EBGP
MH-IBGP MH-IBGP SAFI=1 MH-IBGP MH-IBGP
SAFI=128 SAFI=128 ◀─────────▶ SAFI=128 SAFI=128
◀───────▶ ◀───────▶ ◀─────────▶ ◀───────▶ ◀───────▶
nhs nhs ◀─────────▶ nhs nhs
nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐
┌──┐ ┌─────┐ ┌─────┐ ┌──┐
│PE│ │ ├───────┤ │ │PE│
└──┘ │ASBR1├───────┤ASBR3│ └──┘
│ ╲ ╱│ ├───────┤ │╲ ╱ │
╲ ╱ └─────┘ └─────┘ ╲ ╱
│ ╲ ╱ │ │ ╲ ╱ │
╲┌──┐╱ ╲┌──┐╱
│ │RR│ │ │ │RR│ │
╱└──┘╲ ╱└──┘╲
│ ╱ ╲ │ │ ╱ ╲ │
╱ ╲ ┌─────┐ ┌─────┐ ╱ ╲
│ ╱ ╲│ ├───────┤ │╱ ╲ │
┌──┐ │ASBR2├───────┤ASBR4│ ┌──┐
│PE│ AS 64501 │ ├───────┤ │ AS 64502 │PE│
└──┘ └─────┘ └─────┘ └──┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ─ ─ ┘
¶
This architecture does not require an end-to-end LSP (label switched path) leading from a packet's ingress PE in one AS to its egress PE in another AS, as the user packets exchanged between ASBRs are native IP (no MPLS - Multiprotocol Label Switching - encapsulation) packets. Hence, each ASBR has potentially multiple L3VPN service instances, and performs MPLS encapsulation/decapsulation, which is typical PE function. At the control plane level, each ASBR performs conversion between VPN-IPv4/VPN-IPv6 (SAFI=128) and unicast IPv4/IPv6 (SAFI=1) NLRIs. When these NLRIs are advertised by ASBR, NEXT_HOP attribute MUST be modified to self (nhs).¶
In the original context described in [RFC4364], domains are BGP domains with different ASs, therefore, multiple BGP peerings between two BGP domains are EBGP. However, Option 10A concept can be applied not only to BGP domains with different AS numbers, but as well as to IGP domains with the same AS number, as depicted in Figure 2.¶
MH-IBGP MH-IBGP SH-IBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=1 SAFI=128 SAFI=128
◀───────▶
◀───────▶ ◀───────▶ ◀───────▶ ◀───────▶ ◀───────▶
nhs nhs ◀───────▶ nhs nhs
nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┌ ─ ─ ─ ─ ─ ─ ─ ─
┌──┐ ┌─┴──┐ ┌────┐ ┌─┴┐
│PE│ Domain A │ ├───────┤ │ Domain B │PE│
└──┘ │DBR1├───────┤DBR3│ └─┬┘
│ ╲ ╱│ ├───────┤ │╲ ╱
╲ ╱ └─┬──┘ └────┘ ╲ ╱ │
│ ╲ ╱ │ ╲ ╱
╲┌──┐╱ │ ╲┌──┐╱ │
│ │RR│ │ │RR│
╱└──┘╲ │ ╱└──┘╲ │
│ ╱ ╲ │ ╱ ╲
╱ ╲ ┌─┴──┐ ┌────┐ ╱ ╲ │
│ ╱ ╲│ ├───────┤ │╱ ╲
┌──┐ │DBR2├───────┤DBR4│ ┌─┴┐
│PE│ AS 64500 │ ├───────┤ │ AS 64500 │PE│
└──┘ └─┬──┘ └────┘ └─┬┘
└ ─ ─ ─ ─ ─ ─ ─ ─ └ ─ ─ ─ ─ ─ ─ ─ ─
¶
The main differences, compared to the original Inter-domain Option 10A, are:¶
Loop prevention requires attention in this IBGP variant, since rejection based on the AS_PATH attribute does not apply within a single AS. Two CLUSTER_ID configurations are relevant on a DBR: the global CLUSTER_ID, used for regular route reflection, and an optional VRF-level CLUSTER_ID, used when the DBR re-originates routes at the SAFI-128 to SAFI-1 translation. By default, no VRF-level CLUSTER_ID is configured, and not all implementations support appending a CLUSTER_ID at this SAFI translation.¶
When Domain A routes learned within SAFI-128 are advertised over SAFI-1 to the DBR node in Domain B, the CLUSTER_LIST attribute is updated during the SAFI translation: if a VRF-level CLUSTER_ID is configured on the DBR and the implementation supports the SAFI-transition append, the DBR MUST append it to the CLUSTER_LIST. This ensures a clear path history, so that standard route reflection loop avoidance ( [RFC4456]) applies across the translation. The absence of a VRF-level CLUSTER_ID does not prevent advertisement: the DBR still advertises the routes across the domain boundary, preserving the current default behavior of existing implementations.¶
When the CLUSTER_LIST append is not performed (no VRF-level CLUSTER_ID is configured, or the implementation does not support the append), the operator MUST deploy region-specific community tagging for loop prevention. Region A (DBR1) tags all routes received from its local RR with a region-specific community attribute, using a specific value as the region identifier (e.g., name COMM-DOMAIN-A with a value 1234:4321). This tagging helps identify routes originating from Region A. Before advertising these routes to Region B (DBR3), DBR1 ensures that the COMM-DOMAIN-A community is attached. Upon receiving routes from DBR3, DBR1 imports all routes but rejects any with the COMM-DOMAIN-A community. This prevents the re-advertisement of the same routes back into Region A, thereby avoiding routing loops. Operators MAY deploy the community-based method even where the CLUSTER_LIST append is performed, to ensure consistent behavior across vendors.¶
Other aspects of the architecture are similar.¶
Inter-domain L3VPN architecture based on so called Option 10B ( [RFC4364], Section 10, "b)" bullet point) relies on exchanging VPN-IPv4 (AFI/SAFI=1/128) or VPN-IPv6 (AFI/SAFI=2/128) NLRIs via direct SH-EBGP peering between ASBRs, in an architecture as outlined in Figure 3. RRs within each AS depicted in Figure 3 SHOULD be used. However, in small scale domains (for example, small access rings with few PEs), RR function could be placed on ASBRs, where multi-hop internal BGP (MH-IBGP) peerings are directly established between PEs and ASBRs.¶
MH-IBGP MH-IBGP SH-EBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128 SAFI=128 SAFI=128
◀───────▶ ◀───────▶ ◀─────────▶ ◀───────▶ ◀───────▶
nhs nhs nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐
┌──┐ ┌─────┐ ┌─────┐ ┌──┐
│PE│ │ASBR1├───────┤ASBR3│ │PE│
└──┘ └─────┘ └─────┘ └──┘
│ ╲ ╱ │ │ ╲ ╱ │
╲ ╱ ╲ ╱
│ ╲ ╱ │ │ ╲ ╱ │
╲┌──┐╱ ╲┌──┐╱
│ │RR│ │ │ │RR│ │
╱└──┘╲ ╱└──┘╲
│ ╱ ╲ │ │ ╱ ╲ │
╱ ╲ ╱ ╲
│ ╱ ╲ │ │ ╱ ╲ │
┌──┐ ┌─────┐ ┌─────┐ ┌──┐
│PE│ AS 64501 │ASBR2├───────┤ASBR4│ AS 64502 │PE│
└──┘ └─────┘ └─────┘ └──┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ─ ─ ┘
¶
This architecture requires an end-to-end LSP leading from a packet's ingress PE in one AS to its egress PE in another AS. Hence, at each ASBR, NEXT_HOP attribute MUST be modified to self (nhs), which results in new service label allocation and programming of appropriate label forwarding entries in the data plane. On the ASBR-to-ASBR link between two ASs there is no additional 'labeled transport' (i.e., no LDP - Label Distribution Protocol, RSVP - Resource Reservation Protocol, SR - Segment Routing, ...) protocol - the packets are transmitted on the ASBR-to-ASBR link with single L3VPN service label.¶
In the original context described in [RFC4364], domains are BGP domains with different ASs, therefore, the BGP peering between two BGP domains is EBGP. However, Option 10B concept can be applied not only to BGP domains with different AS numbers, but also to IGP domains with the same AS number, as depicted in Figure 4.¶
MH-IBGP MH-IBGP SH-IBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128 SAFI=128 SAFI=128
SAFI=132 SAFI=132 SAFI=132 SAFI=132 SAFI=132
◀───────▶ ◀───────▶ ◀───────▶ ◀───────▶ ◀───────▶
nhs nhs nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┌ ─ ─ ─ ─ ─ ─ ─ ─
┌──┐ ┌─┴──┐ ┌────┐ ┌─┴┐
│PE│ Domain A │DBR1├───────┤DBR3│ Domain B │PE│
└──┘ └─┬──┘ └────┘ └─┬┘
│ ╲ ╱ C C │ ╲ ╱
╲ ╱ │ l l ╲ ╱ │
│ ╲ ╱ u u │ ╲ ╱
╲┌──┐╱ │ s s ╲┌──┐╱ │
│ │RR│ t t │ │RR│
╱└──┘╲ │ e e ╱└──┘╲ │
│ ╱ ╲ r r │ ╱ ╲
╱ ╲ │ ╱ ╲ │
│ ╱ ╲ A B │ ╱ ╲
┌──┐ ┌─┴──┐ ┌────┐ ┌─┴┐
│PE│ AS 64500 │DBR2├───────┤DBR4│ AS 64500 │PE│
└──┘ └─┬──┘ └────┘ └─┬┘
└ ─ ─ ─ ─ ─ ─ ─ ─ └ ─ ─ ─ ─ ─ ─ ─ ─
¶
Similar to the Inter-Domain Option 10A case, main differences, when comparing to the original Inter-domain Option 10B are:¶
This implies that DBR with RR function MUST change the NEXT_HOP attribute to self, when reflecting these NLRIs.¶
It is strongly advisable to control the exchange of VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs between domains via Constrained Route Distribution ( [RFC4684]). Therefore, DBR-to-DBR SH-IBGP peering, in addition to SAFI=128, SHOULD include Route Target Constraint - RTC (SAFI=132) - as well, and DBRs SHOULD be provisioned to exchange between each other only desired RTCs. Please note, RTC MAY be used inside of each IGP domain, too, to control route distribution within IGP domains.¶
When RTC is deployed on the DBR-to-DBR peering, a DBR with no locally attached VRFs imports no Route Targets of its own, and can express interest in the Route Targets it relays only by propagating the RT membership NLRIs received from within its own IGP domain ([RFC4684], Section 3.2). If it advertises none, its peer withholds all VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs ([RFC4684], Section 6), and inter-domain route distribution stops without any protocol error being reported. Such a DBR MUST therefore either run RTC on its intra-domain peerings as well, or be provisioned to originate RT membership information covering the Route Targets it relays; the default Route Target, encoded as a zero-length prefix ([RFC4684], Section 4), MAY be used for the latter, at the cost of the filtering RTC is deployed to provide.¶
Important aspect of the inter-domain connectivity, when the domains are interconnected via multiple interconnection points, as depicted in Figure 4, is loop prevention. In classic Inter-AS Option 10B, with different AS numbers used in each BGP domain, and EBGP peerings between BGP domains, loop prevention is ensured by rejecting updates containing local AS number in the AS_PATH attribute. In the use case with multiple IGP domains and single BGP domain, each DBR is on-the-path RR, thus is associated with a CLUSTER_ID. One option for CLUSTER_ID allocation is that each DBR is configured with a unique CLUSTER_ID. Another option for CLUSTER_ID allocation is that each DBR pair in the IGP domain uses unique CLUSTER_ID, as depicted in Figure 4. Using the first CLUSTER_ID allocation scheme, there is a risk of a BGP routing loop occurring, since all of the DBRs are reflecting prefixes as RRs in the same AS with next-hop self. To prevent the DBRs of the same IGP domain from accepting updates from each other, they MUST use the same CLUSTER_ID. In this case, a DBR will discard a prefix update that has the same CLUSTER_ID as itself in order to prevent routing information loops in BGP. For example, DBR1 and DBR2 configured with one CLUSTER_ID, while DBR3 and DBR4 have another single CLUSTER_ID. This mechanism, loop prevention based on CLUSTER_LIST filtering, is described in [RFC4456], Section 8 - Avoidance of Routing Information Loops.¶
When using IBGP, instead of EBGP, small variation of the architecture can be achieved, by collapsing two separate DBRs to single, collapsed DBR, as depicted in Figure 5.¶
MH-IBGP MH-IBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128 SAFI=128
SAFI=132 SAFI=132 SAFI=132 SAFI=132
◀───────▶ ◀───────▶ ◀───────▶ ◀───────▶
nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ┐
┌──┐ ┌───────┐ ┌──┐
│PE│ Domain A │ DBR 1 │ Domain B │PE│
└──┘ └───────┘ └──┘
│ ╲ ╱ │ C │ ╲ ╱ │
╲ ╱ l ╲ ╱
│ ╲ ╱ │ u │ ╲ ╱ │
╲┌──┐╱ s ╲┌──┐╱
│ │RR│ │ t │ │RR│ │
╱└──┘╲ e ╱└──┘╲
│ ╱ ╲ │ r │ ╱ ╲ │
╱ ╲ ╱ ╲
│ ╱ ╲ │ A │ ╱ ╲ │
┌──┐ ┌───────┐ ┌──┐
│PE│ AS 64500 │ DBR 2 │ AS 64500 │PE│
└──┘ └───────┘ └──┘
└ ─ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ─ ┘
¶
Similarly to the previous example, DBR MUST change the NEXT_HOP attribute to self, when reflecting VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs, and DBR SHOULD use RTC (SAFI=132) to control the exchange of VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs between domains. RTC MAY be used inside of each domain.¶
Inter-domain L3VPN architecture based on so called Option 10C ( [RFC4364], Section 10, "c)" bullet point) relies on exchanging VPN-IPv4 (AFI/SAFI=1/128) or VPN-IPv6 (AFI/SAFI=2/128) NLRIs via MH-EBGP peering between BGP domains, without changing the NEXT_HOP attribute, and exchanging labeled unicast IPv4 or labeled unicast IPv6 (SAFI=4) host routes (PE loopbacks) via direct SH-EBGP peering between ASBRs, changing the NEXT_HOP attribute at the BGP domain boundaries, in an architecture as outlined in Figure 6. As in previous architectures, RRs within each AS depicted in Figure 6 SHOULD be used. One of the main objectives of Option 10C architecture is to offload ASBRs from the task of maintaining/distributing VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs, without RR these NLRIs would need to be distributed via direct MH-EBGP peerings between PEs from different BGP domains. Such approach makes the design very impractical and not scalable, therefore, in Option 10C RRs SHOULD be deployed, and MH-EBGP peerings to distribute VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs between BGP domains SHOULD be established between RRs.¶
MH-IBGP MH-EBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128
◀───────▶ ◀───────────────────────────────▶ ◀───────▶
nhs nhs
MH-IBGP SH-EBGP MH-IBGP
SAFI=4 SAFI=4 SAFI=4
◀─────────────────▶ ◀───────────▶ ◀─────────────────▶
nhs nhs nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐
┌──┐ ┌─────┐ ┌─────┐ ┌──┐
│PE│ │ASBR1├───────┤ASBR3│ │PE│
└──┘ └─────┘ └─────┘ └──┘
│ ╲ ╱ │ │ ╲ ╱ │
╲ ╱ ╲ ╱
│ ╲ ╱ │ │ ╲ ╱ │
╲┌──┐╱ ╲┌──┐╱
│ │RR│ │ │ │RR│ │
╱└──┘╲ ╱└──┘╲
│ ╱ ╲ │ │ ╱ ╲ │
╱ ╲ ╱ ╲
│ ╱ ╲ │ │ ╱ ╲ │
┌──┐ ┌─────┐ ┌─────┐ ┌──┐
│PE│ AS 64501 │ASBR2├───────┤ASBR4│ AS 64502 │PE│
└──┘ └─────┘ └─────┘ └──┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ─ ─ ┘
¶
This architecture requires an end-to-end LSP leading from a packet's ingress PE in one AS to its egress PE in another AS. Hence, at each ASBR, NEXT_HOP attribute for labeled unicast IPv4 or labeled unicast IPv6 (SAFI=4) NLRI MUST be modified to self (nhs), which results in new transport label allocation, and programming of appropriate label forwarding entries in the data plane. In the packets traversing ASBR-to-ASBR link between two ASs, similar to the links within each AS, there is additional transport label at the top of the label stack in addition to the L3VPN service label. This transport label is exchanged via BGP peering with SAFI=4.¶
In the original context described in [RFC4364], domains are BGP domains with different AS numbers, therefore, the BGP peerings (both for SAFI=4 and SAFI=128) between two BGP domains are EBGP. However, Option 10C concept can be applied not only to BGP domains with different AS numbers, but as well to IGP domains with the same AS number, as depicted in Figure 7.¶
MH-IBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128
SAFI=132 SAFI=132 SAFI=132
◀───────▶ ◀───────────────────────────▶ ◀───────▶
nhs nhs
MH-IBGP SH-IBGP MH-IBGP
SAFI=4 SAFI=4 SAFI=4
◀─────────────────▶ ◀───────▶ ◀─────────────────▶
nhs nhs nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ─ ┌ ─ ─ ─ ─ ─ ─ ─ ─
┌──┐ ┌─┴──┐ ┌────┐ ┌─┴┐
│PE│ Domain A │DBR1├───────┤DBR3│ Domain B │PE│
└──┘ └─┬──┘ └────┘ └─┬┘
│ ╲ ╱ C C │ ╲ ╱
╲ ╱ │ l l ╲ ╱ │
│ ╲ ╱ u u │ ╲ ╱
╲┌──┐╱ │ s s ╲┌──┐╱ │
│ │RR│ t t │ │RR│
╱└──┘╲ │ e e ╱└──┘╲ │
│ ╱ ╲ r r │ ╱ ╲
╱ ╲ │ ╱ ╲ │
│ ╱ ╲ A B │ ╱ ╲
┌──┐ ┌─┴──┐ ┌────┐ ┌─┴┐
│PE│ AS 64500 │DBR2├───────┤DBR4│ AS 64500 │PE│
└──┘ └─┬──┘ └────┘ └─┬┘
└ ─ ─ ─ ─ ─ ─ ─ ─ └ ─ ─ ─ ─ ─ ─ ─ ─
¶
Again, the differences compared to the original Inter-domain Option 10C are:¶
Remaining aspects of the architecture are similar. This implies that IGP domain boundary router (DBR) becomes inline (on-the-path) RR for labeled unicast IPv4 or labeled unicast IPv6 (SAFI=4) NLRIs, and MUST change the NEXT_HOP attribute to self, when reflecting these NLRIs.¶
Because no IGP is run between the IGP domains, the MH-IBGP SAFI=128 peering between RRs in different IGP domains cannot be established until the RR loopback addresses are mutually reachable across the domain boundary. Inter-domain reachability MUST therefore be provisioned for the RR loopback addresses, and not only for the PE loopback addresses. In this architecture that is normally achieved by including the RR loopback addresses in the labeled unicast IPv4 or labeled unicast IPv6 (SAFI=4) host routes exchanged between the IGP domains.¶
As in Option 10B scenario, it is strongly advisable to control the exchange of VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs between domains via Constrained Route Distribution ( [RFC4684]). Therefore, MH-IBGP peering between RRs in different IGP domains, in addition to SAFI=128, SHOULD include RTC (SAFI=132), and RRs SHOULD be provisioned to exchange between each other only desired RTCs. Please note, RTC MAY be used inside of each domain, too, to control route distribution within IGP domains.¶
When using IBGP, instead of EBGP, a small variation of the architecture can be achieved, by collapsing two separate DBRs to single, collapsed DBR, as depicted in Figure 8.¶
MH-IBGP MH-IBGP MH-IBGP
SAFI=128 SAFI=128 SAFI=128
SAFI=132 SAFI=132 SAFI=132
◀───────▶ ◀─────────────────▶ ◀───────▶
nhs nhs
MH-IBGP MH-IBGP
SAFI=4 SAFI=4
◀─────────────────▶ ◀─────────────────▶
nhs nhs nhs nhs
┌ ─ ─ ─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ─ ─ ┐
┌──┐ ┌───────┐ ┌──┐
│PE│ Domain A │ DBR 1 │ Domain B │PE│
└──┘ └───────┘ └──┘
│ ╲ ╱ │ C │ ╲ ╱ │
╲ ╱ l ╲ ╱
│ ╲ ╱ │ u │ ╲ ╱ │
╲┌──┐╱ s ╲┌──┐╱
│ │RR│ │ t │ │RR│ │
╱└──┘╲ e ╱└──┘╲
│ ╱ ╲ │ r │ ╱ ╲ │
╱ ╲ ╱ ╲
│ ╱ ╲ │ A │ ╱ ╲ │
┌──┐ ┌───────┐ ┌──┐
│PE│ AS 64500 │ DBR 2 │ AS 64500 │PE│
└──┘ └───────┘ └──┘
└ ─ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ─ ┘
¶
Similarly to the previous example, DBR MUST change the NEXT_HOP attribute to self, when reflecting labeled unicast IPv4 or labeled unicast IPv6 (SAFI=4) NLRIs, and RR SHOULD use RTC (SAFI=132) to control the exchange of VPN-IPv4/VPN-IPv6 (SAFI=128) NLRIs between IGP domains. RTC MAY be used inside of each domain.¶
This memo includes no request to IANA.¶
As a general rule, traffic spoofing between domains must be prevented. In Option A, the interfaces connecting the two domains do not transport labeled traffic; they only carry regular IP traffic. Therefore, well-established IP mechanisms, like filtering unwanted traffic, can be used to prevent spoofing.¶
BGP options B and C are more vulnerable due to possible unauthorized labeled forwarding or label spoofing, especially when engaging in peering arrangements with third-party DBRs. ( [RFC4364]), Section 6: "Maintaining Proper Isolation of VPNs", addresses the requirements for proper isolation of VPNs. If MPLS is being used as the tunneling technology, this means that a DBR MUST NOT accept a labeled packet from any adjacent DBR unless the following two conditions hold:¶
Defining a concrete solution to address above isolation requirements is out of scope for this document. However, a possible approach to mitigate these concerns, for both Option B and Option C, is described in [I-D.kaliraj-bess-bgp-sig-private-mpls-labels], with Section 6.1 providing specific examples. With this method, distinct context table per BGP peer (or group of peers) is established. This table only contains labels advertised to specific BGP peer (group of peers). Interfaces facilitating DBR connections, where Option B or Option C is implemented, SHOULD be associated with this newly introduced context table. Consequently, the label lookup for packets received over the interface from specific DBR happens within the context of this table. Packets with labels not advertised to DBR, fail the lookup and are dropped.¶
Additionally, for Options B and C, an MPLS filter can be implemented, specifying inner IPv4 or IPv6, under one or more labeled packets. The number of labels in a filter is crucial for differentiating the transport and enabling the filtering of spoofed traffic originating from unwanted source IPv4 or IPv6 addresses.¶
AFI: Address Family Identifier¶
AS: Autonomous System¶
ASBR: Autonomous System Boundary Router¶
BGP: Border Gateway Protocol¶
CE: Customer Edge¶
DBR: Domain Boundary Router¶
EBGP: External Border Gateway Protocol¶
EVPN: Ethernet Virtual Private Network¶
IBGP: Internal Border Gateway Protocol¶
IGP: Interior Gateway Protocol¶
IP: Internet Protocol¶
IPv4: Internet Protocol version 4¶
IPv6: Internet Protocol version 6¶
L3VPN: Layer 3 Virtual Private Network¶
LDP: Label Distribution Protocol¶
LSP: Label Switched Path¶
MH-IBGP: Multi-hop Internal Border Gateway Protocol¶
MPLS: Multiprotocol Label Switching¶
nhs: next-hop self¶
NLRI: Network Layer Reachability Information¶
PE: Provider Edge¶
RR: Route Reflector¶
RSVP: Resource Reservation Protocol¶
RTC: Route Target Constraint¶
SAFI: Subsequent Address Family Identifier¶
SH-EBGP: Single-hop External Border Gateway Protocol¶
SR: Segment Routing¶
VLAN: Virtual Local Area Network¶
VPN: Virtual Private Network¶
VRF: Virtual Routing and Forwarding¶
The authors would like to thank Robert Raszuk, and Bruno Decraene for their reviews of this document and for providing valuable comments.¶