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

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

pbrisset@cisco.com

Cisco Systems

ketant@cisco.com

Cisco Systems

kriswamy@cisco.com

Routing Inter-Domain Routing BGP Large Community data center eBGP underlay origin identification spine-leaf Clos Data-center fabrics that run hop-by-hop eBGP routing frequently need to identify the originating node (leaf) of a prefix as it is propagated through the fabric. The BGP AS_PATH attribute provides loop prevention and identifies the originating Autonomous System (AS), but under common AS numbering models an AS does not map to a single leaf. While several BGP community mechanisms could carry such an identifier, there is no documented practice describing the mechanism and encoding choices for underlay origin-leaf tagging. This document analyzes the problem, states the requirements, and surveys candidate BGP mechanisms for carrying an origin-leaf identifier. It recommends encoding the identifier in a BGP Large Community (RFC 8092), describes how the identifier is allocated within the Large Community namespace, and describes how it is originated, propagated unchanged across the fabric, and consumed at receiving leaves. It also describes an optional profile for locally significant route-attachment metadata. This document is Informational and defines no new protocol elements.

Introduction Modern data-center (DC) networks commonly use eBGP as the routing protocol for the IP underlay, carrying plain IPv4 and IPv6 unicast prefixes across a spine-leaf (Clos) or super-spine/spine/leaf fabric . Each leaf advertises its locally originated prefixes upward toward the spines, which propagate them to all other leaves. A number of operational functions - such as origin-leaf-aware forwarding and routing policy, traffic isolation, and operational visibility - benefit from knowing which leaf originated a given prefix. However, eBGP does not natively provide a structured, reliable way to convey the originating leaf's identity to receiving leaves. This document describes the problem, the use cases, and the requirements for origin-leaf identification in a plain unicast eBGP underlay. It then surveys candidate BGP mechanisms and recommends a concrete, interoperable practice based on BGP Large Communities . Two namespace allocation models and their corresponding encodings are described, of which a deployment uses exactly one encoding consistently (see ). The document is Informational: it documents an operational practice built entirely from existing, standardized BGP capabilities and does not define any new protocol element or IANA registration.

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 ). 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; describes an optional profile for locally significant route-attachment metadata using the same Large Community construction.

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

Terminology

Fabric:: A DC network built as a folded Clos topology of leaves and spines (and, optionally, super-spines).
Leaf:: A top-of-rack (ToR) or equivalent BGP speaker that originates prefixes into the fabric and receives prefixes from other leaves.
Spine:: An aggregation-tier BGP speaker that interconnects leaves within a pod.
Super-spine:: A BGP speaker that interconnects pods in a three-tier fabric.
Pod:: A group of leaves and spines forming a repeatable unit of the fabric.
Originating leaf:: The leaf that first advertises a given prefix into the fabric. "Origin" refers to the control-plane origin of the route; in the forwarding plane, the originating leaf is the egress (destination) leaf for traffic sent toward the prefix.
Receiving leaf:: Any leaf that learns a prefix originated by another leaf.
Origin-leaf identifier:: A structured value that unambiguously identifies the originating leaf and pod (and, optionally, port) of a prefix.
Assigning ASN:: The ASN carried in the Global Administrator field of a Large Community, acting as the authority that defines the meaning of its Local Data fields .

Problem Statement Each leaf advertises its locally originated prefixes upward toward the spines, which propagate them to all other leaves. A receiving leaf that wishes to apply origin-based policy needs to know which leaf originated each prefix. The following subsections examine why eBGP does not reliably provide this information today.

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: Leaf Identity Recoverable from AS_PATH by AS-Numbering Model

AS assignment model	Leaf identity in AS_PATH	Notes
Unique private ASN per leaf	Directly readable	e.g. Leaf-1 = AS 65101, Leaf-2 = AS 65102
Unique ASN per tier (all leaves share one ASN)	Lost - all leaves appear identical	Common in large fabrics to simplify policy
Shared ASN pool (ASNs reused across pods)	Ambiguous	Pod A Leaf-1 and Pod B Leaf-1 may share the same ASN

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.

Lack of an Established Practice BGP offers several community mechanisms - Standard Communities , Extended Communities , and Large Communities - 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.

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.

Use Cases

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.

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).

Requirements AS_PATH retains its loop-prevention and origin-AS roles (see ); the requirements below concern leaf-level origin identification, which AS_PATH does not provide in general. The following requirements guide the selection of a mechanism. Requirements for an Origin-Leaf Identification Mechanism

