Origin-Leaf Identification in Data-Center eBGP Underlays using BGP Large Communities

1.1. Scope

This document is limited to plain IPv4 and IPv6 unicast eBGP underlays. Overlay technologies such as EVPN/VXLAN are discussed only insofar as they affect the choice of underlay mechanism (see Section 8). Implementation-specific data-plane programming details (for example, how a particular routing stack propagates metadata to an ASIC) are out of scope; this document focuses on the control-plane encoding and its propagation properties.¶

The primary focus is origin-leaf identification; Section 7.2 describes an optional profile for locally significant route-attachment metadata using the same Large Community construction.¶

1.2. 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.¶

This document is Informational and defines no new protocol elements. Where these key words appear, they express requirements and recommendations for deployments that follow the operational practice described here; they do not impose conformance requirements on BGP protocol implementations.¶

3.1. What the AS_PATH Provides

The BGP AS_PATH attribute records every Autonomous System a route has traversed and serves two purposes: loop prevention, and identification of the AS from which a prefix originated. Origin identification is therefore at AS granularity; whether it also identifies the originating leaf depends entirely on the AS-numbering model in use:¶

Even in the best case (a unique ASN per leaf), the AS_PATH is a path descriptor rather than a structured tag. Extracting leaf identity from it requires matching specific ASN values, which is brittle when ASN assignment changes and provides no room for structured metadata such as pod, rack, or role.¶

3.2. Lack of an Established Practice

BGP offers several community mechanisms - Standard Communities [RFC1997], Extended Communities [RFC4360], and Large Communities [RFC8092] - any of which could, in principle, carry an origin identifier. However, there is no documented, interoperable practice describing which mechanism to use for DC underlay origin-leaf tagging, nor how to encode the identifier. The result is ad hoc, per-operator solutions that do not interoperate and that are difficult to reason about operationally.¶

3.3. Multi-Hop Survival Requirement

An origin-leaf identifier must survive every eBGP hop between the originating and receiving leaf. In a two-tier spine-leaf fabric a prefix crosses at least two eBGP hops (leaf to spine, spine to leaf). In a three-tier fabric with super-spines a prefix crosses at least four eBGP hops (leaf to spine to super-spine to spine to leaf). The chosen mechanism must therefore be preserved, unmodified, across all intermediate BGP speakers, without per-hop strip and re-add, when community advertisement is enabled across the propagation path.¶

4.1. Origin-Leaf-Aware Policy

At a receiving leaf, BGP learns routes carrying the originating leaf's identifier. The operator extracts this identifier and uses it to drive behavior that depends on the leaf at which traffic toward the prefix exits the fabric, for example:¶

• programming forwarding policy that depends on the originating leaf or pod;¶
• applying Quality of Service (QoS), Access Control List (ACL), or traffic-steering rules per originating leaf, for example to support asymmetric routing or service-level objectives;¶
• implementing pod-aware Equal-Cost Multi-Path (ECMP) or traffic isolation;¶
• applying BGP policy that targets a specific originating leaf (for example, adjusting LOCAL_PREF on, or rejecting, routes from a leaf under maintenance). Coarser location-based preference (for example, per site or region) is commonly handled with location communities and is not the focus of this document.¶

The key requirement is that the origin-leaf identity be recoverable as structured metadata rather than being buried in an attribute that is expensive or ambiguous to parse.¶

4.2. Operational Visibility

Operators can identify the originating leaf of a prefix directly from BGP route attributes, using an identifier that is independent of the fabric's AS-numbering model, rather than inferring it indirectly (for example, from AS_PATH contents).¶

6.1. Per-Leaf Unique Private ASN (AS_PATH Encoding)

Each leaf is assigned a unique private ASN, so that the origin AS conveyed by the AS_PATH (Section 3.1) identifies the originating leaf, and policy can match on it.¶

Advantages: no additional configuration beyond ASN assignment; works with standard eBGP; survives an unlimited number of hops.¶

