Juniper Networks

tsaad@juniper.net

Juniper Networks

vbeeram@juniper.net

ZTE Corporation

chen.ran@zte.com.cn

ZTE Corporation

peng.shaofu@zte.com.cn

Comcast

Bin_Wen@cable.comcast.com

Ericsson

daniele.ceccarelli@ericsson.com

LSR Working Group Internet-Draft Segment Routing (SR) defines a set of topological “segments” within an IGP topology to enable steering over a specific SR path. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes extensions to the IS-IS and OSPF required to support the signaling of Resource Partition (NRP) segments that operate over SR-MPLS and SRv6 dataplanes. Multiple SR NRP segments can be associated with the same topological element to allow offering of different forwarding treatments (e.g. scheduling and drop policy) associated with each NRP.

The Segment Routing (SR) architecture defines a set of topological “segments” within an IGP topology as means to enable steering over a specific SR end-to-end path. These segments are advertised by the IGP link-state routing protocols (IS-IS and OSPF). The SR control plane can be applied to both IPv6 and MPLS data planes. The definition of a network slice for use within the IETF and the characteristics of IETF network slice are specified in . A framework for reusing IETF VPN and traffic-engineering technologies to realize IETF network slices is discussed in . introduces a Slice-Flow Aggregate as the collection of packets (from one or more IETF network slice traffic streams) that match an NRP Policy selection criteria and are offered the same forwarding treatment. The NRP Policy is used to realize an NRP by instantiating specific control and data plane resources on select topological elements in an IP/MPLS network. describes an approach to extend SR to advertise new SID types called NRP SIDs. Such NRP SIDs are used by a router to define the forwarding action for a packet (next-hop selection), as well as to enforce the specific treatment (scheduling and drop policy) associated with the NRP. This document defines the IS-IS and OSPF specific encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN-Adjacency Segment that are required to support the signaling of SR NRP SIDs operating over SR-MPLS and SRv6 dataplanes. When the NRP segments share the same topology (and Algorithm for NRP Prefix-SIDs), the different NRP SIDs of the same topological element share the same forwarding path (i.e., IGP next-hop(s)), but are associated with the specific forwarding treatment (e.g. scheduling and drop policy) of each NRP.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Segment Routing can be directly instantiated on the MPLS data plane through the use of the Segment Routing header instantiated as a stack of MPLS labels defined in .

defines the IS-IS Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV) that is applicable to SR-MPLS dataplane. The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID, and is associated with a prefix advertised by a router. A new IS-IS SR Network Resource Partition Prefix SID (NRP Prefix-SID) sub-TLV is defined to allow a router advertising a prefix to associate multiple NRP Prefix-SIDs to the same prefix. The NRP Prefix-SIDs associated with the same prefix share the same IGP path to the destination prefix within the specific mapped or customized topology/algorithm but offer the specific QoS treatment associated with the specific NRP. The NRP ID is carried in the NRP Prefix-SID sub-TLV in order to associate the Prefix-SID with the specific NRP. The NRP Prefix-SID sub-TLV has the following format:

where: Type: TBD1 (Suggested value to be assigned by IANA) Length: Variable. Depending on the size of the SID. The “Flags” and “SID/Index/Label” fields are the same as the Prefix-SID sub-TLV . Algorithm: 1 octet. Associated algorithm. Algorithm values are defined in the IGP Algorithm Type registry NRP-ID: Identifies a specific NRP within the IGP domain. This sub-TLV MAY be present in any of the following TLVs: TLV-135 (Extended IPv4 reachability) defined in . TLV-235 (Multitopology IPv4 Reachability) defined in . TLV-236 (IPv6 IP Reachability) defined in . TLV-237 (Multitopology IPv6 IP Reachability) defined in . This sub-TLV MAY appear multiple times in each TLV.

defines the IS-IS Adjacency Segment Identifier sub-TLV (Adj-SID sub-TLV). The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment Routing IGP Adjacency-SID as defined in . A new SR Network Resource Partition Adjacency SID (NRP Adj-SID) sub-TLV is defined to allow a router to allocate and advertise multiple NRP Adj-SIDs towards the same IS-IS neighbor (adjacency). The NRP Adj-SIDs allows a router to enforce the specific treatment associated with the NRP on the specific adjacency. The NRP ID is carried in the NRP Adj-SID sub-TLV to associate it to the specific NRP, and has the following format:

