Huawei Technologies

China rainsword.wang@huawei.com

Huawei Technologies

China jie.dong@huawei.com

Cisco Systems

India ketant.ietf@gmail.com

Huawei Technologies

China hantao@huawei.com

ZTE Corporation

China chen.ran@zte.com.cn

RTG idr intent-aware routing This document describes a mechanism to advertise IPv6 prefixes in BGP that are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called "Colored Prefix Routing" (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. SRv6 services (e.g., SRv6 VPN services) with a specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored Prefixes. This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. The existing IPv6 Address Family and Color Extended Community are reused to advertise IPv6 Colored Prefixes without new BGP extensions; thus, this mechanism is easy to interoperate and can be deployed incrementally in multi-Autonomous System (AS) networks that belong to the same trusted domain.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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

• .  Introduction
• .  BGP CPR
  • .  Colored Prefix Allocation
  • .  Colored Prefix Advertisement
  • .  CPR to Intra-Domain Path Resolution
  • .  SRv6 Service Route Advertisement
  • .  SRv6 Service Steering
• .  Encapsulation and Forwarding Process
  • .  CPR over SRv6 Intra-Domain Paths
  • .  CPR over MPLS Intra-Domain Paths
• .  Operational Considerations
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction With the trend of using one common network to carry multiple types of services, each service type can have different requirements for the network. Such requirements are usually considered the "intent" of the service or customer, which is represented as an abstract notion called "color". In network scenarios where the services are delivered across multiple Autonomous Systems (ASes), there is a need to provide the services with different end-to-end paths to meet the intent. describes the problem statements and requirements for inter-domain intent-aware routing. The inter-domain path can be established using either Multi-Protocol Label Switching (MPLS) or the IP data plane. In MPLS-based networks, the usual inter-domain approach is to establish an end-to-end Label Switched Path (LSP) based on the mechanism defined in (which is usually referred to as BGP-LU (BGP Labeled Unicast)). Each domain's ingress border node needs to perform label swapping for the end-to-end LSP, and impose the label stack that is used for the LSP within its own domain. In IP-based networks, the IP reachability information can be advertised to network nodes in different domains using BGP, so that all the domain border nodes can obtain the routes to the IP prefixes of the destination nodes in other domains. With the introduction of SRv6 , BGP services are assigned with SRv6 Service SIDs , which are routable in the network according to its SRv6 locator prefix. Thus, the inter-domain path can be established simply based on the inter-domain routes to the prefix. Inter-domain LSPs based on the BGP-LU mechanism are not necessary for IPv6- and SRv6-based networks. This document describes a mechanism to advertise IPv6 prefixes that are associated with the Color Extended Community to establish end-to-end intent-aware paths for SRv6 services. The color value in the Color Extended Community indicates the intent . Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. BGP services over SRv6 (e.g., SRv6 VPN services) with specific intent could be assigned with SRv6 SIDs under the corresponding SRv6 locators, which are advertised as Colored Prefixes. This allows the SRv6 service traffic to be steered (as specified in ) into end-to-end intent-aware paths based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. In the data plane, the dedicated transport label or SID for the inter-domain path is not needed, resulting in smaller encapsulation overhead than with other options. The existing IPv6 Address Family and Color Extended Community could be reused to advertise IPv6 Colored Prefixes without new BGP extensions; thus, this mechanism is easy to interoperate and can be deployed incrementally in multi-AS networks that belong to the same trusted domain (in the sense used by ).

BGP CPR

Colored Prefix Allocation In SRv6 networks, an SRv6 locator needs to be allocated for each node. In order to distinguish N different intents, a Provider Edge (PE) node needs to be allocated with N SRv6 locators, each of which is associated a different intent that is identified by a color value. One way to achieve this is by splitting the base SRv6 locator of the node into N sub-locators, whereby these sub-locators are Colored Prefixes associated with different intents. For example, a PE node is allocated with the base SRv6 Locator 2001:db8:aaaa:1::/64. In order to provide 16 different intents, this base SRv6 Locator is split into 16 sub-locators from 2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68; each of these sub-locators is associated with a different intent, such as low-delay, high-bandwidth, etc.

Colored Prefix Advertisement After the allocation of Colored Prefixes on a PE node, routes to these Colored Prefixes need to be advertised both in the local domain and also to other domains using BGP, so that the BGP SRv6 services routes could be resolved using the corresponding CPR route. In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as defined in is used for the advertisement of the Colored Prefix routes, in which the Address Family / Subsequent Address Family (AFI/SAFI = 2/1) is used. The Color Extended Community is carried with the Colored Prefix route with the color value indicating the intent . The procedure of Colored Prefix advertisement is described using an example with the following topology:

Example Topology for CPR Route Illustration Consistent Color Domain: C1, C2, ... +--------------+ +--------------+ +-------------+ | | | | | | | [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] | --[PE1] [P1] | X | [P2] | X | [P3] [PE3]-- | [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] | | | | | | | +--------------+ +--------------+ +-------------+ AS1 AS2 AS3 Colored Prefixes of PE3: Low delay: PE3:CL1:: High bandwidth: PE3:CL2:: ...

Assume PE3 is provisioned with two different Colored Prefixes CLP-1 and CLP-2 for two different intents such as "low-delay" and "high-bandwidth" respectively. In this example, It is assumed that the color representing a specific intent is consistent throughout all the domains.

• PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry the corresponding Color Extended Community C1 or C2. PE3 also advertises a route for the base SRv6 Locator prefix PE3:BL, and there is no Color Extended Community carried with this route.
• ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the CPR routes further to ASBR23 and ASBR24 with next-hop set to itself.
• ASBR23 and ASBR24 receive the CPR routes of PE3. Since the color-to-intent mapping in AS2 is consistent with that in AS3, the Color Extended Community in the received CPR routes are kept unchanged. ASBR23 and ASBR24 advertise the CPR routes further in AS2 with the next hop set to itself.
• The behavior of ASBR21 and ASBR22 are similar to the behavior of ASBR31 and ASBR32.
• The behavior of ASBR11 and ASBR12 are similar to the behavior of ASBR23 and ASBR24.

In normal cases, the color value in the Color Extended Community associated with the CPR route is consistent through all the domains, so that the Color Extended Community in the CPR routes is kept unchanged. In some special cases, one intent may be represented as a different color value in different domains. If this is the case, then the Color Extended Community in the CPR routes needs to be updated at the border nodes of the domains based on the color-mapping policy. For example, in AS1, the intent "low latency" is represented by the color "red", while the same intent is represented by color "blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color Extended Community in the CPR routes needs to be updated from "red" to "blue" at the border nodes based on the color-mapping policy. In network scenarios where some of the intermediate autonomous systems are MPLS based, the CPR routes may still be advertised using the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based intermediate domains; at the MPLS domain border nodes, some route resolution policy could be used to make the CPR routes resolve to intra-domain intent-aware MPLS LSPs. Another possible mechanism is to use the IPv6 LU address family (AFI/SAFI=2/4) to advertise the CPR routes in the MPLS domains, the detailed procedure is described in .

CPR to Intra-Domain Path Resolution A domain border node that receives a CPR route can resolve the CPR route to an intra-domain color-aware path based on the tuple (N, C), where N is the next hop of the CPR route, and C is the Color Extended Community of the CPR route. The intra-domain color-aware path could be built with any of the following mechanisms:

• SRv6 Policy
• SR-MPLS Policy
• SRv6 Flex-Algo
• SR-MPLS Flex-Algo
• RSVP-TE

For example, if PE1 receives a CPR route to PE3:CL1:: with the color C1 and next hop ASBR11, it can resolve the CPR routes to an intra-domain SRv6 Policy based on the tuple (ASBR11, C1). The intra-domain path resolution scheme could be based on any existing tunnel resolution policy, and new tunnel resolution mechanisms could be introduced if needed.

SRv6 Service Route Advertisement For an SRv6 service that is associated with a specific intent, the SRv6 Service SID could be allocated under the corresponding Colored locator prefix. For example, on PE3 in the example topology, an SRv6 VPN service with the low-delay intent can be allocated with the SRv6 End.DT4 SID PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix for low-delay service. The SRv6 service routes are advertised using the mechanism defined in . The inter-domain VPN Option C is used, which means the next hop of the SRv6 service route is set to the originating PE and is not changed. Since the intent of the service is embedded in the SRv6 service SID, the SRv6 service route does not need to carry the Color Extended Community.

SRv6 Service Steering With the CPR routing mechanism, the ingress PE node that receives the SRv6 service routes follows the behavior of SRv6 shortest path forwarding (refer to Sections and of ). The SRv6 service SID carried in the service route is used as the destination address in the outer IPv6 header that encapsulates the service packet. If the corresponding CPR route has been received and installed, longest prefix matching of SRv6 service SIDs to the Colored Prefixes is performed. As a result of this prefix matching, the next hop found is an intra-domain color-aware path, which will be used for forwarding the SRv6 service traffic. This process repeats at the border node of each domain the packet traverses, until it reaches its destination.

Encapsulation and Forwarding Process This section describes the encapsulation and forwarding process of data packets which are matched with the corresponding CPR route. The topology of is used in each example.

CPR over SRv6 Intra-Domain Paths Following is an illustration of the packet encapsulation and forwarding process of CPR over SRv6 Policy. The abstract representation of IPv6 and the Segment Routing Header (SRH) described in is used. PE3 is provisioned with a Colored Prefix PE3:CL1:: for "low-delay". In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with SID list <P1, ASBR11>. In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented with the SID list <P2, ASBR23>. In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with the SID list <P3, PE3>. C-pkt is the customer packet PE1 received from its attaching CE. For packets that belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding process using H.Encaps.Red behavior is shown as below:

PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt) P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt)