Drawbacks: no structured encoding (pod/rack relationships require an external mapping); matching on AS_PATH is brittle when ASN assignment changes; it fails entirely when leaves share an ASN (the per-tier model); the private-ASN pool is finite; and it carries no semantic metadata. It therefore does not satisfy R1, R5, R6, or R11 in the general case.¶

6.2. BGP Standard Community

At the originating leaf, a Standard Community "AA:NN" [RFC1997] encodes a fabric identifier and a leaf identifier.¶

Advantages: universally supported; survives eBGP hops when not stripped; simple to configure and well understood.¶

Drawbacks: each field is only 16 bits. Operators do build hierarchical encodings within that space, but 16 bits is too small to carry pod, leaf, and port at DC scale without aggressive packing. The namespace is also shared with other policy uses (QoS marking, blackholing, and so on), creating a risk of collision (R12). It satisfies R6 only for small fabrics.¶

6.3. BGP Large Community

A Large Community [RFC8092] is three 32-bit integers, "global-administrator:local-data-1:local-data-2". The Global Administrator field carries an ASN that acts as the assigning authority, and the two Local Data fields carry operator-defined values.¶

Advantages: 32 bits per field (ample scale); a namespace separate from Standard Communities and partitioned by assigning ASN; standardized and widely supported; and no effect on BGP best-path selection. It satisfies R1 through R8, R9 (see Section 8), R11 (subject to the caveat for the per-pod-ASN encoding in Section 7.1.1), R12 (see Section 7.1), and R13 (see Section 12).¶

The same mechanism can also encode route-associated switch/port metadata using operator-defined local identifiers, avoiding the need for a new type-specific BGP community when the information is consumed within a single administrative domain (see Section 7.2); this addresses R10.¶

Considerations: Large Communities are widely used for other purposes (for example, informational and action communities [RFC8195]), possibly under the same ASN an operator would choose as assigning authority. An origin-leaf encoding therefore cannot assume that it owns the entire Large Community space of that ASN; it either uses an ASN dedicated to this purpose or reserves a function value within a shared ASN (see Section 7.1). Like other communities, a Large Community is not sent to a peer unless the sender is configured to advertise Large Communities, and it is less universally deployed on legacy equipment than Standard Communities.¶

6.4. BGP Site-of-Origin (SoO) Extended Community

The Site-of-Origin (SoO) Extended Community [RFC4364] is a transitive Extended Community used by BGP VPN deployments, and some EVPN deployments and implementations, to prevent routing loops by identifying the site from which a route originated. When a route carrying an SoO is received in a context configured with the same site-origin value, the route is typically rejected or suppressed to avoid re-advertising it back into the originating site. In L3VPN this is the classic multihomed CE/site loop-prevention case of [RFC4364]; in EVPN and symmetric L3VNI designs SoO is likewise used to prevent re-advertisement loops across multihomed sites. Each leaf could set a unique SoO value on its originated routes.¶

Advantages: standardized and transitive; can be matched in policy and extracted to local metadata; and it aligns with EVPN deployments that already use SoO.¶

Drawbacks: SoO's loop-prevention behavior is useful for its intended VPN/EVPN use case, but it makes SoO a less clean fit for plain unicast underlay metadata, where the desired property is passive origin identification without any implicit loop-prevention semantics. Where an operator does configure SoO-based procedures on the underlay, a route whose SoO matches the local site-origin context may be rejected or suppressed; in a correctly numbered fabric this does not trigger, but misconfiguration or unexpected reflection can cause hard-to-diagnose route loss (relevant to R3). Finally, SoO provides only two fields with a 16-bit value, so it cannot cleanly encode pod, leaf, and port (weak on R6). SoO may be an acceptable choice when an EVPN overlay is already deployed and a single mechanism is preferred; see Section 8.¶

6.5. Generic (Opaque) Extended Community

A transitive opaque Extended Community [RFC4360] could carry an opaque leaf identifier in its value bits.¶