where: Type: TBD2 (Suggested value to be assigned by IANA) Length: Variable. Depending on the size of the SID. The “Flags”, “SID/Index/Label”, and “Weight” fields are the same as those defined for the Adj-SID sub-TLV in . NRP-ID: Identifies a specific NRP within the IGP domain. This sub-TLV MAY be present in any of the following TLVs: TLV-22 (Extended IS reachability) . TLV-222 (Multitopology IS) . TLV-23 (IS Neighbor Attribute) . TLV-223 (Multitopology IS Neighbor Attribute) . TLV-141 (inter-AS reachability information) . Multiple Adj-SID sub-TLVs MAY be associated with a single IS-IS neighbor. This sub-TLV MAY appear multiple times in each TLV.

defines ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-TLV. A new per Algorithm SR NRP Adj-SID is defined to allow a router to allocate and advertise multiple NRP Adj-SIDs towards the same adjacency. The per Algorithm NRP Adj-SID allow the router to enforce the specific forwarding treatment associated with the NRP on to packets using that NRP Adj-SID as active segment. The NRP ID is carried in the NRP per Algorithm Adj-SID sub-TLV to associate it to the specific NRP. The sub-TLV has the following format:

where: Type: TBD3. Length: 10 or 11 depending on size of the SID. NRP-ID: Identifies a specific NRP within the IGP domain. The “Flags”, “SID/Index/Label”, and “Weight” fields are the same as those defined for the Adj-SID sub-TLV in . The “Algorithm” field is as defined in for the per Algorithm Adj-SID Sub-TLV.

In LAN subnetworks, defines the SR-MPLS LAN-Adj-SID sub-TLV for a router to advertise the Adj-SID of each of its neighbors. A new SR Network Resource Partition LAN Adjacency SID (NRP LAN-Adj-SID) sub-TLV is defined to allow a router to allocate and advertise multiple NRP LAN-Adj-SIDs towards each of its neighbors on the LAN. The NRP LAN-Adj-SIDs allows a router to enforce the specific treatment associated with the specific NRP towards a neighbor. The NRP ID is carried in the NRP LAN-Adj-SID sub-TLV to associate it to the specific NRP, and it has the following format:

where: Type: TBD4 (Suggested value to be assigned by IANA) Length: Variable. Depending on the size of the SID. The “Flags” and “SID/Index/Label” fields are the same as the LAN-Adj-SID sub-TLV . NRP-ID: Identifies a specific NRP within the IGP domain. This sub-TLV MAY be present in any of the following TLVs: TLV-22 (Extended IS reachability) . TLV-222 (Multitopology IS) . TLV-23 (IS Neighbor Attribute) . TLV-223 (Multitopology IS Neighbor Attribute) . Multiple LAN-Adj-SID sub-TLVs MAY be associated with a single IS-IS neighbor. This sub-TLV MAY appear multiple times in each TLV.

ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV has the following format:

where: Type: TBD5. Length: Variable. The “Flags”, “SID/Index/Label”, “Weight”, and “Neighbor System-ID” fields are the same as those defined for the LAN-Adj-SID sub-TLV in . The “Algorithm” field is as defined in for the per Algorithm LAN-Adj-SID Sub-TLV. Editor Note: the OSPF Sub-TLV sections will be populated in further update.

Segment Routing can be directly instantiated on the IPv6 data plane through the use of the Segment Routing Header defined in . SRv6 refers to this SR instantiation on the IPv6 dataplane. The SRv6 Locator TLV was introduced in to advertise SRv6 Locators and End SIDs associated with each locator.

The SRv6 End SID sub-TLV was introduced in to advertise SRv6 Segment Identifiers (SID) with Endpoint behaviors which do not require a particular neighbor. The SRv6 End SID sub-TLV is advertised in the SRv6 Locator TLV, and inherits the topology/algorithm from the parent locator. The SRv6 End SID sub-TLV defined in carries optional sub-sub-TLVs. A new SRv6 NRP SID Sub-Sub-TLV is defined to allow a router to assign and advertise an SRv6 End SID that is associated with a specific NRP. The SRv6 SID NRP Sub-Sub-TLV allows routers to infer and enforce the specific treatment associated with the NRP on the selected next-hops along the path to the End SID destination.