In some autonomous systems, SRv6 Flex-Algo may be used to provide intent-aware intra-domain paths. The encapsulation is similar to the case with SRv6 Policy.

CPR over MPLS Intra-Domain Paths In network scenarios where some of the autonomous systems use the MPLS-based data plane, the CPR route can be resolved over a color-aware intra-domain MPLS LSP. Such an intra-domain MPLS LSP may be established using SR-MPLS Policy, SR-MPLS Flex-Algo, or RSVP-TE. The encapsulation and forwarding of SRv6 service packets (which are actually IPv6 packets) over an intra-domain MPLS LSP is based on the MPLS mechanisms as defined in , and . The behavior is similar to that of IPv6 Provider Edge Routers (6PEs) . In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented with the SID list <P1, ASBR11>. In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is represented with SID list <ASBR23>. In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented with SID list <P3, PE3>. C-pkt is the customer packet PE-1 received from its attaching CE. For packets that belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding process is shown as below:

PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)

Operational Considerations The CPR mechanism can be used in network scenarios where multiple inter-connected ASes belong to the same operator, or where there is an operational trust model between the ASes of different operators which means they belong to the same trusted domain (in the sense used by ). As described in , inter-domain intent-aware routing may be achieved with a logical tunnel created by an SR Policy that applies to multiple ASes. In addition, service traffic with specific intent can be steered to the inter-domain SR Policy based on the intent signaled by Color Extended Community. An operator may prefer a BGP routing-based solution for the reasons described in . The operator may also consider the availability of an inter-domain controller for end-to-end intent-aware path computation. This document proposes an alternate solution to signal the intent with IPv6 Colored Prefixes using BGP. When Colored Prefixes are assigned as sub-locators of the node's base SRv6 locator, the IPv6 unicast route of the base locator prefix is the prefix that covers all of the Colored locator prefixes. To make sure the Colored locator prefixes can be distributed to the ingress PE nodes along the border nodes, it is required that route aggregation be disabled for IPv6 unicast routes that carry the Color Extended Community. With the CPR mechanism, at the prefix originator, each Colored Prefix is associated with one specific intent (i.e., color). In each domain, according to the color mapping policy, the same CPR route is always updated with the same color. The case where there are multiple copies of CPR routes with the same Colored Prefix but different Color Extended Community is considered a misconfiguration. All the border nodes and the ingress PE nodes need to install the Colored locator prefixes in the RIB and FIB. For transit domains that support the CPR mechanism, the border nodes can use the tuple (N, C), where N is the next hop and C is the color, to resolve the CPR routes to intent-aware intra-domain paths. For transit domains that do not support the CPR mechanism, the border nodes would ignore the Color Extended Community and resolve the CPR routes over a best-effort intra-domain path to the next-hop N, while the CPR route will be advertised further to the downstream domains with only the next hop changed to itself. This allows the CPR routes to resolve to intent-aware intra-domain paths in any autonomous systems that support the CPR mechanism, while the CPR routes can fall back to resolve over best-effort intra-domain paths in the legacy autonomous systems. There may be multiple inter-domain links between the adjacent autonomous systems, and a border node BGP speaker may receive CPR routes from multiple peering BGP speakers in another domain via External BGP (EBGP). The local policy of a BGP speaker may take the attributes of the inter-domain links and the attributes of the received CPR routes into consideration when selecting the best path for specific Colored Prefixes to better meet the intent. The detailed local policy is outside the scope of this document. In a multi-AS environment, the policy of BGP speakers in different domains needs to be consistent. In this document, the IPv6 Unicast Address Family is used for the advertisement of IPv6 Colored Prefixes. The primary advantage of this approach is the improved interoperability with legacy networks that lack support for intent-aware paths, and the facilitation of incremental deployment of intent-aware routing mechanisms. One potential concern arises regarding the need to separate Colored Prefixes from public IPv6 unicast routes. Because the IP prefixes and SRv6 locators of network infrastructure are usually advertised as part of the IP unicast routes, and appropriate filters are configured at the boundaries of network administration, this concern is not considered to be a significant issue. allocates the prefix 5f00::/16 for SRv6 SIDs. By common agreement among participants in the trusted domain, the filters can be configured to by default drop all traffic from 5f00::/16 but permit the Colored Prefixes in use in these domains. The proposal in provides a complementary solution that is also based on the notion of color indicating the intent and where the SRv6 Locator prefix itself signifies the intent; the difference is that a separate SAFI is used. describes another mechanism for intent-aware routing, in which the SRv6 service SIDs are not directly associated with the intent (additional SRv6 transport SIDs are required to steer traffic to the inter-domain intent-aware paths), and an SRv6 operation similar to MPLS label swapping is needed on the border nodes of autonomous systems.