ID	Requirement
R1	The identifier MUST be unique per originating leaf across the entire fabric.
R2	The identifier MUST be preserved across all eBGP hops (spine, super-spine) without explicit strip and re-add.
R3	The mechanism itself MUST NOT alter standard eBGP behavior (loop prevention, best-path selection, ECMP), independent of any explicit operator policy applied to the identifier.
R4	The mechanism MUST work for both IPv4 unicast and IPv6 unicast Address Families (AFs).
R5	The mechanism MUST be expressible using widely available BGP policy constructs.
R6	The identifier encoding SHOULD be structured enough to carry pod, leaf, and (optionally) port granularity.
R7	At the receiving leaf, the identifier MUST be matchable by inbound BGP policy (for example, by community or large-community matching).
R8	The identifier SHOULD be mappable to local, implementation-specific metadata (for example, a route tag) for use by policy and the forwarding plane. This is a deployment and implementation consideration rather than a BGP protocol property.
R9	The mechanism SHOULD coexist with a future VXLAN/EVPN overlay deployment without conflict or migration.
R10	The mechanism SHOULD be extensible to carry other route-associated attachment metadata, such as a locally assigned switch or interface identifier, without defining a new BGP path attribute or community type.
R11	The identifier SHOULD be independent of the fabric's ASN assignment and remain stable when ASNs are renumbered.
R12	The identifier MUST NOT collide with other uses of the same community namespace.
R13	The identifier MUST be removable by routing policy (for example, an export policy at the fabric boundary) so that it is not advertised beyond the fabric.

Candidate Mechanisms This section surveys the mechanisms that could carry an origin-leaf identifier and evaluates each against the requirements in . Identifying the originator of a route is not new in BGP, but the existing mechanisms are tied to contexts that a plain unicast eBGP underlay does not use, and are therefore not considered further. The ORIGINATOR_ID attribute is set by route reflectors and is not carried over eBGP. Route Distinguishers of Type 1 , which embed the originating router's IP address and on which EVPN and inter-AS Option B deployments rely, exist only in VPN address families. BGP-based VPLS identifies sites by a VE ID carried in the L2VPN NLRI. The VRF Route Import Extended Community carries the originating PE's address but is defined for MVPN procedures on VPN-IP routes. Each of these fails R2 or R4 for plain IPv4/IPv6 unicast.

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 () 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.

BGP Standard Community At the originating leaf, a Standard Community "AA:NN" 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.

BGP Large Community A Large Community 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 ), R11 (subject to the caveat for the per-pod-ASN encoding in ), R12 (see ), and R13 (see ). 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 ); this addresses R10. Considerations: Large Communities are widely used for other purposes (for example, informational and action communities ), 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 ). 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.

BGP Site-of-Origin (SoO) Extended Community The Site-of-Origin (SoO) Extended Community 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 ; 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 .

Generic (Opaque) Extended Community A transitive opaque Extended Community 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.

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.

Comparison Comparison of Candidate Mechanisms

Criterion	Unique ASN	Standard Community	Large Community	SoO Ext. Community	Generic Ext. Community
Value space	Finite ASN pool	16-bit per field	32-bit per field	ASN:16-bit or IP:16-bit	48-bit opaque
Structured encoding	No	Partial (2 fields)	Yes (3 fields; packing depends on encoding)	Partial (2 fields)	Opaque
Survives N eBGP hops	Yes	Yes (if not stripped)	Yes (if not stripped)	Yes (transitive)	Yes
IPv4 and IPv6 unicast	Yes	Yes	Yes	Yes	Yes
Operational clarity	Requires ASN lookup	Readable	Readable; per-field matching depends on encoding	Readable	Opaque/hex
BGP selection impact	AS_PATH length	None	None	Loop-prevention rejection (VPN/EVPN procedures)	None
Namespace isolation	None	Shared with policy	Per assigning ASN; partitioned by dedicated ASN or function value	Dedicated (VPN semantics)	Dedicated
Reference	RFC 4271	RFC 1997	RFC 8092	RFC 4364	RFC 4360
Plain unicast (no EVPN)	Works	Works	Recommended	Works, VPN semantics	Not recommended

Recommended Solution For plain IPv4/IPv6 unicast eBGP underlays this document RECOMMENDS encoding the origin-leaf identifier in a BGP Large Community . Large Communities satisfy the requirements in : each field is 32 bits (ample scale); they occupy a namespace separate from Standard Communities that can be partitioned per assigning ASN or per function value; they have no effect on BGP best-path selection; they are matchable by inbound policy; and they are preserved across eBGP hops when advertisement of Large Communities is enabled.

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 ), 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 () or a reserved function value within a shared ASN (). 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.