Advantages: transitive across eBGP; type-coded.¶

Drawbacks: the encoding is opaque with no standardized semantic meaning, configuration is more complex, and operational visibility is poor compared with Large Communities or SoO. It is not recommended for this use case.¶

6.6. Future: Path-Recording Attributes

Work-in-progress BGP extensions that record the set of nodes a route has traversed could, in the future, expose the originating leaf as the first node in a recorded path, in addition to full hop-by-hop path visibility. Such mechanisms are broader than the origin-only requirement addressed here, are not yet standardized, and have uncertain deployment timelines. They may become relevant for use cases requiring full path visibility (for example, advanced traffic engineering or SLA monitoring) but are not recommended for origin-leaf-only identification today.¶

6.7. Comparison

7.1. Encoding

The Global Administrator field of the Large Community carries an assigning ASN that serves as the authority for the origin identifier, preserving its RFC 8092 meaning. Because the same ASN may also be the Global Administrator of other Large Communities (for example, those following [RFC8195]), the origin-leaf identifier MUST NOT overlap with any other Large Community defined under the same assigning ASN. Two namespace allocation models achieve this: a dedicated assigning ASN (Section 7.1.1) or a reserved function value within a shared ASN (Section 7.1.2).¶

A deployment MUST use exactly one of the encodings below consistently within a given fabric, so that every receiver interprets origin-leaf Large Communities the same way. Any packing constants (N, and L in the function-based encoding) and any function value MUST also be consistent across the fabric and documented, so that receivers decode the identifier identically.¶

   <pod-asn> : <leaf-id> : <port-id>

   <fabric-asn> : <pod-id> : <leaf-port-id>

   leaf-port-id = (leaf << N) | port

   <fabric-asn> : <function-id> : <pod-leaf-port-id>

   pod-leaf-port-id = (pod << (L + N)) | (leaf << N) | port

7.2. Route-Attachment Metadata Profile

Although this document focuses on identifying the originating pod, leaf, and optionally port of a prefix, the same Large Community construction can represent other route-associated attachment identifiers within the same administrative domain. For example, an operator MAY encode a locally assigned switch identifier and port identifier, under a dedicated assigning ASN, as:¶

   <fabric-asn> : <switch-id> : <port-id>

or, where pod scoping is required:¶

   <fabric-asn> : <pod-id> : <switch-port-id>

or, under function-based allocation:¶

   <fabric-asn> : <function-id> : <switch-port-id>

where switch-port-id is a deployment-defined packed value. The namespace rules of Section 7.1 apply: an ASN dedicated to origin-leaf identification MUST NOT also carry attachment metadata, and under function-based allocation the attachment profile MUST use a function value distinct from the origin-leaf one. This profile is useful when the receiver needs to associate a route with the fabric attachment point used for forwarding, admission control, traffic placement, or congestion-avoidance policy.¶

Such identifiers are locally significant unless otherwise specified by the operator. The mapping from switch-id to a device address, router ID, or inventory object is a fabric-management concern and is out of scope for this document.¶

For locally significant route-attachment metadata consumed within a single administrative domain, the same information can be represented using existing BGP Large Communities without defining a new BGP path attribute or community type.¶

7.3. Propagation Model

The operational model is as follows:¶

1. Origination: The originating leaf attaches the Large Community carrying its origin-leaf identifier, in the encoding chosen for the fabric (Section 7.1), to each prefix it originates.¶

2. Transit: Spines and super-spines advertise the prefix unchanged, preserving the Large Community. Intermediate speakers MUST NOT strip or overwrite the Large Community; where policy adds communities at intermediate nodes, additive semantics MUST be used so the origin community is preserved.¶

3. Reception: Each receiving leaf matches the Large Community in inbound policy and extracts the origin-leaf identity into local metadata for use in policy and, where applicable, for programming the forwarding plane.¶