where: Type: TBD6 Length: 4 octets. NRP-ID: Identifies a specific NRP within the IGP domain. ISIS SRv6 SID NRP Sub-Sub-TLV MUST NOT appear more than once in its parent Sub-TLV. If it appears more than once in its parent Sub- TLV, the parent Sub-TLV MUST be ignored by the receiver. The new SRv6 SID NRP Sub-Sub-TLV is an optional Sub-Sub-TLV of: SRv6 End SID Sub-TLV (Section 7.2 of ) SRv6 End.X SID Sub-TLV (Section 8.1 of ) SRv6 LAN End.X SID Sub-TLV (Section 8.2 of )

This document requests allocation for the following Sub-TLVs types.

Table 1 summarizes registrations made in the “Sub-TLVs for TLV 135,235,226 and 237 registry”. Sub-TLV Type Description Reference TBD1 NRP Prefix-SID Sub-TLV

Table 2 summarizes registrations made in the “Sub-TLVs for TLV 22, 23, 25, 141, 222, and 223” registry. Sub-TLV Type Description Reference TBD2 NRP Adj-SID Sub-TLV TBD3 NRP LAN-Adj-SID Sub-TLV TBD4 NRP Per Algo Adj-SID Sub-TLV TBD5 NRP Per Algo LAN-Adj-SID Sub-TLV

The below is a request to allocate a new sub-sub-TLV type from the “sub-sub-TLVs for SRv6 End SID and SRv6 End.X SID” registry: Type: TBD5 (to be assigned by IANA). Reference:

TBD.

The authors would like to thank Swamy SRK, and Prabhu Raj Villadathu Karunakaran for their review of this document, and for providing valuable feedback on it.

The following individuals contributed to this document:

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 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. Juniper Networks Juniper Networks Huawei Technologies Comcast Ericsson Ericsson ZTE Corporation ZTE Corporation Volta Networks Telefonica Ciena Verizon Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. Juniper Networks Juniper Networks ZTE Corporation ZTE Corporation Comcast Ericsson Multiple network slices can be realized on top of a single shared network. A router that requires forwarding of a packet that belongs to a slice aggregate may have to decide on the forwarding action to take based on selected next-hop(s), and the forwarding treatment (e.g., scheduling and drop policy) to enforce based on the slice aggregate per-hop behavior. Segment Routing is a technology that enables the steering of packets in a network by encoding pre- established segments within the network into the packet header. This document introduces mechanisms to enable forwarding of packets over a specific slice aggregate along a Segment Routing (SR) path. Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK] This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK] This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK] ZTE Corporation ZTE Corporation Cisco Systems Cisco Systems Segment Routing architecture supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement 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. Cisco Systems Cisco Systems Individual Orange Huawei Technologies The Segment Routing (SR) architecture allows flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. Nokia NTT Futurewei Telefonica Juniper Networks This document provides a definition of the term "IETF Network Slice" for use within the IETF and specifically as a reference for other IETF documents that describe or use aspects of network slices. The document also describes the characteristics of an IETF network slice, related terms and their meanings, and explains how IETF network slices can be used in combination with end-to-end network slices or independent of them. Ericsson Juniper Networks This memo discusses setting up special-purpose network connections using existing IETF technologies. These connections are called IETF network slices for the purposes of this memo. The memo discusses the general framework for this setup, the necessary system components and interfaces, and how abstract requests can be mapped to more specific technologies. The memo also discusses related considerations with monitoring and security. This memo is intended for discussing interfaces and technologies. It is not intended to be a new set of concrete interfaces or technologies. Rather, it should be seen as an explanation of how some existing, concrete IETF VPN and traffic-engineering technologies can be used to create IETF network slices. Note that there are a number of these technologies, and new technologies or capabilities keep being added. This memo is also not intended presume any particular technology choice.