IGP Extensions for SR Network Resource Partition SIDsJuniper Networkstsaad@juniper.netJuniper Networksvbeeram@juniper.netZTE Corporationchen.ran@zte.com.cnZTE Corporationpeng.shaofu@zte.com.cnComcastBin_Wen@cable.comcast.comEricssondaniele.ceccarelli@ericsson.comLSR Working GroupInternet-DraftSegment 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 registryNRP-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: TBD6Length: 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 TypeDescriptionReferenceTBD1NRP Prefix-SID Sub-TLVTable 2 summarizes registrations made in the “Sub-TLVs for TLV
22, 23, 25, 141, 222, and 223” registry.Sub-TLV TypeDescriptionReferenceTBD2NRP Adj-SID Sub-TLVTBD3NRP LAN-Adj-SID Sub-TLVTBD4NRP Per Algo Adj-SID Sub-TLVTBD5NRP Per Algo LAN-Adj-SID Sub-TLVThe 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:Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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 ArchitectureSegment 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.Realizing Network Slices in IP/MPLS NetworksJuniper NetworksJuniper NetworksHuawei TechnologiesComcastEricssonEricssonZTE CorporationZTE CorporationVolta NetworksTelefonicaCienaVerizon 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.
Scalable Network Slicing over SR NetworksJuniper NetworksJuniper NetworksZTE CorporationZTE CorporationComcastEricsson 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.
IS-IS Extensions for Segment RoutingSegment 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.IS-IS Extensions for Traffic EngineeringThis 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]M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)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]Routing IPv6 with IS-ISThis 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]Simplified Extension of Link State PDU (LSP) Space for IS-ISThis 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]ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic EngineeringThis 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]Algorithm Related IGP-Adjacency SID AdvertisementZTE CorporationZTE CorporationCisco SystemsCisco 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
IPv6 Segment Routing Header (SRH)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.IS-IS Extensions to Support Segment Routing over IPv6 DataplaneCisco SystemsCisco SystemsIndividualOrangeHuawei 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.
Definition of IETF Network SlicesNokiaNTTFutureweiTelefonicaJuniper 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.
Framework for IETF Network SlicesEricssonJuniper 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.