IS-IS for IP Internets S. Previdi, Ed. Internet-Draft C. Filsfils Intended status: Standards Track A. Bashandy Expires: April 28, 2015 Cisco Systems, Inc. H. Gredler Juniper Networks, Inc. S. Litkowski B. Decraene Orange J. Tantsura Ericsson October 25, 2014 IS-IS Extensions for Segment Routing draft-ietf-isis-segment-routing-extensions-03 Abstract 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 draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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." Previdi, et al. Expires April 28, 2015 [Page 1] Internet-Draft IS-IS Extensions for Segment Routing October 2014 This Internet-Draft will expire on April 28, 2015. Copyright Notice Copyright (c) 2014 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 2.4.5. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 2.4.6. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 18 2.4.7. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 18 2.4.8. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 19 2.4.9. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 19 2.4.10. Unnumbered Interface ID ERO subTLV . . . . . . . . . 20 2.4.11. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 21 2.4.12. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 21 2.4.13. Unnumbered Interface ID Backup ERO subTLV . . . . . . 22 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics . . . . . . . . . . . . . . . . . . . . . . 23 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 23 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 23 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 Previdi, et al. Expires April 28, 2015 [Page 2] Internet-Draft IS-IS Extensions for Segment Routing October 2014 4.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 27 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 5. Manageability Considerations . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction 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). Two types of segments are defined, Prefix segments and Adjacency segments. Prefix segments represent an ecmp-aware shortest-path to a prefix, as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. SR's control-plane can be applied to both IPv6 and MPLS data-planes, and do not require any additional signaling (other than the regular IGP). For example, when used in MPLS networks, SR paths do not require any LDP or RSVP-TE signaling. Still, SR can interoperate in the presence of LSPs established with RSVP or LDP. This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing. Segment Routing architecture is described in [I-D.filsfils-spring-segment-routing]. Segment Routing use cases are described in [I-D.filsfils-spring-segment-routing-use-cases]. 2. Segment Routing Identifiers Segment Routing architecture ([I-D.filsfils-spring-segment-routing]) defines different types of Segment Identifiers (SID). This document defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. Previdi, et al. Expires April 28, 2015 [Page 3] Internet-Draft IS-IS Extensions for Segment Routing October 2014 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV). The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [I-D.filsfils-spring-segment-routing]. The 'Prefix SID' MUST be unique within a given IGP domain (when the L-flag is not set). The 'Prefix SID' MUST carry an index (when the V-flag is not set) that determines the actual SID/label value inside the set of all advertised SID/label ranges of a given router. A receiving router uses the index to determine the actual SID/label value in order to construct forwarding state to a particular destination router. In many use-cases a 'stable transport' IP Address is overloaded as an identifier of a given node. Because the IP Prefixes may be re- advertised into other levels there may be some ambiguity (e.g. Originating router vs. L1L2 router) for which node a particular IP prefix serves as identifier. The Prefix-SID sub-TLV contains the necessary flags to disambiguate IP Prefix to node mappings. Furthermore if a given node has several 'stable transport' IP addresses there are flags to differentiate those among other IP Prefixes advertised from a given node. A Prefix-SID sub-TLV is associated to a prefix advertised by a node and MAY be present in any of the following TLVs: TLV-135 (IPv4) defined in [RFC5305]. TLV-235 (MT-IPv4) defined in [RFC5120]. TLV-236 (IPv6) defined in [RFC5308]. TLV-237 (MT-IPv6) defined in [RFC5120]. Binding-TLV defined in Section 2.4. When the IP Reachability TLV is propagated across level boundaries, the Prefix-SID sub-TLV SHOULD be kept. The Prefix-SID sub-TLV has the following format: Previdi, et al. Expires April 28, 2015 [Page 4] Internet-Draft IS-IS Extensions for Segment Routing October 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 3 Length: variable. Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R|N|P|E|V|L| | +-+-+-+-+-+-+-+-+ where: R-Flag: Re-advertisement flag. If set, then the prefix to which this Prefix-SID is attached, has been propagated by the router either from another level (i.e.: from level-1 to level-2 or the opposite) or from redistribution (e.g.: from another protocol). N-Flag: Node-SID flag. If set, then the Prefix-SID refers to the router identified by the prefix. Typically, the N-Flag is set on Prefix-SIDs attached to a router loopback address. The N-Flag is set when the Prefix-SID is a Node-SID as described in [I-D.filsfils-spring-segment-routing]. P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering the packet to the node that advertised the Prefix-SID. E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for IPv6) before forwarding the packet. V-Flag: Value flag. If set, then the Prefix-SID carries a value (instead of an index). By default the flag is UNSET. Previdi, et al. Expires April 28, 2015 [Page 5] Internet-Draft IS-IS Extensions for Segment Routing October 2014 L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default the flag is UNSET. Other bits: MUST be zero when originated and ignored when received. Algorithm: the router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Algorithms identifiers are defined in Section 3.2. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The algorithm field of the Prefix-SID contains the identifier of the algorithm the router has used in order to compute the reachability of the prefix the Prefix-SID is associated to. At origination, the Prefix-SID algorithm field MUST be set to 0 on all Prefix-SID of prefixes computed using SPF algorithm (Shortest Path First). On reception of the Prefix-SID sub-TLV, any non-zero algorithm value MUST match what advertised in the SR-Algorithm sub-TLV (Section 3.2). A router receiving a Prefix-SID from a remote node and with an algorithm value that such remote node has not advertised in the SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- TLV. SID/Index/Label: according to the V and L flags, it contains either: * A 4 octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. In this case the V and L flags MUST be unset. * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. 2.1.1. Flags 2.1.1.1. R and N Flags The R-Flag MUST be set for prefixes that are not local to the router and either: advertised because of propagation (Level-1 into Level-2); advertised because of leaking (Level-2 into Level-1); Previdi, et al. Expires April 28, 2015 [Page 6] Internet-Draft IS-IS Extensions for Segment Routing October 2014 advertised because of redistribution (e.g.: from another protocol). In the case where a Level-1-2 router has local interface addresses configured in one level, it may also propagate these addresses into the other level. In such case, the Level-1-2 router MUST NOT set the R bit. The R-bit MUST be set only for prefixes that are not local to the router and advertised by the router because of propagation and/or leaking. The N-Flag is used in order to define a Node-SID. A router MAY set the N-Flag only if all of the following conditions are met: The prefix to which the Prefix-SID is attached is local to the router. I.e.: the prefix is configured on one of the local interfaces. (e.g.: 'stable transport' loopback). The prefix to which the Prefix-SID is attached MUST have a Prefix length of either /32 (IPv4) or /128 (IPv6). The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 2.1.1.2. E and P Flags When calculating the outgoing label for the prefix, the router MUST take into account E and P flags advertised by the next-hop router, if next-hop router advertised the SID for the prefix. This MUST be done regardless of next-hop router contributing to the best path to the prefix or not. When propagating (either from Level-1 to Level-2 or vice versa) a reachability advertisement originated by another IS-IS speaker, the router MUST set the P-flag and MUST clear the E-flag of the related Prefix-SIDs. The following behavior is associated with the settings of the E and P flags: o If the P-flag is not set then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane which improves performance of the ultimate hop. MPLS EXP bits of the Prefix-SID are not preserved to the ultimate hop (the Prefix-SID being removed). If the P-flag is unset the received E-flag is ignored. o If the P-flag is set then: Previdi, et al. Expires April 28, 2015 [Page 7] Internet-Draft IS-IS Extensions for Segment Routing October 2014 * If the E-flag is not set then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when, e.g., the originator of the Prefix-SID must stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an inter-area border router (prefix propagation from one area to another) or at an inter-domain border router (prefix propagation from one domain to another). * If the E-flag is set then any upstream neighbor of the Prefix- SID originator MUST replace the PrefixSID with a Prefix-SID having an Explicit-NULL value. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. 2.1.2. Prefix-SID Propagation The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV gets propagated across level boundaries. The level-1-2 router that propagates the Prefix-SID sub-TLV between levels MUST set the R-flag. If the Prefix-SID contains a global index (L and V flags unset) and it is propagated as such (with L and V flags unset), the value of the index MUST be preserved when propagated between levels. The level-1-2 router that propagates the Prefix-SID sub-TLV between levels MAY change the setting of the L and V flags in case a local label value is encoded in the Prefix-SID instead of the received value. 2.2. Adjacency Segment Identifier A new IS-IS sub-TLV is defined: the 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 [I-D.filsfils-spring-segment-routing] with flags and fields that may be used, in future extensions of Segment Routing, for carrying other types of SIDs. IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs below: TLV-22 [RFC5305] Previdi, et al. Expires April 28, 2015 [Page 8] Internet-Draft IS-IS Extensions for Segment Routing October 2014 TLV-222 [RFC5120] TLV-23 [RFC5311] TLV-223 [RFC5311] TLV-141 [RFC5316] Multiple Adj-SID sub-TLVs MAY be associated with a single IS- neighbor. Examples where more than one Adj-SID may be used per IS- neighbor are described in [I-D.filsfils-spring-segment-routing-use-cases]. 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV The following format is defined for the Adj-SID sub-TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 31 Length: variable. Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|B|V|L|S| | +-+-+-+-+-+-+-+-+ where: F-Flag: Address-Family flag. If unset, then the Adj-SID refers to an adjacency with outgoing IPv4 encapsulation. If set then the Adj-SID refers to an adjacency with outgoing IPv6 encapsulation. B-Flag: Backup flag. If set, the Adj-SID refers to an adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as described in [I-D.filsfils-spring-segment-routing-use-cases]. Previdi, et al. Expires April 28, 2015 [Page 9] Internet-Draft IS-IS Extensions for Segment Routing October 2014 V-Flag: Value flag. If set, then the Adj-SID carries a value. By default the flag is SET. L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. S-Flag. Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well). Other bits: MUST be zero when originated and ignored when received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [I-D.filsfils-spring-segment-routing]. SID/Index/Label: according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. In this case V and L flags MUST be unset. * A 16 octet IPv6 address. In this case the V flag MUST be set. The L flag MUST be unset if the IPv6 address is globally unique. An SR capable router MAY allocate an Adj-SID for each of its adjacencies and SHOULD set the B-Flag when the adjacency is protected by a FRR mechanism (IP or MPLS) as described in [I-D.filsfils-spring-segment-routing-use-cases]. An SR capable router MAY allocate more than one Adj-SID to an adjacency. An SR capable router MAY allocate the same Adj-SID to different adjacencies. Examples of use of the Adj-SID sub-TLV are described in [I-D.filsfils-spring-segment-routing]. and [I-D.previdi-6man-segment-routing-header]. Previdi, et al. Expires April 28, 2015 [Page 10] Internet-Draft IS-IS Extensions for Segment Routing October 2014 The F-flag is used in order for the router to advertise the outgoing encapsulation of the adjacency the Adj-SID is attached to. Use cases of the use of the F-flag are described in [I-D.filsfils-spring-segment-routing-use-cases]. 2.2.2. Adjacency Segment Identifiers in LANs In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS. When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors. Since, on LANs, each router only advertises one adjacency to the DIS (and doesn't advertise any other adjacency), each router advertises the set of Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV part of the TLV advertising the adjacency to the DIS (e.g.: TLV-22). The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, suggested value 32) containing the set of Adj-SIDs the router assigned to each of its LAN neighbors. The format of the LAN-Adj-SID sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System-ID (6 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 32 Length: variable. Flags: 1 octet field of following flags: Previdi, et al. Expires April 28, 2015 [Page 11] Internet-Draft IS-IS Extensions for Segment Routing October 2014 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|B|V|L|S| | +-+-+-+-+-+-+-+-+ where F, B, V, L and S flags are defined in Section 2.2.1. Other bits: MUST be zero when originated and ignored when received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [I-D.filsfils-spring-segment-routing]. System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in [ISO10589]. SID/Index/Label: according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. In this case V and L flags MUST be unset. * A 16 octet IPv6 address. In this case the V flag MUST be set. The L flag MUST be unset if the IPv6 address is globally unique. Multiple LAN-Adj-SID sub-TLVs MAY be encoded. In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be used, MUST have the same metric and SHOULD be inserted within the same LSP fragment. Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each router in the LAN, is capable of reconstructing the LAN topology as well as the set of Adj-SID each router uses for each of its neighbors. A label is encoded in 3 octets (in the 20 rightmost bits). An index is encoded in 4 octets. An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined in [I-D.previdi-6man-segment-routing-header]). Previdi, et al. Expires April 28, 2015 [Page 12] Internet-Draft IS-IS Extensions for Segment Routing October 2014 2.3. SID/Label Sub-TLV The SID/Label sub-TLV is present in the following sub-TLVs defined in this document: Binding TLV Section 2.4. SR Capability sub-TLV Section 3.1. The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 1 Length: variable SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label. 2.4. SID/Label Binding TLV The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain. There are multiple uses of the SID/Label Binding TLV: o The router may advertise a SID/Label binding to a FEC along with at least a single 'nexthop style' anchor. The protocol supports more than one 'nexthop style' anchor to be attached to a SID/Label binding, which results into a simple path description language. In analogy to RSVP the terminology for this is called an 'Explicit Route Object' (ERO). Since ERO style path notation allows to anchor SID/label bindings to both link and node IP addresses any label switched path, can be described. Furthermore also SID/Label Bindings from external protocols can get easily re-advertised. o The SID/Label Binding TLV may be used for advertising SID/Label Bindings and their associated Primary and Backup paths. In one single TLV either a primary ERO Path, a backup ERO Path or both are advertised. If a router wants to advertise multiple parallel Previdi, et al. Expires April 28, 2015 [Page 13] Internet-Draft IS-IS Extensions for Segment Routing October 2014 paths then it can generate several TLVs for the same Prefix/FEC. Each occurrence of a Binding TLV with respect with a given FEC Prefix has accumulating and not canceling semantics. Due the space constraints in the 8-Bit IS-IS TLVs an originating router MAY encode a primary ERO path in one SID/Label Binding TLV and the backup ERO path in a second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label sub-TLV MUST be identical in both TLVs. o The SID/Label Binding TLV may also be used in order to advertise prefixes to SID/Label mappings. This functionality is called the 'Mapping Server' and it's used when, in a heterogeneous network, not all nodes are capable of advertising their own SIDs/Labels. When the SID/Label Binding TLV is used by the Mapping Server in order to advertise prefix to SID/label mappings, the index/label MUST include the Prefix-SID SubTLV (Section 2.1). The SID/Label Binding TLV has Type TBD (suggested value 149), and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | Prefix Length | FEC Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // FEC Prefix (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubTLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SID/Label Binding TLV format o Type: TBD, suggested value 149 o Length: variable. o 1 octet of flags o 1 octet of Weight o 2 octets of Range o 1 octet of Prefix Length o 0-16 octets of FEC Prefix o sub-TLVs, where each sub-TLV consists of a sequence of: Previdi, et al. Expires April 28, 2015 [Page 14] Internet-Draft IS-IS Extensions for Segment Routing October 2014 * 1 octet of sub-TLV type * 1 octet of length of the value field of the sub-TLV * 0-243 octets of value 2.4.1. Flags Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|M|S|D|A| | +-+-+-+-+-+-+-+-+ where: F-Flag: Address Family flag. If unset, then the Prefix FEC carries an IPv4 Prefix. If set then the Prefix FEC carries an IPv6 Prefix. M-Flag: Mirror Context flag. Set if the advertised SID/path corresponds to a mirrored context. The use of the M flag is described in [I-D.filsfils-spring-segment-routing]. S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing domain. If the S flag is not set, the SID/ Label Binding TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking. D-Flag: when the SID/Label Binding TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. SID/Label Binding TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping across levels. A-Flag: Attached flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators. The mechanisms through which the originator of the SID/Label Binding TLV can figure out if a prefix is attached or not are outside the scope of this document (e.g.: through explicit configuration). An implementation MAY decide not to honor the S-flag in order not to leak Binding TLV's between levels (for policy reasons). In all cases, the D flag MUST always be set by any router leaking the Binding TLV from level-2 into level-1 and MUST be checked when Previdi, et al. Expires April 28, 2015 [Page 15] Internet-Draft IS-IS Extensions for Segment Routing October 2014 propagating the Binding TLV from level-1 into level-2. If the D flag is set, the Binding TLV MUST NOT be propagated into level-2. Other bits: MUST be zero when originated and ignored when received. 2.4.2. Weight Weight: 1 octet: The value represents the weight of the path for the purpose of load balancing. The use of the weight is defined in [I-D.filsfils-spring-segment-routing]. 2.4.3. Range The 'Range' field provides the ability to specify a range of addresses and their associated Prefix SIDs. This functionality is called "Mapping Server". It is essentially a compression scheme to distribute a continuous Prefix and their continuous, corresponding SID/Label Block. If a single SID is advertised then the range field MUST be set to one. For range advertisements > 1, the number of addresses that need to be mapped into a Prefix-SID and the starting value of the Prefix-SID range. Example 1: if the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix SID indexes. Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |0|0| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 4 | /32 | 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .0 | .2 | .1 |Prefix-SID Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Length| Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example-2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes: Previdi, et al. Expires April 28, 2015 [Page 16] Internet-Draft IS-IS Extensions for Segment Routing October 2014 10.1.1/24, Prefix-SID: Index 51 10.1.2/24, Prefix-SID: Index 52 10.1.3/24, Prefix-SID: Index 53 10.1.4/24, Prefix-SID: Index 54 10.1.5/24, Prefix-SID: Index 55 10.1.6/24, Prefix-SID: Index 56 10.1.7/24, Prefix-SID: Index 57 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |0|0| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 7 | /24 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .1 | .1 |Prefix-SID Type| sub-TLV Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 51 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is not expected that a network operator will be able to keep fully continuous FEC Prefix / SID/Index mappings. In order to support noncontinuous mapping ranges an implementation MAY generate several instances of Binding TLVs. For example if a router wants to advertise the following ranges: Range 16: { 192.168.1.1-15, Index 1-15 } Range 6: { 192.168.1.22-27, Index 22-27 } Range 41: { 192.168.1.44-84, Index 80-120 } A router would need to advertise three instances of the Binding TLV. 2.4.4. Prefix Length, Prefix The 'FEC Prefix' represents the Forwarding equivalence class at the tail-end of the advertised path. The 'FEC Prefix' does not need to correspond to a routable prefix of the originating node. The 'Prefix Length' field contains the length of the prefix in bits. Only the most significant octets of the Prefix FEC are encoded. I.e. 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 Previdi, et al. Expires April 28, 2015 [Page 17] Internet-Draft IS-IS Extensions for Segment Routing October 2014 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC prefix length 113 up to 128. 2.4.5. Mapping Server Prefix-SID The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 and contains the SID/index/label value associated with the prefix and range. The Prefix-SID SubTLV MUST be used when the SID/Label Binding TLV is used by the Mapping Server (i.e.: advertising one or a range of prefixes and their associated SIDs/Labels). A node receiving a MS entry for a prefix MUST check the existence of such prefix in its link-state database prior to consider and use the associated SID. 2.4.5.1. Prefix-SID Flags The Prefix-SID flags are defined in Section 2.1. The Mapping Server MAY advertise a mapping with the N flag set when the prefix being mapped is known in the link-state topology with a mask length of 32 and when the prefix represents a node. The mechanisms through which the operator defines that a prefix represents a node are outside the scope of this document (typically it will be through configuration). The other flags defined in Section 2.1 are not used by the Mapping Server and MUST be ignored at reception. 2.4.5.2. Prefix-SID Algorithm The algorithm field contains the identifier of the algorithm the router MUST use in order to compute reachability to the range of prefixes. Use of the algorithm field is described in Section 2.1. 2.4.6. SID/Label Sub-TLV The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the SID/Label value as defined in Section 2.3. It MAY be present in the SID/Label Binding TLV. 2.4.7. ERO Metric sub-TLV ERO Metric sub-TLV (Type: TBD, suggested value 10) is a sub-TLV of the SID/Label Binding TLV. The ERO Metric sub-TLV carries the cost of an ERO path. It is used to compare the cost of a given source/destination path. A router MAY advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the advertised Previdi, et al. Expires April 28, 2015 [Page 18] Internet-Draft IS-IS Extensions for Segment Routing October 2014 ERO. Since manipulation of the Metric field may attract or distract traffic from and to the advertised segment it MAY be manually overridden. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ERO Metric sub-TLV format where: Type: TBD, suggested value 10 Length: 4 Metric: 4 bytes 2.4.8. IPv4 ERO subTLV The IPv4 ERO subTLV (Type: TBD, suggested value 11) describes a path segment using IPv4 address style of encoding. Its semantics have been borrowed from [RFC3209]. The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv4 ERO subTLV format 2.4.9. IPv6 ERO subTLV The IPv6 ERO subTLV (Type: TBD, suggested value 12) describes a path segment using IPv6 Address style of encoding. Its semantics have been borrowed from [RFC3209]. Previdi, et al. Expires April 28, 2015 [Page 19] Internet-Draft IS-IS Extensions for Segment Routing October 2014 The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 ERO subTLV format 2.4.10. Unnumbered Interface ID ERO subTLV The appearance and semantics of the 'Unnumbered Interface ID' have been borrowed from Section 4 [RFC3477]. The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 13) describes a path segment that spans over an unnumbered interface. Unnumbered interfaces are referenced using the interface index. Interface indices are assigned local to the router and therefore not unique within a domain. All elements in an ERO path need to be unique within a domain and hence need to be disambiguated using a domain unique Router-ID. The 'Router-ID' field contains the router ID of the router which has assigned the 'Interface ID' field. Its purpose is to disambiguate the 'Interface ID' field from other routers in the domain. IS-IS supports two Router-ID formats: o (TLV 134, 32-Bit format) [RFC5305] o (TLV 140, 128-Bit format) [RFC6119] The actual Router-ID format gets derived from the 'Length' field. o For 32-Bit Router-ID width the subTLV length is set to 8 octets. o For 128-Bit Router-ID width the subTLV length is set to 20 octets. Previdi, et al. Expires April 28, 2015 [Page 20] Internet-Draft IS-IS Extensions for Segment Routing October 2014 The 'Interface ID' is the identifier assigned to the link by the router specified by the router ID. The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Router ID (32 or 128 bits) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Unnumbered Interface ID ERO subTLV format 2.4.11. IPv4 Backup ERO subTLV The IPv4 Backup ERO subTLV (Type: TBD, suggested value 14) describes a Backup path segment using IPv4 Address style of encoding. Its appearance and semantics have been borrowed from [RFC3209]. The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPv4 Backup ERO subTLV format 2.4.12. IPv6 Backup ERO subTLV The IPv6 Backup ERO subTLV (Type: TBD, suggested value 15) describes a Backup path segment using IPv6 Address style of encoding. Its appearance and semantics have been borrowed from [RFC3209]. The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' Previdi, et al. Expires April 28, 2015 [Page 21] Internet-Draft IS-IS Extensions for Segment Routing October 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: IPv6 Backup ERO subTLV format 2.4.13. Unnumbered Interface ID Backup ERO subTLV The appearance and semantics of the 'Unnumbered Interface ID' have been borrowed from Section 4 [RFC3477]. The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested value 16) describes a Backup LSP path segment that spans over an unnumbered interface. Unnumbered interfaces are referenced using the interface index. Interface indices are assigned local to the router and therefore not unique within a domain. All elements in an ERO path need to be unique within a domain and hence need to be disambiguated using a domain unique Router-ID. The 'Router-ID' field contains the router ID of the router which has assigned the 'Interface ID' field. Its purpose is to disambiguate the 'Interface ID' field from other routers in the domain. IS-IS supports two Router-ID formats: o (TLV 134, 32-Bit format) [RFC5305] o (TLV 140, 128-Bit format) [RFC6119] The actual Router-ID format gets derived from the 'Length' field. o For 32-Bit Router-ID width the subTLV length is set to 8 octets. o For 128-Bit Router-ID width the subTLV length is set to 20 octets. The 'Interface ID' is the identifier assigned to the link by the router specified by the router ID. Previdi, et al. Expires April 28, 2015 [Page 22] Internet-Draft IS-IS Extensions for Segment Routing October 2014 The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Router ID (32 or 128 bits) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Unnumbered Interface ID Backup ERO subTLV format 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics All 'ERO' and 'Backup ERO' information represents an ordered set which describes the segments of a path. The last ERO subTLV describes the segment closest to the egress point of the path. Contrary the first ERO subTLV describes the first segment of a path. If a router extends or stitches a label switched path it MUST prepend the new segments path information to the ERO list. The same ordering applies for the Backup ERO labels. An implementation SHOULD first encode all primary path EROs followed by the bypass EROs. 3. Router Capabilities 3.1. SR-Capabilities Sub-TLV Segment Routing requires each router to advertise its SR data-plane capability and the range of MPLS label values it uses for Segment Routing in the case where global SIDs are allocated (i.e.: global indexes). Data-plane capabilities and label ranges are advertised using the newly defined SR-Capabilities sub-TLV inserted into the IS- IS Router Capability TLV-242 that is defined in [RFC4971]. The Router Capability TLV specifies flags that control its advertisement. The SR Capabilities sub-TLV MUST be propagated throughout the level and SHOULD NOT be advertised across level boundaries. Therefore Router Capability TLV distribution flags SHOULD be set accordingly, i.e.: the S flag MUST be unset. The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY appear multiple times inside the Router Capability TLV and has following format: Previdi, et al. Expires April 28, 2015 [Page 23] Internet-Draft IS-IS Extensions for Segment Routing October 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (cont.) | SID/Label sub-TLV (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 2 Length: variable. Flags: 1 octet of flags. The following are defined: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|V| | +-+-+-+-+-+-+-+-+ where: I-Flag: IPv4 flag. If set, then the router is capable of outgoing IPv4 encapsulation on all interfaces. V-Flag: IPv6 flag. If set, then the router is capable of outgoing IPv6 encapsulation on all interfaces. Range: 3 octets value defining the number of values of the range from the starting value defined in the SID/Label sub-TLV. SID/Label sub-TLV: SID/Label value as defined in Section 2.3. Multiple occurrence of the SR-Capabilities sub-TLV MAY be advertised, in order to advertise multiple ranges. In such case: o Only the Flags in the first occurrence of the sub-TLV are to be taken into account. o The originating router MUST encode ranges each into a different SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded within the same LSP fragment. o The order of the ranges (i.e.: SR-Capability sub-TLVs) in the LSP fragment is decided by the originating router and hence the receiving routers MUST NOT re-order the received ranges. This is Previdi, et al. Expires April 28, 2015 [Page 24] Internet-Draft IS-IS Extensions for Segment Routing October 2014 required for avoiding label churn when for example a numerical lower Segment/Label Block gets added to an already advertised Segment/Label Block. o An originator router SHOULD add newly configured block at the end, and SHOULD NOT change the order of previously advertised block. Indeed, changing the order to block being used will create label churn in the FIB and blackhole / misdirect some traffic during the IGP convergence. In particular, if a range, which is not the last, is extended it's preferable to add a new range rather than extending the previously advertised range. o The originating router decides the order of the set of originated SR-Capability sub-TLV. In all cases, the originating router MUST ensure the order is same after a graceful restart (using checkpointing, non-volatile storage or any other mechanism) in order to guarantee the same order before and after GR. o The originator router MUST NOT advertising overlapping range. o A router not supporting multiple occurrences of the SR-Capability sub-TLV MUST take into consideration the first occurrence in the received set. Here follows an example of advertisement of multiple ranges: The originating router advertises following ranges: SR-Cap: range: 100, SID value: 100 SR-Cap: range: 100, SID value: 1000 SR-Cap: range: 100, SID value: 500 The receiving routers concatenate the ranges and build the SRGB is as follows: SRGB = [100, 199] [1000, 1099] [500, 599] The indexes span multiple ranges: index=0 means label 100 ... index 99 means label 199 index 100 means label 1000 index 199 means label 1099 ... index 200 means label 500 ... Previdi, et al. Expires April 28, 2015 [Page 25] Internet-Draft IS-IS Extensions for Segment Routing October 2014 3.2. SR-Algorithm Sub-TLV The router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, suggested value 19) allows the router to advertise the algorithms that the router is currently using. The following value has been defined: 0: Shortest Path First (SPF) algorithm based on link metric. The SR-Algorithm sub-TLV is inserted into the IS-IS Router Capability TLV-242 that is defined in [RFC4971]. The Router Capability TLV specifies flags that control its advertisement. The SR-Algorithm MUST be propagated throughout the level and need not to be advertised across level boundaries. Therefore Router Capability TLV distribution flags MUST be set accordingly, i.e.: the S flag MUST be unset. The SR-Algorithm sub-TLV is optional, it MAY only appear a single time inside the Router Capability TLV. When the originating router does not advertise the SR-Algorithm sub- TLV, then all the Prefix-SID advertised by the router MUST have algorithm field set to 0. Any receiving router MUST assume SPF algorithm (i.e.: Shortest Path First). The SR-Algorithm sub-TLV has following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 19 Length: variable. Algorithm: 1 octet of algorithm Section 2.1 Previdi, et al. Expires April 28, 2015 [Page 26] Internet-Draft IS-IS Extensions for Segment Routing October 2014 4. IANA Considerations This documents request allocation for the following TLVs and subTLVs. 4.1. Sub TLVs for Type 22,23,222 and 223 This document makes the following registrations in the "sub-TLVs for TLV 22, 23, 222 and 223" registry. Type: TBD (suggested value 31) Description: Adjacency Segment Identifier TLV 22: yes TLV 23: yes TLV 222: yes TLV 223: yes Reference: This document (Section 2.2.1) Type: TBD (suggested value 32) Description: LAN Adjacency Segment Identifier TLV 22: yes TLV 23: yes TLV 222: yes TLV 223: yes Reference: This document (Section 2.2.2) 4.2. Sub TLVs for Type 135,235,236 and 237 This document makes the following registrations in the "sub-TLVs for TLV 135,235,236 and 237" registry. Type: TBD (suggested value 3) Previdi, et al. Expires April 28, 2015 [Page 27] Internet-Draft IS-IS Extensions for Segment Routing October 2014 Description: Prefix Segment Identifier TLV 135: yes TLV 235: yes TLV 236: yes TLV 237: yes Reference: This document (Section 2.1) 4.3. Sub TLVs for Type 242 This document makes the following registrations in the "sub-TLVs for TLV 242" registry. Type: TBD (suggested value 2) Description: Segment Routing Capability Reference: This document (Section 3.1) Type: TBD (suggested value 19) Description: Segment Routing Algorithm Reference: This document (Section 3.2) 4.4. New TLV Codepoint and Sub-TLV registry This document registers the following TLV: Type: TBD (suggested value 149) name: Segment Identifier / Label Binding IIH: no LSP: yes SNP: no Purge: no Previdi, et al. Expires April 28, 2015 [Page 28] Internet-Draft IS-IS Extensions for Segment Routing October 2014 Reference: This document (Section 2.4) This document creates the following sub-TLV Registry: Registry: sub-TLVs for TLV 149 Registration Procedure: Expert review Reference: This document (Section 2.4) Type: TBD, suggested value 1 Description: SID/Label Reference: This document (Section 2.3) Type: TBD, suggested value 3 Description: Prefix-SID Reference: This document (Section 2.1) Type: TBD, suggested value 10 Description: ERO Metric Reference: This document (Section 2.4.7) Type: TBD, suggested value 11 Description: IPv4 ERO Reference: This document (Section 2.4.8) Type: TBD, suggested value 12 Description: IPv6 ERO Reference: This document (Section 2.4.9) Previdi, et al. Expires April 28, 2015 [Page 29] Internet-Draft IS-IS Extensions for Segment Routing October 2014 Type: TBD, suggested value 13 Description: Unnumbered Interface-ID ERO Reference: This document (Section 2.4.10) Type: TBD, suggested value 14 Description: IPv4 Backup ERO Reference: This document (Section 2.4.11) Type: TBD, suggested value 15 Description: IPv6 Backup ERO Reference: This document (Section 2.4.12) Type: TBD, suggested value 16 Description: Unnumbered Interface-ID Backup ERO Reference: This document (Section 2.4.13) 5. Manageability Considerations TBD 6. Security Considerations TBD 7. Contributors The following people gave a substantial contribution to the content of this document: Martin Horneffer, Igor Milojevic, Rob Shakir, Saku Ytti, Wim Henderickx, Les Ginsberg, Steven Luong and Jesper Skriver. Previdi, et al. Expires April 28, 2015 [Page 30] Internet-Draft IS-IS Extensions for Segment Routing October 2014 8. Acknowledgements We would like to thank Dave Ward, Dan Frost, Stewart Bryant and Pierre Francois for their contribution to the content of this document. Many thanks to Yakov Rekhter and Ina Minei for their contribution on earlier incarnations of the "Binding / MPLS Label TLV". 9. References 9.1. Normative References [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. Previdi, et al. Expires April 28, 2015 [Page 31] Internet-Draft IS-IS Extensions for Segment Routing October 2014 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, February 2009. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011. 9.2. Informative References [I-D.filsfils-spring-segment-routing] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-filsfils-spring- segment-routing-04 (work in progress), July 2014. [I-D.filsfils-spring-segment-routing-use-cases] Filsfils, C., Francois, P., Previdi, S., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Crabbe, "Segment Routing Use Cases", draft-filsfils- spring-segment-routing-use-cases-01 (work in progress), October 2014. [I-D.previdi-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Segment Routing Header (SRH)", draft-previdi-6man-segment- routing-header-02 (work in progress), July 2014. Authors' Addresses Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Previdi, et al. Expires April 28, 2015 [Page 32] Internet-Draft IS-IS Extensions for Segment Routing October 2014 Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Ahmed Bashandy Cisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134 US Email: bashandy@cisco.com Hannes Gredler Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: hannes@juniper.net Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Bruno Decraene Orange FR Email: bruno.decraene@orange.com Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 US Email: Jeff.Tantsura@ericsson.com Previdi, et al. Expires April 28, 2015 [Page 33]