Dedicated Assigning ASN In this model, the assigning ASN is reserved exclusively for origin-leaf identification within the fabric: no other Large Community is defined under it. Both Local Data fields are therefore available to the identifier. Two encodings are possible, depending on the fabric's ASN model. In deployments where each pod has a distinct ASN that serves as the assigning authority for origin identifiers within that pod, and that carries no other Large Communities, the Global Administrator field MAY be set to the pod ASN, yielding: : : ]]> For this encoding to be unambiguous, the pod ASN MUST be unique within the administrative domain in which the origin identifier is interpreted. If the same ASN is reused across pods, the resulting identifiers are ambiguous and the fabric-wide encoding below MUST be used instead. Because the pod component is the pod ASN itself, this encoding satisfies R11 only as long as pod ASNs are stable. Otherwise, deployments SHOULD use a fabric-wide ASN as the Global Administrator and carry the pod identifier in a Local Data field, yielding: : : leaf-port-id = (leaf << N) | port ]]> In the per-pod-ASN encoding, pod, leaf, and port are all directly matchable (the pod via the Global Administrator ASN, the leaf and port via their own Local Data fields). In the fabric-wide encoding, the pod is directly matchable but the leaf and port share a Local Data field, so matching on them requires decoding or precomputed values.

Function-Based Allocation In this model, the assigning ASN is shared with other Large Communities. Following the "ASN:Function:Parameter" convention of , the first Local Data field carries an operator-reserved function value that identifies the community as an origin-leaf identifier, and the second Local Data field carries the pod, leaf, and port packed together: : : pod-leaf-port-id = (pod << (L + N)) | (leaf << N) | port ]]> L and N are fabric-wide constants giving the widths of the leaf and port components; the pod component occupies the remaining 32 - (L + N) bits. The function value is chosen by the operator from values not otherwise used under the assigning ASN. Other profiles, such as route-attachment metadata (), can coexist under the same ASN by reserving distinct function values. The function value is directly matchable; matching on individual pod, leaf, or port components requires decoding or precomputed values.

Field Definitions and Examples

pod-asn / fabric-asn:: The Global Administrator field, set to the assigning ASN: the ASN of the originating pod in the per-pod-ASN encoding, or a single fabric-wide ASN otherwise. This keeps the encoding within the namespace delegated to that ASN, avoiding collisions with Large Communities defined by other administrations. The chosen ASN need not be used by every BGP speaker in the fabric. If a private ASN is used, the resulting Large Community is only meaningful within the administrative domain and SHOULD be stripped at its boundaries (see ).
leaf-id / pod-id / function-id:: The first Local Data field. In the per-pod-ASN encoding it identifies the leaf that originated the prefix; in the fabric-wide encoding it identifies the originating pod; in the function-based encoding it carries the reserved function value.
port-id / leaf-port-id / pod-leaf-port-id:: The second Local Data field. In the per-pod-ASN encoding it optionally identifies the originating port and MAY be set to a fixed value (for example 0) where only pod- and leaf-level granularity is required. In the fabric-wide encoding it carries the leaf and port packed as shown above. In the function-based encoding it carries the pod, leaf, and port packed as shown above.

For example, for pod 2, leaf 7, port 1:

Per-pod-ASN encoding with pod ASN 65002: "65002:7:1".
Fabric-wide encoding with fabric ASN 65000 and N = 10: "65000:2:7169" (7169 = (7 << 10) | 1).
Function-based encoding with fabric ASN 65000, function value 100, L = 12, and N = 10: "65000:100:8395777" (8395777 = (2 << 22) | (7 << 10) | 1).

The port component is OPTIONAL. Operators MAY constrain field ranges to match their fabric dimensions. The specific values of the assigning ASN, function value, pods, leaves, and ports, and the choice of L and N, are fabric-management concerns and are out of scope for this document (see ).

Choosing an Allocation Model The two models trade identifier space against namespace flexibility: Comparison of Namespace Allocation Models

Criterion	Dedicated assigning ASN	Function-based allocation
Identifier space	64 bits (both Local Data fields)	32 bits (e.g., 10/12/10 bits: 1024 pods, 4096 leaves, 1024 ports)
Namespace requirement	An ASN (or one per pod) carrying no other Large Communities	One function value under an ASN shared with other uses
Additional profiles	Each requires another dedicated ASN	Each requires another function value
Per-component matching	Direct in per-pod-ASN encoding; partial in fabric-wide encoding	Requires decoding or precomputed values
Local metadata mapping	Requires repacking ()	On-wire value can be used directly when layouts agree

