BGP Enabled Services S. Sivabalan, Ed. Internet-Draft P. Dhillon Intended status: Standards Track H. Shah Expires: 7 January 2027 Ciena Corporation K. Patel Arrcus, Inc. J. Whittaker Verizon 6 July 2026 Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition draft-many-bess-rfc9252-dual-sid-00 Abstract RFC 9252 defines BGP signaling procedures for SRv6 services, including the use of an MPLS Label field and transposition semantics. However, when transposition is not used (i.e., TL = 0), RFC 9252 does not explicitly define the interpretation of the MPLS Label field, leading to ambiguity in control-plane signaling. This document specifies a minimal, backward-compatible extension to RFC 9252 that enables a single route to unambiguously advertise both a valid MPLS Service Label and an SRv6 Service SID. The extension relies on existing MPLS label semantics, without introducing new TLVs, attributes, or changes to the base encoding format. 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 7 January 2027. Sivabalan, et al. Expires 7 January 2027 [Page 1] Internet-Draft Dual MPLS/SRv6 July 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 4.1. BGP Capability . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Route Reflector (RR) Behavior . . . . . . . . . . . . 8 4.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Extended Semantics . . . . . . . . . . . . . . . . . 9 4.2.2. Next-Hop Considerations . . . . . . . . . . . . . . . 10 4.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Ingress PE Behavior . . . . . . . . . . . . . . . . . 10 4.3.2. Egress PE Behavior . . . . . . . . . . . . . . . . . 10 4.3.3. Sample Advertisement . . . . . . . . . . . . . . . . 11 4.4. Backward Compatibility . . . . . . . . . . . . . . . . . 11 4.5. Design Considerations . . . . . . . . . . . . . . . . . . 11 5. Comparison with Alternatives . . . . . . . . . . . . . . . . 12 5.1. Analysis of Alternative Approaches . . . . . . . . . . . 12 5.2. Advantages of the Proposed Solution . . . . . . . . . . . 13 5.3. Summary of Alternatives . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Sivabalan, et al. Expires 7 January 2027 [Page 2] Internet-Draft Dual MPLS/SRv6 July 2026 1. Introduction Segment Routing over IPv6 (SRv6) and MPLS-based services are frequently required to coexist during network transitions, hybrid deployments, and in multi-domain environments. Many service providers deploy SRv6 incrementally while maintaining existing MPLS- based infrastructures, resulting in networks where both data-planes must be supported simultaneously. RFC 9252 specifies mechanisms for advertising SRv6-based services using BGP, including procedures for encoding and distributing SRv6 Service SIDs. As part of this encoding, the following fields are defined: * MPLS Label. * Transposition Offset (TO). * Transposition Length (TL). The Transposition mechanism defined in RFC 9252 enables the dynamic construction of SRv6 Segment Identifiers (SIDs) by modifying specific bit positions within a base SID. This mechanism is active when the Transposition Length (TL) is greater than zero and allows flexible encoding of service information. While RFC 9252 defines explicit and normative behavior when transposition is active (i.e., TL > 0), it does not explicitly specify the interpretation of the MPLS Label field when TL = 0. In this case, transposition is disabled, and RFC 9252 does not explicitly specify how the MPLS Label field is to be interpreted. In RFC 9252, the following behavior applies: TL > 0 Transposition is active. TL = 0 Transposition is inactive. However, when TL = 0, RFC 9252 does not explicitly specify whether the MPLS Label field is intended to carry a valid service label or whether its value is to be ignored. In addition, the Transposition Offset (TO) field has no defined semantics when transposition is inactive, and therefore its interpretation is undefined. Sivabalan, et al. Expires 7 January 2027 [Page 3] Internet-Draft Dual MPLS/SRv6 July 2026 The MPLS Label field, as defined in [RFC3032], may include special- purpose label values such as the Implicit NULL label. These labels have well-defined forwarding semantics in MPLS networks. However, when TL = 0, [RFC9252] does not define how such values are to be interpreted in the context of service advertisement. In operational deployments following [RFC9252], when the SRv6 Service SID is fully encoded in the SRv6 Service TLV without the use of transposition, the MPLS Label field is typically set to the Implicit NULL label to indicate that MPLS forwarding is not intended. The absence of explicit guidance for interpreting the MPLS Label field when TL = 0 may result in different implementation choices and interoperability challenges. In particular, it prevents deterministic interpretation of routes that could otherwise be used to advertise both MPLS and SRv6 service information. This limitation becomes critical in the following deployment scenarios: * Incremental MPLS-to-SRv6 migration, where both data-planes must coexist during transition. * Mixed data-plane environments, where different domains or nodes support different forwarding paradigms. * Interworking scenarios requiring seamless service continuity across MPLS and SRv6 segments. * Control-plane scaling optimization, where operators prefer to advertise a single route instead of maintaining multiple parallel route advertisements. In the absence of a defined mechanism, operators are forced to use alternative approaches such as multiple route advertisements, additional attributes, or out-of-band signaling. These approaches increase control-plane overhead, complicate interoperability, and introduce additional implementation complexity. This document introduces a minimal and backward-compatible extension to RFC 9252 to resolve this ambiguity. The proposed solution: * Defines explicit semantics for interpreting the MPLS Label field when TL = 0. * Enables deterministic and unambiguous encoding of dual data-plane reachability (MPLS and SRv6) within a single BGP route. Sivabalan, et al. Expires 7 January 2027 [Page 4] Internet-Draft Dual MPLS/SRv6 July 2026 * Preserves the existing encoding structures defined in RFC 9252. * Avoids the introduction of new TLVs, attributes, or SAFIs. By leveraging existing MPLS label semantics under well-scoped conditions, the proposed approach ensures seamless interoperability with legacy implementations while enabling more efficient control- plane behavior for modern deployments. 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. 3. Terminology The following terms are used in this document. Where applicable, terminology is consistent with [RFC9252] and related Segment Routing specifications. SRv6 SID: A Segment Identifier in the SRv6 data-plane, encoded as an IPv6 address, that represents a specific instruction or function to be executed at a node. SIDs are used to steer packets through a network and to invoke endpoint behaviors defined in [RFC8986]. SRv6 Service SID: An SRv6 SID associated with a service function, such as a Layer 3 VPN (L3VPN) or Ethernet VPN (EVPN) endpoint. Service SIDs are typically bound to service-specific endpoint behaviors (e.g., End.DT or End.DX) and identify the context in which incoming packets are processed. MPLS Service Label: An MPLS label that identifies a specific service instance, such as a VPN or EVPN service, and is used by an egress Provider Edge (PE) router to determine forwarding context. The MPLS Service Label is carried in the MPLS label stack and is defined in [RFC3032]. Implicit NULL Label: A special-purpose MPLS label with a reserved value defined in [RFC3032]. This label indicates penultimate hop popping behavior and SHALL NOT be considered a valid MPLS Service Label. Non-reserved MPLS Label: An MPLS label value that is not allocated Sivabalan, et al. Expires 7 January 2027 [Page 5] Internet-Draft Dual MPLS/SRv6 July 2026 as a special-purpose label as defined in [RFC3032]. In this document, such labels are considered valid MPLS Service Labels for service identification and forwarding. Transposition: A mechanism defined in [RFC9252] that modifies specific bit positions within an SRv6 SID using the Transposition Offset (TO) and Transposition Length (TL) fields. This allows dynamic construction of SIDs based on advertised information. Transposition Length (TL): A field defined in [RFC9252] that specifies the number of bits to be transposed into an SRv6 SID. When TL is greater than zero, transposition is active. When TL is equal to zero, transposition is inactive. Transposition Offset (TO): A field defined in [RFC9252] that specifies the bit position within an SRv6 SID where transposition is applied. When TL is equal to zero, the semantics of the TO field are undefined in [RFC9252] and are not used by this document. Dual Data-Plane Advertisement: The capability to advertise both MPLS-based and SRv6-based service information within a single BGP route, enabling flexible service selection and efficient control- plane operation. Ingress PE: A Provider Edge (PE) router that receives customer traffic and imposes service encapsulation, such as an MPLS label stack or an SRv6 SID list, based on control-plane information. Egress PE: A Provider Edge (PE) router that terminates service encapsulation, interprets MPLS labels or SRv6 SIDs, and forwards packets toward the appropriate service endpoint. Capability Negotiation: The process by which BGP peers advertise and determine support for specific protocol extensions using BGP Capability advertisements, as defined in [RFC5492]. 4. Proposed Solution This document specifies a minimal extension to the encoding defined in [RFC9252] in order to resolve ambiguity when the Transposition Length (TL) field is set to zero. The extension does not modify the base encoding format, nor does it introduce new BGP attributes, TLVs, or SAFIs. Instead, it defines explicit semantics for interpreting the MPLS Label field when transposition is not in use. Sivabalan, et al. Expires 7 January 2027 [Page 6] Internet-Draft Dual MPLS/SRv6 July 2026 In particular, when TL = 0 and the Dual Service Encoding Capability has been successfully negotiated, the interpretation of the MPLS Label field is determined by its value. This enables deterministic and unambiguous advertisement of MPLS and SRv6 service information within a single BGP route. The use of these semantics is controlled by a new BGP Capability, as described below. The semantics defined in this document apply ONLY when all of the following conditions are satisfied: (1) The Transposition Length (TL) is equal to zero, and (2) The Dual Service Encoding Capability has been successfully negotiated. In all other cases, the MPLS Label field MUST be interpreted strictly according to [RFC9252]. The Implicit NULL label, as defined in [RFC3032], is a special- purpose MPLS label and SHALL NOT be considered a valid MPLS Service Label. When the MPLS Label field is set to the Implicit NULL value, the route SHALL be interpreted as carrying only a valid SRv6 Service SID. When the MPLS Label field contains a non-reserved MPLS label (i.e., not defined as a special-purpose label in [RFC3032]), the route SHALL be interpreted as carrying both a valid MPLS Service Label and a valid SRv6 Service SID. In this case, both data-planes are considered usable for forwarding. When the MPLS Label field contains any reserved label as defined in [RFC3032], including but not limited to the Implicit NULL label, the label MUST NOT be interpreted as a valid MPLS Service Label. The route SHALL be interpreted as carrying only the SRv6 Service SID. When TL > 0, the semantics defined in [RFC9252] apply without modification. The proposed approach has the following properties: * Preserves the encoding structure defined in [RFC9252], ensuring compatibility with existing implementations. * Introduces no additional control-plane overhead, since no new attributes or route advertisements are required. * Enables deterministic interpretation of dual data-plane reachability using existing MPLS label semantics. Sivabalan, et al. Expires 7 January 2027 [Page 7] Internet-Draft Dual MPLS/SRv6 July 2026 * Avoids reinterpretation of existing encoding fields, thereby minimizing changes to the base specification. * Maintains backward compatibility with legacy implementations that do not support this extension. 4.1. BGP Capability This document defines a new BGP Capability, referred to as the "Dual Service Encoding Capability", which is used to signal support for the extended semantics defined in this document. Capability negotiation is performed as specified in [RFC5492]. A BGP speaker that supports this specification MUST advertise the new capability to its peers. Both peers advertise the capability: The semantics defined in this document MAY be applied when TL = 0. Capability not advertised by one or both peers: The receiver MUST interpret the route according to [RFC9252]. The Dual Service Encoding Capability further indicates that a BGP speaker: - Supports interpretation of MPLS Label semantics when TL = 0 as defined in this document. - Supports installation of forwarding state for both MPLS and SRv6 service identifiers, subject to local policy and capabilities. A BGP speaker MAY support only a subset of forwarding data-planes. In such cases, it MUST select a supported data-plane and ignore unsupported ones without treating the route as invalid. 4.1.1. Route Reflector (RR) Behavior A Route Reflector (RR) that supports the Dual Service Encoding Capability SHOULD advertise this capability as part of BGP Capability negotiation, as specified in [RFC5492]. If the RR does not support this capability, it MUST continue to operate according to standard BGP route reflection procedures. The RR MUST treat the attributes defined in [RFC9252] and this specification as opaque and MUST NOT modify the MPLS Label, SRv6 Service SID, or associated encoding fields except as required for compatibility with peers that do not support the Dual Service Encoding Capability. Sivabalan, et al. Expires 7 January 2027 [Page 8] Internet-Draft Dual MPLS/SRv6 July 2026 +------------------------+ | +----+ | | | RR | | | +/--\+ | | / \ | | +----+ +----+ | | |PE-1| |PE-2| | | +----+ +----+ | | Egress Ingress | +------------------------+ Figure 1: Route Reflector Topology Example The following rules apply when reflecting routes between clients: Both clients support the Dual Service Encoding Capability: The RR MUST reflect the route without modification. In particular, it MUST preserve the MPLS Label and SRv6 Service SID exactly as received. Egress PE supports the capability, ingress PE does not: The RR MUST ensure compatibility with the ingress PE. It SHALL reflect the route in a form compliant with [RFC9252], which results in SRv6-only semantics. In practice, this means the MPLS Label field SHOULD be set to the Implicit NULL label. Ingress PE supports the capability, egress PE does not: The route received by the RR is compliant with [RFC9252]. The RR MUST reflect the route without modifying the MPLS Label field or SRv6 Service SID. In all cases, the RR MUST NOT introduce ambiguity in the encoding and MUST preserve correct forwarding semantics. 4.2. Encoding The encoding format of the SRv6 Service SID and associated fields remains unchanged from [RFC9252]. 4.2.1. Extended Semantics This document defines additional semantics that apply when TL = 0. TL = 0 and MPLS Label = Implicit NULL: The MPLS Label field SHALL NOT be considered a valid MPLS Service Label, and the route SHALL be interpreted as carrying only a valid SRv6 Service SID. TL = 0 and MPLS Label is a non-reserved value: The MPLS Label field SHALL be considered a valid MPLS Service Label. Both MPLS and SRv6 service identifiers are valid for forwarding. Sivabalan, et al. Expires 7 January 2027 [Page 9] Internet-Draft Dual MPLS/SRv6 July 2026 If the MPLS Label field contains an invalid or unrecognized value, the receiving node MUST treat the MPLS label as unusable and fall back to SRv6 forwarding. TL > 0: The semantics defined in [RFC9252] apply. 4.2.2. Next-Hop Considerations When a route carries both SR-MPLS and SRv6 service information, a common Next Hop representation is desirable. For SR-MPLS services using an IPv6 control plane and for SRv6 services, the BGP Next Hop can be encoded as an IPv6 address. For SR-MPLS services using an IPv4 control plane, when advertised together with SRv6 service information, the Next Hop can be represented as an IPv4-mapped IPv6 address. This provides a uniform IPv6-based Next Hop encoding across dual SR-MPLS and SRv6 advertisements. 4.3. Operation 4.3.1. Ingress PE Behavior When TL > 0, processing MUST follow [RFC9252]. When TL = 0, the ingress PE MUST determine forwarding behavior based on the MPLS Label value. When MPLS Label equals Implicit NULL, SRv6 forwarding MUST be used. When MPLS Label is a non-reserved value, both MPLS and SRv6 forwarding MAY be used. When both MPLS and SRv6 forwarding are available, the ingress PE MUST select the forwarding data-plane based on local policy. Such policy MAY consider next-hop reachability, data-plane capability, and administrative preference. In the absence of explicit policy, the selection of MPLS or SRv6 forwarding is implementation-specific. 4.3.2. Egress PE Behavior An egress PE MAY advertise SRv6-only reachability by setting the MPLS Label field to the Implicit NULL value when TL = 0. An egress PE MAY advertise dual data-plane reachability by assigning a valid MPLS Service Label and including an SRv6 Service SID when TL = 0. Sivabalan, et al. Expires 7 January 2027 [Page 10] Internet-Draft Dual MPLS/SRv6 July 2026 4.3.3. Sample Advertisement Consider a route advertised with the following values: * SRv6 Service SID = 2001:db8:100::1. * TL = 0. * MPLS Label = 20000. Assuming the Dual Service Encoding Capability has been successfully negotiated, the route is interpreted as carrying both a valid MPLS Service Label and a valid SRv6 Service SID. An ingress PE may therefore forward traffic using either: * MPLS forwarding with service label 20000; or * SRv6 forwarding using Service SID 2001:db8:100::1. The forwarding data-plane selection is determined by local policy. 4.4. Backward Compatibility This specification is backward compatible with existing implementations of [RFC9252]. Legacy implementations rely solely on the SRv6 Service SID when TL = 0. A BGP speaker that does not support this specification will interpret such routes as SRv6-only and will not use MPLS forwarding. This ensures safe fallback without forwarding inconsistencies. 4.5. Design Considerations This document intentionally avoids introducing new TLVs, attributes, or SAFIs. Instead, it reuses existing encoding and MPLS label semantics to achieve compact and efficient dual data-plane signaling. This approach minimizes control-plane overhead while maintaining compatibility with existing deployments. Future extensions MAY define additional signaling for data-plane preference. Sivabalan, et al. Expires 7 January 2027 [Page 11] Internet-Draft Dual MPLS/SRv6 July 2026 5. Comparison with Alternatives Several alternative approaches can be considered to achieve the simultaneous advertisement of MPLS and SRv6 service identifiers. These approaches differ in terms of control-plane complexity, backward compatibility, and operational overhead. The approach defined in this document focuses on reusing existing encoding fields while introducing minimal additional semantics. This section compares the proposed solution with other possible design alternatives. 5.1. Analysis of Alternative Approaches One possible approach is to define a new TLV within the existing SRv6 Service encoding. This would allow explicit signaling of MPLS and SRv6 service identifiers without reusing existing fields. However, this approach introduces additional encoding structures, requiring updates to protocol parsers and increasing implementation complexity. It also increases the size of BGP updates and may impact processing performance. Another alternative is to define a new optional BGP path attribute to carry MPLS service label information independently of the SRv6 encoding. While this provides clear separation of semantics, it increases control-plane complexity and requires changes to BGP attribute handling. Additionally, such an approach may introduce ordering or dependency considerations between attributes, which complicates interoperability. A third alternative is to advertise separate BGP routes for MPLS and SRv6 data-planes. In this approach, one route would carry MPLS label information while another carries SRv6 SID information. While this maintains protocol simplicity, it results in duplication of routing information and increased control-plane state. This approach also introduces challenges in ensuring consistency and synchronization between multiple route advertisements. Some implementations may consider using out-of-band mechanisms or local configuration to correlate MPLS labels and SRv6 SIDs. However, such approaches lack standardization, reduce interoperability, and introduce operational complexity. Sivabalan, et al. Expires 7 January 2027 [Page 12] Internet-Draft Dual MPLS/SRv6 July 2026 5.2. Advantages of the Proposed Solution The solution defined in this document provides a balanced trade-off between functionality, simplicity, and compatibility. By reusing the existing encoding format defined in [RFC9252] and leveraging MPLS label semantics as specified in [RFC3032], the approach avoids modifications to the base encoding. * No new encoding structures: The solution does not introduce new TLVs, attributes, or SAFIs, thereby minimizing implementation impact. * Deterministic interpretation: Explicit semantics for TL = 0 based on MPLS label values eliminate ambiguity and ensure consistent behavior across implementations. * Control-plane efficiency: A single BGP route can advertise both MPLS and SRv6 service information, reducing route scale and update overhead. * Backward compatibility: Legacy implementations continue to operate according to [RFC9252], relying on SRv6 Service SID when TL = 0, without introducing protocol inconsistencies. * Incremental deployability: The solution supports gradual migration from MPLS to SRv6 without requiring coordinated upgrades across the network. 5.3. Summary of Alternatives The following table summarizes the key characteristics and drawbacks of the alternative approaches compared to the proposed solution. Sivabalan, et al. Expires 7 January 2027 [Page 13] Internet-Draft Dual MPLS/SRv6 July 2026 +---------------------+----------------------------------------------+ | Approach | Drawback | +---------------------+----------------------------------------------+ | New TLV | Increased encoding complexity and protocol | | | parsing overhead | +---------------------+----------------------------------------------+ | New Attribute | Additional control-plane state and | | | implementation complexity | +---------------------+----------------------------------------------+ | Multiple Routes | Increased control-plane scale and need for | | | route synchronization | +---------------------+----------------------------------------------+ | Proposed Solution | Reuses existing encoding and MPLS label | | | semantics with minimal impact and preserves | | | backward compatibility | +---------------------+----------------------------------------------+ Figure 2: Comparison of Alternative Approaches 6. Security Considerations This document does not introduce new trust relationships beyond those already present in BGP, MPLS, and SRv6 deployments. Existing security mechanisms applicable to BGP, including transport security, peer authentication, routing policy controls, and operational protections, remain applicable. 7. IANA Considerations This document requests allocation of a new BGP Capability Code from the "BGP Capability Codes" registry. Name: Dual Service Encoding Capability Capability Code: To be assigned by IANA Reference: This document 8. References 8.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, . Sivabalan, et al. Expires 7 January 2027 [Page 14] Internet-Draft Dual MPLS/SRv6 July 2026 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding.", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4.", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9252] Dawra, G., Talaulikar, K., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . 8.2. Informative References [RFC4271] Rekhter, Y., Li, T., and S. Hares, "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, . [RFC8986] Filsfils, C., Camarillo, D., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Acknowledgments TBD Contributors TBD. Authors' Addresses Siva Sivabalan (editor) Ciena Corporation Sivabalan, et al. Expires 7 January 2027 [Page 15] Internet-Draft Dual MPLS/SRv6 July 2026 Email: ssivabal@ciena.com Param Preet Singh Dhillon Ciena Corporation Email: pdhillon@ciena.com Himanshu Shah Ciena Corporation Email: hshah@ciena.com Keyur Patel Arrcus, Inc. Email: keyur@arrcus.com Jeremy Whittaker Verizon Email: jeremy.whittaker@verizon.com Sivabalan, et al. Expires 7 January 2027 [Page 16]