IANA Considerations This document has no IANA actions.

Security Considerations The mechanism described in this document provides an approach for inter-domain intent-aware routing based on existing BGP protocol mechanisms. The existing BGP IPv6 Unicast Address Family and existing Color Extended Community are reused without further BGP extensions. With this approach, the number of IPv6 Colored Prefixes advertised by PE nodes is proportionate to the number of intents it supports. This may introduce additional routes to the BGP IPv6 routing table. Because these are infrastructure routes, the number of Colored Prefixes is only a small portion of the total amount of IPv6 prefixes. Thus, the impact to the required routing table size is considered acceptable. As the CPR routes are distributed across multiple ASes that belong to a trusted domain, the mapping relationship between the intent and the IPv6 Colored Prefixes are observable to BGP nodes in those ASes. It is possible for an on-path attacker in the trusted domain to identify packets associated with a particular intent. The security considerations as described in , , and apply to this document.

References Normative References BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Informative References Cisco Systems Cisco Systems Work in Progress Juniper Networks, Inc. Juniper Networks, Inc. Work in Progress Juniper Networks Inc. Cisco Systems Independent Contributor BT Verizon This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions. Work in Progress This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK] This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK] This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs. Cisco Systems Cisco Systems Bell Canada LinkedIn Huawei Technologies Juniper Networks Work in Progress

Acknowledgements The authors would like to thank , , , , and for their reviews and valuable discussion.

Contributors The following people contributed significantly to the content of this document and should be considered co-authors:

ifocus.chen@huawei.com

xiejingrong@huawei.com

li_zhenqiang@hotmail.com

Authors' Addresses Huawei Technologies

China rainsword.wang@huawei.com

Huawei Technologies

China jie.dong@huawei.com

Cisco Systems

India ketant.ietf@gmail.com

Huawei Technologies

China hantao@huawei.com

ZTE Corporation

China chen.ran@zte.com.cn