MVPN/EVPN Tunnel Aggregation with Common Labels
updates
Extracted elements (27)
A Domain-wide Common Block (DCB) of labels, reserved on all PEs and assigned by a central entity, reduces the label count for N VPNs/BDs/ESs from O(PEs × N) to O(N). This is analogous to using identical SRGBs across all nodes in Segment Routing [RFC8402].
As an alternative to per-PMSI label allocation at segmentation points, segmentation points could perform (C-S,C-G) lookups in VRFs, allowing S-PMSIs for the same VPN/BD to share a common VPN/BD-identifying label. However, this trades a label-count scaling problem for a (C-S/*,C-G) route-count scaling problem in VRFs.
For per-AS/region PMSI routes where different ASBRs/RBRs for the same source AS/region advertise the same route, using a common label requires coordination; the simpler approach is for each ASBR/RBR to allocate from its own assigned label block, avoiding the coordination requirement.
For segmented selective tunnels, a single per-VPN/BD DCB label cannot be used at segmentation points because different flows on the same aggregate tunnel in one region may fan out to different tunnels in the next region. Per-PMSI labels allocated from PE-specific disjoint blocks within a context-specific label space are required instead.
The 'domain' for DCB purposes need not include internal P routers, because DCB labels only appear at the top of the stack when traffic arrives at PE routers. Excluding P routers means they do not need to reserve the same label block.
The ESI label scaling problem exists even without P2MP tunnel aggregation: if 1001 PEs each attach to 1000 ESs, each PE must understand up to 1,000,000 ESI labels allocated independently by other PEs from their own label spaces.
When a single DCB large enough for all VPNs/BDs/ESs is impractical, a few context-specific label spaces (identified by small DCB labels) can hold the full VPN/BD/ES label set. Ingress PEs impose the context-identifying DCB label after the VPN/BD/ES label, allowing egress PEs to determine the correct forwarding table.
With independent per-PE upstream-assigned label allocation, each egress PE must track up to PEs × VPNs/BDs labels (e.g., 1,000,000 labels for 1001 PEs each hosting 1000 VPNs). This scaling problem motivates the use of provisioned common labels so all ingress PEs assign the same label to a given VPN/BD/ES.
The three label allocation methods (DCB, common context-specific label spaces, per-PE disjoint blocks) can be used in any combination depending on deployment. The MAY in Section 4.2 means use of these procedures is optional, but when used, all PEs and segmentation points must consistently support them.
An x-PMSI/IMET route MUST NOT carry both the DCB-flag and the Context-Specific Label Space ID EC. A received route with both present MUST be treated as withdrawn.
If a PE originates two x-PMSI/IMET routes sharing the same tunnel, they MUST all carry the DCB-flag, or all carry the Context-Specific Label Space ID EC, or none carry the DCB-flag, or none carry the Context-Specific Label Space ID EC. Inconsistent mixing causes receiving PEs to treat the routes as withdrawn.
If a VPN/BD/ES/PMSI label is assigned from one of the context-specific label spaces (not the DCB), a Context-Specific Label Space ID EC MUST be attached to the route, with ID-Type 0 and ID-Value set to the DCB label that identifies that context-specific label space.
If neither the DCB-flag nor the Context-Specific Label Space ID EC is present on an x-PMSI/IMET route, the label in the PTA or ESI Label EC MUST be treated as an upstream-assigned label from the source PE's label space, and the procedures of RFC 6514 and RFC 7432 MUST be followed.
It is REQUIRED that PE Distinguisher Labels allocated by a particular node for MP2MP tunnels come from the same label space as the node's VPN-identifying labels.
The ES label and the BD label MUST be assigned from the same label space. If PE Distinguisher Labels are used [RFC7582], they MUST also be allocated from the same label space as the VPN-identifying labels.
The receiving PE MUST place an entry for the label in the PTA or ESI Label EC in the default MPLS forwarding table (if the DCB-flag is present) or in the context-specific label table (if the Context-Specific Label Space ID EC is present).
When a PE originates or re-advertises an x-PMSI/IMET route, the route MUST carry the DCB-flag if and only if the label in its PTA is assigned from the DCB.
When a PE receives an x-PMSI/IMET route with the Context-Specific Label Space ID EC, it MUST install an entry in its default MPLS forwarding table mapping the label in the EC to the corresponding context-specific label table for subsequent inner-label lookups.
When the procedures in this document are used, all PE routers and segmentation points MUST support these procedures. Ensuring uniform support is outside the scope of this document.
The DCB-flag is Bit 47 in the 'Additional PMSI Tunnel Attribute Flags' BGP Extended Community [RFC7902]. A route 'carries the DCB-flag' when its PTA Flags field has the Extension bit set AND the Additional PMSI Tunnel Attribute Flags EC has the DCB-flag bit set.
Three label allocation methods are defined: (1) central entity allocates per-VPN/BD/ES labels directly from the DCB; (2) central entity allocates from a few common context-specific label spaces identified by DCB labels; (3) per-PE disjoint blocks within context-specific label spaces for segmented S-PMSIs. Multiple methods may be combined.
When using context-specific label spaces, an ingress PE imposes labels in order: first the VPN/BD label and/or ESI label (from the context-specific space), then the DCB label identifying that context-specific label space, then the transport tunnel encapsulation.
IANA assigned Bit 47 (named 'DCB') in the 'Additional PMSI Tunnel Attribute Flags' BGP Extended Community registry [RFC7902].
IANA assigned sub-type 0x08 for 'Context-Specific Label Space ID Extended Community' in the 'Transitive Opaque Extended Community Sub-Types' registry.
IANA created the 'Context-Specific Label Space ID Type' registry within the BGP Extended Communities group, with First Come First Served registration policy. Initial assignments: Type 0 = MPLS Label (RFC 9573), Types 1-254 = Unassigned, Type 255 = Reserved.
The three label allocation methods are equivalent to using common SRGBs from the regular per-platform label space (Option 1), from a third-party label space [RFC5331] (Option 2), or from disjoint blocks in a third-party label space (Option 3). RFC 6514, 7432, 8402, and 5331 identify no security concerns related to label allocation methods, and this document introduces no new security concerns.
The Context-Specific Label Space ID Extended Community is a Transitive Opaque EC (type 0x03 or 0x43, sub-type 0x08) with a 2-octet ID-Type field and a 4-octet ID-Value field. When ID-Type is 0 (MPLS Label), the most significant 20 bits of ID-Value carry the label value.