The dedicated-ASN model offers the larger identifier space and simpler matching; it is appropriate where an ASN can be reserved for this purpose. The function-based model scales better in terms of namespace usage, since it coexists with any other Large Community use under the same ASN and accommodates further profiles without consuming additional ASNs; its 32-bit identifier space is ample for current fabric sizes.

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: : : ]]> or, where pod scoping is required: : : ]]> or, under function-based allocation: : : ]]> where switch-port-id is a deployment-defined packed value. The namespace rules of 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.

Propagation Model The operational model is as follows:

Origination: The originating leaf attaches the Large Community carrying its origin-leaf identifier, in the encoding chosen for the fabric (), to each prefix it originates.
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.
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 ), 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 () 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 ), 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.

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 ): 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: 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 (), 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.

Coexistence with EVPN/VXLAN Overlays The recommended Large Community mechanism is orthogonal to overlay loop-prevention mechanisms. When a VXLAN/EVPN overlay is later added, some EVPN deployments - particularly symmetric L3VNI, multihoming, or interconnect designs - use the SoO Extended Community to prevent re-advertisement loops. The underlay Large Community continues to convey origin-leaf metadata independently. A route may therefore carry both a Large Community (underlay origin metadata) and an SoO Extended Community (overlay loop prevention) without conflict; no migration of the underlay tagging is required. This satisfies R9. Where an EVPN overlay is already deployed and operators strongly prefer a single mechanism for both underlay and overlay, SoO MAY be used for underlay origin identification instead, accepting the encoding and side-effect limitations described in . For new plain-unicast fabrics, the Large Community approach remains RECOMMENDED.

Operational Considerations

Community preservation: Any BGP speaker in the path that applies non-additive community-setting policy can inadvertently erase the origin community. All fabric devices SHOULD be audited to confirm pass-through behavior.
Heterogeneous fabrics: If the fabric includes BGP speakers from multiple implementations, Large Community support SHOULD be verified on all of them.
ECMP and best-path: Large Communities have no effect on best-path selection. Multiple equal-cost paths from different leaves each carry their own identifier; any preference among them MUST be expressed with explicit policy.
Fabric changes: When a leaf is renumbered or replaced, only the originating leaf's policy needs to change; no other device requires reconfiguration.
IPv6: The same encoding and policy apply identically to the IPv6 unicast AF; Large Community advertisement MUST be enabled per AF.

Deployment Considerations

Standardizing the pod, leaf, and port numbering scheme within a fabric is a fabric-management concern and is out of scope for this document.
Whether the community is attached at redistribution time, at prefix-origination time, or via per-neighbor outbound policy is an operational choice.
Whether to strip the community at the fabric border toward external peers is discussed in .
When the identifier represents a switch or port rather than an originating leaf (see ), operators SHOULD ensure that the identifier namespace is stable across device replacement, interface renumbering, and software upgrades. The identifier SHOULD refer to a fabric-management object rather than an implementation-specific ifIndex unless the deployment explicitly accepts ifIndex churn.

IANA Considerations This document has no IANA actions. It defines no new BGP path attribute, community, or code point; it describes an operational use of the existing BGP Large Communities attribute .

Security Considerations The mechanism described here reuses existing BGP capabilities and introduces no new protocol machinery, so it does not change the fundamental security properties of BGP . The following operational considerations apply. The origin-leaf or route-attachment Large Community reveals internal fabric topology (pod, leaf, port, or switch structure). To avoid leaking this information to parties outside the administrative domain, operators SHOULD apply export policy at the fabric border that removes the origin-leaf or route-attachment Large Community on advertisement toward external peers (R13). These communities are identified by their assigning ASN and, in the function-based encoding, their function value. Conversely, an origin-leaf or route-attachment Large Community received from outside the fabric could be used to inject a forged origin identity, which might mislead origin-leaf-aware policy. Operators SHOULD therefore remove or sanitize these Large Communities on ingress from external peers at all border devices, so that only communities set by trusted fabric devices are honored. The identifier is not cryptographically authenticated; its trustworthiness depends entirely on border filtering and on trust in the fabric's BGP speakers. Because the mechanism relies on Large Communities being preserved across eBGP hops, operators should be aware that a compromised or misconfigured intermediate speaker could alter or remove the identifier; standard BGP hardening and configuration-audit practices apply.

References Normative References Informative References

Acknowledgements The authors would like to thank Stephane Litkowski for his review and comments.