Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition
draft-many-bess-rfc9252-dual-sid-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Siva Sivabalan , Param Preet Singh Dhillon , Himanshu Shah , Keyur Patel , Jeremy Whittaker | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-bess-rfc9252-dual-sid-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
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,
<https://www.rfc-editor.org/rfc/rfc3032>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4.", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/rfc/rfc5492>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc9252>.
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, <https://www.rfc-editor.org/rfc/rfc4271>.
[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,
<https://www.rfc-editor.org/rfc/rfc4456>.
[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,
<https://www.rfc-editor.org/rfc/rfc8986>.
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]