Advertisement of Large Communities is not implied by advertisement of Standard Communities; operators MUST explicitly enable Large Community advertisement on every eBGP session in the propagation path. This applies per Address Family, including the IPv6 unicast AF.¶

The origin-leaf identifier is meaningful only within the fabric in which it is assigned. At DC boundaries, such as data-center interconnect (DCI) points, it is normally removed by export policy (R13; see Section 12), and inter-DC advertisements commonly use aggregate routes, which do not identify a single originating leaf. A BGP speaker that aggregates routes within the fabric SHOULD NOT copy origin-leaf Large Communities from the contributing routes onto the aggregate; otherwise the aggregate carries multiple origin-leaf communities (see below).¶

Receiving leaves need well-defined handling for origin-leaf Large Communities that are unexpected, duplicated, or malformed. Deployments using the route-attachment metadata profile (Section 7.2) SHOULD apply analogous validation rules for assigning authority, duplicate matching communities, and out-of-range attachment identifiers.¶

• Unexpected assigning authority: A receiver SHOULD ignore, for the purpose of origin-leaf identification, any Large Community whose Global Administrator field does not match a configured assigning ASN (a fabric-wide ASN, or one of the pod ASNs in the per-pod-ASN encoding) or, in the function-based encoding, whose first Local Data field does not match the configured function value. Such communities are treated as ordinary Large Communities and are not mapped to origin-leaf metadata.¶

• Multiple matching communities: A route MAY carry more than one origin-leaf Large Community (for example, following an unexpected re-advertisement, an aggregation that inherits communities, a misconfiguration, or a malicious injection). The RECOMMENDED default is to treat the origin identity as ambiguous, map no origin-leaf metadata, and log the condition, so that a wrong identity is never silently programmed into the forwarding plane. A deployment MAY instead select a single community by a documented, repeatable rule (for example, the numerically lowest value); if it does, that rule MUST be deterministic and the condition SHOULD be logged.¶

• Malformed or out-of-range values: If the pod, leaf, or port value decoded from a matching community falls outside the ranges defined for the deployment (including any local metadata packing described in Section 7.4), the receiver MUST NOT map it to forwarding-plane metadata. The route SHOULD still be installed and forwarded normally, without origin-leaf metadata, and the condition SHOULD be logged.¶

7.4. Mapping to Local Metadata

At the receiving leaf, the pod, leaf, and port values carried in the Large Community can be mapped to a single fixed-width local metadata value for compact storage and efficient forwarding-plane use. This local packing is distinct from the on-wire "leaf-port-id = (leaf << N) | port" packing of the fabric-wide encoding (see Section 7.1.1): it is receiver-local, is not carried in BGP, and combines all three values. The example below uses the fabric-wide encoding, whose pod-id is a small integer. One convenient mapping packs the three values into a 32-bit value using disjoint bit ranges, for example a 10-bit pod field, a 12-bit leaf field, and a 10-bit port field:¶

   value = (asn-pod << 22) | (leaf << 10) | port

   Bit layout (32-bit value):
     [31:22] = Pod  (10 bits; asn-pod index)
     [21:10] = Leaf (12 bits)
     [9:0]   = Port (10 bits)

The exact width and layout of such a packed value is a local implementation choice and is not carried on the wire; only the Large Community itself is propagated between BGP speakers. Operators SHOULD document the chosen layout so that it can be interpreted consistently across the fabric and across software versions.¶

In the function-based encoding (Section 7.1.2), the on-wire pod-leaf-port-id already has this form; when the local layout uses the same L and N, it can be used directly as the local value without repacking.¶

The "asn-pod" field above is a compact pod index. In the fabric-wide and function-based encodings it is the small-integer pod identifier directly. In the per-pod-ASN encoding the pod is represented by the pod ASN, which does not fit in a small pod field; deployments using that encoding first translate the pod ASN to a compact local pod index (for example via a configured pod-ASN to pod-index table) before packing, or choose a local layout wide enough to hold the ASN.¶