idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2014) is 3666 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '100' on line 985 -- Looks like a reference, but probably isn't: '199' on line 985 -- Looks like a reference, but probably isn't: '1000' on line 986 -- Looks like a reference, but probably isn't: '1099' on line 986 -- Looks like a reference, but probably isn't: '500' on line 987 -- Looks like a reference, but probably isn't: '599' on line 987 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Bashandy 5 Expires: October 13, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 Orange 10 J. Tantsura 11 Ericsson 12 April 11, 2014 14 IS-IS Extensions for Segment Routing 15 draft-ietf-isis-segment-routing-extensions-00 17 Abstract 19 Segment Routing (SR) allows for a flexible definition of end-to-end 20 paths within IGP topologies by encoding paths as sequences of 21 topological sub-paths, called "segments". These segments are 22 advertised by the link-state routing protocols (IS-IS and OSPF). 24 This draft describes the necessary IS-IS extensions that need to be 25 introduced for Segment Routing. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 13, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 69 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 71 2.3. Adjacency Segment Identifier . . . . . . . . . . . . . . 7 72 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 8 73 2.3.2. Adjacency Segment Identifiers in LANs . . . . . . . . 9 74 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 11 75 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 12 76 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 13 78 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 14 79 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 15 80 2.4.6. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 15 81 2.4.7. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 15 82 2.4.8. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 83 2.4.9. Unnumbered Interface ID ERO subTLV . . . . . . . . . 16 84 2.4.10. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 17 85 2.4.11. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 18 86 2.4.12. Unnumbered Interface ID Backup ERO subTLV . . . . . . 18 87 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path 88 semantics . . . . . . . . . . . . . . . . . . . . . . 19 89 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 90 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 91 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 92 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 4.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 23 94 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 24 95 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 24 96 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 25 97 5. Manageability Considerations . . . . . . . . . . . . . . . . 27 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 99 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 9.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 106 1. Introduction 108 Segment Routing (SR) allows for a flexible definition of end-to-end 109 paths within IGP topologies by encoding paths as sequences of 110 topological sub-paths, called "segments". These segments are 111 advertised by the link-state routing protocols (IS-IS and OSPF). Two 112 types of segments are defined, Prefix segments and Adjacency 113 segments. Prefix segments represent an ecmp-aware shortest-path to a 114 prefix, as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 do not require any additional signaling (other than the regular IGP). 120 For example, when used in MPLS networks, SR paths do not require any 121 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 122 of LSPs established with RSVP or LDP. 124 This draft describes the necessary IS-IS extensions that need to be 125 introduced for Segment Routing. 127 Segment Routing architecture is described in 128 [I-D.filsfils-rtgwg-segment-routing]. 130 Segment Routing use cases are described in 131 [I-D.filsfils-spring-segment-routing-use-cases]. 133 2. Segment Routing Identifiers 135 Segment Routing architecture ([I-D.filsfils-rtgwg-segment-routing]) 136 defines different types of Segment Identifiers (SID). This document 137 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 138 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 140 2.1. SID/Label Sub-TLV 142 The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this 143 document and contains a SID or a MPLS Label. The SID/Label Sub-TLV 144 has the following format: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | SID/Label (variable) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 where: 156 Type: TBD, suggested value 1 158 Length: variable (3 or 4) 160 SID/Label: if length is set to 3 then the 20 rightmost bits 161 represent a MPLS label. If length is 4 then the value represents 162 a 32 bits SID. 164 The receiving router MUST silently ignore SID/Label sub-TLVs whose 165 length is different from 3 and 4. 167 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) 169 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 170 (Prefix-SID Sub-TLV). 172 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as 173 defined in [I-D.filsfils-rtgwg-segment-routing]. The 'Prefix SID' 174 must be unique within a given IGP domain. The 'Prefix SID' is an 175 index to determine the actual SID/label value inside the set of all 176 advertised SID/label ranges of a given router. A receiving router 177 uses the index to determine the actual SID/label value in order to 178 construct forwarding state to a particular destination router. 180 In many use-cases a 'stable transport' IP Address is overloaded as an 181 identifier of a given node. Because the IP Prefixes may be re- 182 advertised into other levels there may be some ambiguity (e.g. 183 Originating router vs. L1L2 router) for which node a particular IP 184 prefix serves as identifier. The Prefix-SID Sub-TLV contains the 185 necessary flags to disambiguate IP Prefix to node mappings. 186 Furthermore if a given node has several 'stable transport' IP 187 addresses there are flags to differentiate those among other IP 188 Prefixes advertised from a given node. 190 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 191 and MAY be present in any of the following TLVs: 193 TLV-135 (IPv4) defined in [RFC5305]. 195 TLV-235 (MT-IPv4) defined in [RFC5120]. 197 TLV-236 (IPv6) defined in [RFC5308]. 199 TLV-237 (MT-IPv6) defined in [RFC5120]. 201 The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP 202 Reachability TLV gets propagated across level boundaries. 204 The Prefix-SID Sub-TLV has the following format: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | Flags | Algorithm | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | SID/Index | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 where: 216 Type: TBD, suggested value 3 218 Length: variable. 220 Flags: 1 octet field of following flags: 222 0 1 2 3 4 5 6 7 223 +-+-+-+-+-+-+-+-+ 224 |R|N|P| | 225 +-+-+-+-+-+-+-+-+ 227 where: 229 R-Flag: Re-advertisement flag. If set, then the prefix to 230 which this Prefix-SID is attached, has been propagated by the 231 router either from another level (i.e.: from level-1 to level-2 232 or the opposite) or from redistribution (e.g.: from another 233 protocol). 235 N-Flag: Node-SID flag. Optional and, if set, then the Prefix- 236 SID refers to the router identified by the prefix. Typically, 237 the N-Flag is set on Prefix-SIDs attached to a router loopback 238 address. The N-Flag is set when the Prefix-SID is a Node-SID 239 as described in [I-D.filsfils-rtgwg-segment-routing]. 241 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 242 pop the Prefix-SID before delivering the packet to the node 243 that advertised the Prefix-SID. 245 Other bits: MUST be zero when originated and ignored when 246 received. 248 Algorithm: the router may use various algorithms when calculating 249 reachability to other nodes or to prefixes attached to these 250 nodes. Examples of these algorithms are metric based Shortest 251 Path First (SPF), various sorts of Constrained SPF, etc. The 252 Algorithm field allows a router to advertise algorithms that 253 router is currently using. SR-Algorithm TLV has following 254 structure: one octet identifying the algorithm to which the 255 Prefix-SID is associated. Currently, the following value has been 256 defined: 258 0: Shortest Path First (SPF) algorithm based on link metric. 260 Definitions and use of algorithms in Segment Routing are 261 described in [I-D.filsfils-rtgwg-segment-routing] 263 SID/Index: 32 bit index defining the offset in the SID/Label space 264 advertised by this router using the encodings defined in 265 Section 3.1. 267 Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which 268 case each SID is encoded as a separate Sub-TLV. When multiple 269 Prefix-SID Sub-TLVs are present, the receiving router MUST use the 270 first encoded SID and MAY use the subsequent ones. 272 The No-PHP flag MUST be set on the Prefix-SIDs associated with 273 reachability advertisements which were originated by other routers 274 and leaked (either from Level-1 to Level-2 or vice versa). 276 The R-Flag MUST be set for prefixes that are not local to the router 277 and either: 279 advertised because of propagation (Level-1 into Level-2); 281 advertised because of leaking (Level-2 into Level-1); 283 advertised because redistribution (e.g.: from another protocol). 285 In the case where a Level-1-2 router has local interface addresses 286 configured in one level, it may also propagate these addresses into 287 the other level. In such case, the Level-1-2 router MUST NOT set the 288 R bit. The R-bit MUST be set only for prefixes that are not local to 289 the router and advertised by the router because of propagation and/or 290 leaking. 292 The N-Flag is used in order to define a Node-SID. A router MAY set 293 the N-Flag only if all of the following conditions are met: 295 The prefix to which the Prefix-SID is attached is local to the 296 router. I.e.: the prefix is configured on one of the local 297 interfaces. (e.g.: 'stable transport' loopback). 299 The prefix to which the Prefix-SID is attached MUST have a Prefix 300 length of either /32 (IPv4) or /128 (IPv6). 302 The router MUST ignore the N-Flag on a received Prefix-SID if the 303 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 305 The router behavior determined by the P, R and N flags are described 306 in [I-D.filsfils-rtgwg-segment-routing]. 308 2.3. Adjacency Segment Identifier 310 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 311 TLV (Adj-SID Sub-TLV). 313 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 314 Routing IGP-Adjacency-SID as defined in 315 [I-D.filsfils-rtgwg-segment-routing] with flags and fields that may 316 be used, in future extensions of Segment Routing, for carrying other 317 types of SIDs. 319 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 320 below: 322 TLV-22 [RFC5305] 324 TLV-222 [RFC5120] 326 TLV-23 [RFC5311] 328 TLV-223 [RFC5311] 330 TLV-141 [RFC5316] 332 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 333 neighbor. Examples where more than one Adj-SID may be used per IS- 334 neighbor are described in 335 [I-D.filsfils-spring-segment-routing-use-cases]. 337 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 339 The following format is defined for the Adj-SID Sub-TLV: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type | Length | Flags | Weight | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | SID/Label Sub-TLV (variable) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 where: 351 Type: TBD, suggested value 31 353 Length: variable. 355 Flags: 1 octet field of following flags: 357 0 1 2 3 4 5 6 7 358 +-+-+-+-+-+-+-+ 359 |F|B| | 360 +-+-+-+-+-+-+-+ 362 where: 364 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 365 to an adjacency with outgoing IPv4 encapsulation. If set then 366 the Adj-SID refers to an adjacency with outgoing IPv6 367 encapsulation. 369 B-Flag: Backup flag. If set, the Adj-SID refers to an 370 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 371 described in [I-D.filsfils-spring-segment-routing-use-cases]. 373 Other bits: MUST be zero when originated and ignored when 374 received. 376 Weight: 1 octet. The value represents the weight of the Adj-SID 377 for the purpose of load balancing. The use of the weight is 378 defined in [I-D.filsfils-rtgwg-segment-routing]. 380 SID/Label Sub-TLV: contains the SID/Label value as defined in 381 Section 2.1. 383 An SR capable router MAY allocate an Adj-SID for each of its 384 adjacencies and SHOULD set the B-Flag when the adjacency is 385 protected by a FRR mechanism (IP or MPLS) as described in 386 [I-D.filsfils-spring-segment-routing-use-cases]. 388 An SR capable router MAY allocate more than one Adj-SID to an 389 adjacency. 391 An SR capable router MAY allocate the same Adj-SID to different 392 adjacencies. 394 Examples of use of the Adj-SID Sub-TLV are described in 395 [I-D.filsfils-rtgwg-segment-routing]. 397 The F-flag is used in order for the router to advertise the 398 outgoing encapsulation of the adjacency the Adj-SID is attached 399 to. Use cases of the use of the F-flag are described in 400 [I-D.filsfils-spring-segment-routing-use-cases]. 402 2.3.2. Adjacency Segment Identifiers in LANs 404 In LAN subnetworks, the Designated Intermediate System (DIS) is 405 elected and originates the Pseudonode-LSP (PN-LSP) including all 406 neighbors of the DIS. 408 When Segment Routing is used, each router in the LAN MAY advertise 409 the Adj-SID of each of its neighbors. Since, on LANs, each router 410 only advertises one adjacency to the DIS (and doesn't advertise any 411 other adjacency), each router advertises the set of Adj-SIDs (for 412 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 413 advertising the adjacency to the DIS (e.g.: TLV-22). 415 The following new Sub-TLV is defined: LAN-Adj-SID (Type: TBD, 416 suggested value 32) containing the set of Adj-SIDs the router 417 assigned to each of its LAN neighbors. 419 The format of the LAN-Adj-SID Sub-TLV is as follows: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | Flags | Weight | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | System-ID (6 octets) | 429 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | SID/Label Sub-TLV (variable) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 where: 439 Type: TBD, suggested value 32 441 Length: variable. 443 Flags: 1 octet field of following flags: 445 0 1 2 3 4 5 6 7 446 +-+-+-+-+-+-+-+ 447 |F|B| | 448 +-+-+-+-+-+-+-+ 450 where: 452 F-Flag: Address Family flag. If unset, then the Adj-SID refers 453 to an adjacency with outgoing IPv4 encapsulation. If set then 454 the Adj-SID refers to an adjacency with outgoing IPv6 455 encapsulation. 457 B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an 458 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 459 described in [I-D.filsfils-spring-segment-routing-use-cases]. 461 Other bits: MUST be zero when originated and ignored when 462 received. 464 Weight: 1 octet. The value represents the weight of the Adj-SID 465 for the purpose of load balancing. The use of the weight is 466 defined in [I-D.filsfils-rtgwg-segment-routing]. 468 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 469 defined in [ISO10589]. 471 SID/Label Sub-TLV: contains the SID/Label value as defined in 472 Section 2.1. 474 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 476 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 477 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 478 advertisements of the adjacency to the DIS MUST be used, MUST have 479 the same metric and SHOULD be inserted within the same LSP fragment. 481 Each router within the level, by receiving the DIS PN LSP as well as 482 the non-PN LSP of each router in the LAN, is capable of 483 reconstructing the LAN topology as well as the set of Adj-SID each 484 router uses for each of its neighbors. 486 2.4. SID/Label Binding TLV 488 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 489 domain. The router may advertise a SID/Label binding to a FEC along 490 with at least a single 'nexthop style' anchor. The protocol supports 491 more than one 'nexthop style' anchor to be attached to a SID/Label 492 binding, which results into a simple path description language. In 493 analogy to RSVP the terminology for this is called an 'Explicit Route 494 Object' (ERO). Since ERO style path notation allows to anchor SID/ 495 label bindings to to both link and node IP addresses any label 496 switched path, can be described. Furthermore also SID/Label Bindings 497 from external protocols can get easily re-advertised. 499 The SID/Label Binding TLV may be used for advertising SID/Label 500 Bindings and their associated Primary and Backup paths. In one 501 single TLV either a primary ERO Path, a backup ERO Path or both are 502 advertised. If a router wants to advertise multiple parallel paths 503 then it can generate several TLVs for the same Prefix/FEC. Each 504 occurrence of a Binding TLV with respect with a given FEC Prefix has 505 accumulating and not canceling semantics. Due the space constraints 506 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 507 ERO path in one SID/Label Binding TLV and the backup ERO path in a 508 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 509 Sub-TLV MUST be identical in both TLVs. 511 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 512 the following format: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | Flags | Weight | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Range | Prefix Length | FEC Prefix | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 // FEC Prefix (continued, variable) // 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | SubTLVs (variable) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 1: SID/Label Binding TLV format 528 o Type: TBD, suggested value 149 530 o Length: variable. 532 o 1 octet of flags 534 o 1 octet of Weight 536 o 2 octets of Range 538 o 1 octet of Prefix Length 540 o 0-16 octets of FEC Prefix 542 o sub-TLVs, where each sub-TLV consists of a sequence of: 544 * 1 octet of sub-TLV type 546 * 1 octet of length of the value field of the sub-TLV 548 * 0-243 octets of value 550 2.4.1. Flags 552 Flags: 1 octet field of following flags: 554 0 1 2 3 4 5 6 7 555 +-+-+-+-+-+-+-+-+ 556 |F|M| | 557 +-+-+-+-+-+-+-+-+ 559 where: 561 F-Flag: Address Family flag. If unset, then the Prefix FEC 562 carries an IPv4 Prefix. If set then the Prefix FEC carries an 563 IPv6 Prefix. 565 M-Flag: Mirror Context flag. Set if the advertised SID/path 566 corresponds to a mirrored context. The use of the M flag is 567 described in [I-D.filsfils-rtgwg-segment-routing]. 569 Other bits: MUST be zero when originated and ignored when 570 received. 572 2.4.2. Weight 574 Weight: 1 octet: The value represents the weight of the path for the 575 purpose of load balancing. The use of the weight is defined in 576 [I-D.filsfils-rtgwg-segment-routing]. 578 2.4.3. Range 580 The 'Range' field provides the ability to specify a range of 581 addresses and their associated Prefix SIDs. It is essentially a 582 compression scheme to distribute a continuous Prefix and their 583 continuous, corresponding SID/Label Block. If a single SID is 584 advertised then the range field MUST be set to one. For range 585 advertisements > 1, the number of addresses that need to be mapped 586 into a Prefix-SID and the starting value of the Prefix-SID range. 588 Example 1: if the following router addresses (loopback addresses) 589 need to be mapped into the corresponding Prefix SID indexes. 591 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 592 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 593 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 594 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Length |0|0| | Weight | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Range = 4 | /32 | 192 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | .0 | .2 | .1 | Sub-TLV Type | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Sub-TLV Length| 1 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Example-2: If the following prefixes need to be mapped into the 609 corresponding Prefix-SID indexes: 611 10.1.1/24, Prefix-SID: Index 51 612 10.1.2/24, Prefix-SID: Index 52 613 10.1.3/24, Prefix-SID: Index 53 614 10.1.4/24, Prefix-SID: Index 54 615 10.1.5/24, Prefix-SID: Index 55 616 10.1.6/24, Prefix-SID: Index 56 617 10.1.7/24, Prefix-SID: Index 57 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length |0|0| | Weight | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Range = 7 | /24 | 10 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | .1 | .1 | Sub-TLV Type | Sub-TLV Length| 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | 51 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 It is not expected that a network operator will be able to keep fully 632 continuous FEC Prefix / SID/Index mappings. In order to support 633 noncontinuous mapping ranges an implementation MAY generate several 634 instances of Binding TLVs. 636 For example if a router wants to advertise the following ranges: 638 Range 16: { 192.168.1.1-15, Index 1-15 } 640 Range 6: { 192.168.1.22-27, Index 22-27 } 642 Range 41: { 192.168.1.44-84, Index 80-120 } 644 A router would need to advertise three instances of the Binding TLV. 646 2.4.4. Prefix Length, Prefix 648 The 'FEC Prefix' represents the Forwarding equivalence class at the 649 tail-end of the advertised path. The 'FEC Prefix' does not need to 650 correspond to a routable prefix of the originating node. 652 The 'Prefix Length' field contains the length of the prefix in bits. 653 Only the most significant octets of the Prefix FEC are encoded. I.e. 654 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 655 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 656 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 657 prefix length 113 up to 128. 659 2.4.5. SID/Label Sub-TLV 661 The SID/Label Sub-TLV (Type: TBD, suggested value 1) contains the SID 662 /Label value as defined in Section 2.1. It MUST be present in every 663 SID/Label Binding TLV. 665 2.4.6. ERO Metric sub-TLV 667 ERO Metric sub-TLV (Type: TBD, suggested value 2) is a Sub-TLV of the 668 SID/Label Binding TLV. 670 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 671 to compare the cost of a given source/destination path. A router MAY 672 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 673 SHOULD be set to the cumulative IGP or TE path cost of the advertised 674 ERO. Since manipulation of the Metric field may attract or distract 675 traffic from and to the advertised segment it MAY be manually 676 overridden. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Length | Metric | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Metric (continued) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 ERO Metric sub-TLV format 688 where: 690 Type: TBD, suggested value 2 692 Length: 4 694 Metric: 4 bytes 696 2.4.7. IPv4 ERO subTLV 698 The IPv4 ERO subTLV (Type: TBD, suggested value 3) describes a path 699 segment using IPv4 address style of encoding. Its semantics have 700 been borrowed from [RFC3209]. 702 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 703 set, then the value of the attribute is 'loose.' Otherwise, the 704 value of the attribute is 'strict.' 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type | Length |L| Reserved | IPv4 address | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | IPv4 address (continued) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 2: IPv4 ERO subTLV format 716 2.4.8. IPv6 ERO subTLV 718 The IPv6 ERO subTLV (Type: TBD, suggested value 4) describes a path 719 segment using IPv6 Address style of encoding. Its semantics have 720 been borrowed from [RFC3209]. 722 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 723 set, then the value of the attribute is 'loose.' Otherwise, the 724 value of the attribute is 'strict.' 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length |L| Reserved | IPv6 address | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | IPv6 Address (continued) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | IPv6 Address (continued) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | IPv6 Address (continued) | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | IPv6 Address (continued) | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 3: IPv6 ERO subTLV format 742 2.4.9. Unnumbered Interface ID ERO subTLV 744 The appearance and semantics of the 'Unnumbered Interface ID' have 745 been borrowed from Section 4 [RFC3477]. 747 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 5) 748 describes a path segment that spans over an unnumbered interface. 749 Unnumbered interfaces are referenced using the interface index. 751 Interface indices are assigned local to the router and therefore not 752 unique within a domain. All elements in an ERO path need to be 753 unique within a domain and hence need to be disambiguated using a 754 domain unique Router-ID. 756 The 'Router-ID' field contains the router ID of the router which has 757 assigned the 'Interface ID' field. Its purpose is to disambiguate 758 the 'Interface ID' field from other routers in the domain. 760 IS-IS supports two Router-ID formats: 762 o (TLV 134, 32-Bit format) [RFC5305] 764 o (TLV 140, 128-Bit format) [RFC6119] 766 The actual Router-ID format gets derived from the 'Length' field. 768 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 770 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 772 The 'Interface ID' is the identifier assigned to the link by the 773 router specified by the router ID. 775 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 776 set, then the value of the attribute is 'loose.' Otherwise, the 777 value of the attribute is 'strict.' 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type | Length |L| Reserved | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 // Router ID (32 or 128 bits) // 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Interface ID (32 bits) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 4: Unnumbered Interface ID ERO subTLV format 791 2.4.10. IPv4 Backup ERO subTLV 793 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 6) describes a 794 Backup path segment using IPv4 Address style of encoding. Its 795 appearance and semantics have been borrowed from [RFC3209]. 797 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 798 set, then the value of the attribute is 'loose.' Otherwise, the 799 value of the attribute is 'strict.' 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type | Length |L| Reserved | IPv4 address | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | IPv4 address (continued) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 5: IPv4 Backup ERO subTLV format 811 2.4.11. IPv6 Backup ERO subTLV 813 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 7) describes a 814 Backup path segment using IPv6 Address style of encoding. Its 815 appearance and semantics have been borrowed from [RFC3209]. 817 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 818 set, then the value of the attribute is 'loose.' Otherwise, the 819 value of the attribute is 'strict.' 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Type | Length |L| Reserved | IPv6 address | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | IPv6 Address (continued) | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | IPv6 Address (continued) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | IPv6 Address (continued) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | IPv6 Address (continued) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Figure 6: IPv6 Backup ERO subTLV format 837 2.4.12. Unnumbered Interface ID Backup ERO subTLV 839 The appearance and semantics of the 'Unnumbered Interface ID' have 840 been borrowed from Section 4 [RFC3477]. 842 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 843 value 8) describes a Backup LSP path segment that spans over an 844 unnumbered interface. Unnumbered interfaces are referenced using the 845 interface index. Interface indices are assigned local to the router 846 and therefore not unique within a domain. All elements in an ERO 847 path need to be unique within a domain and hence need to be 848 disambiguated using a domain unique Router-ID. 850 The 'Router-ID' field contains the router ID of the router which has 851 assigned the 'Interface ID' field. Its purpose is to disambiguate 852 the 'Interface ID' field from other routers in the domain. 854 IS-IS supports two Router-ID formats: 856 o (TLV 134, 32-Bit format) [RFC5305] 858 o (TLV 140, 128-Bit format) [RFC6119] 860 The actual Router-ID format gets derived from the 'Length' field. 862 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 864 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 866 The 'Interface ID' is the identifier assigned to the link by the 867 router specified by the router ID. 869 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 870 set, then the value of the attribute is 'loose.' Otherwise, the 871 value of the attribute is 'strict.' 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Type | Length |L| Reserved | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 // Router ID (32 or 128 bits) // 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Interface ID (32 bits) | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 885 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path semantics 887 All 'ERO' and 'Backup ERO' information represents an ordered set 888 which describes the segments of a path. The last ERO subTLV 889 describes the segment closest to the egress point of the path. 890 Contrary the first ERO subTLV describes the first segment of a path. 891 If a router extends or stitches a label switched path it MUST prepend 892 the new segments path information to the ERO list. The same ordering 893 applies for the Backup ERO labels. An implementation SHOULD first 894 encode all primary path EROs followed by the bypass EROs. 896 3. Router Capabilities 898 3.1. SR-Capabilities Sub-TLV 900 Segment Routing requires each router to advertise its SR data-plane 901 capability and the range of SID/Label values it uses for Segment 902 Routing. Data-plane capabilities and SID/Label ranges are advertised 903 using the newly defined SR-Capabilities Sub-TLV inserted into the IS- 904 IS Router Capability TLV-242 that is defined in [RFC4971]. 906 The Router Capability TLV specifies flags that control its 907 advertisement. The SR Capabilities Sub-TLV MUST be propagated 908 throughout the level and need not to be advertised across level 909 boundaries. Therefore Router Capability TLV distribution flags MUST 910 be set accordingly, i.e.: the S flag MUST be unset. 912 The SR Capabilities Sub-TLV (Type: TBD, suggested value 2) is 913 optional, MAY appear multiple times inside the Router Capability TLV 914 and has following format: 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type | Length | Flags | Range | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Range (cont.) | SID/Label Sub-TLV (variable) | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 where: 926 Type: TBD, suggested value 2 928 Length: variable. 930 Flags: 1 octet of flags. The following are defined: 932 0 933 0 1 2 3 4 5 6 7 934 +-+-+-+-+-+-+-+-+ 935 |I|V| | 936 +-+-+-+-+-+-+-+-+ 938 where: 940 I-Flag: IPv4 flag. If set, then the router is capable of 941 outgoing IPv4 encapsulation on all interfaces. 943 V-Flag: IPv6 flag. If set, then the router is capable of 944 outgoing IPv6 encapsulation on all interfaces. 946 Range: 3 octets value defining the number of values of the range 947 from the starting value defined in the SID/Label Sub-TLV. 949 SID/Label Sub-TLV: SID/Label value as defined in Section 2.1. 951 Multiple occurrence of the SR-Capabilities Sub-TLV MAY be advertised, 952 in order to advertise multiple ranges. In such case: 954 o Only the Flags in the first occurrence of the Sub-TLV are to be 955 taken into account. 957 o The originating router MUST encode ranges each into a different 958 SR-Capability Sub-TLV and all SR-Capability TLVs MUST be encoded 959 within the same LSP fragment. 961 o The order of the ranges (i.e.: SR-Capability Sub-TLVs) in the LSP 962 fragment is decided by the originating router and hence the 963 receiving routers MUST NOT re-order the received ranges. This is 964 required for avoiding label churn when for example a numerical 965 lower Segment/Label Block gets added to an already advertised 966 Segment/Label Block. 968 o The originating router decides the order of the set of originated 969 SR-Capability Sub-TLV (sorted or not). In all cases, the 970 originating router MUST ensure the order is same after a graceful 971 restart (using checkpointing, non-volatile storage or any other 972 mechanism) in order to guarantee the same order before and after 973 GR. 975 Here follows an example of advertisement of multiple ranges: 977 The originating router advertises following ranges: 978 Range 1: [100, 199] 979 Range 2: [1000, 1099] 980 Range 3: [500, 599] 982 The receiving routers concatenate the ranges and build the SRGB 983 is as follows: 985 SRGB = [100, 199] 986 [1000, 1099] 987 [500, 599] 989 The indexes span multiple ranges: 991 index=0 means label 100 992 ... 993 index 99 means label 199 994 index 100 means label 1000 995 index 199 means label 1099 996 ... 997 index 200 means label 500 998 ... 1000 3.2. SR-Algorithm Sub-TLV 1002 The router may use various algorithms when calculating reachability 1003 to other nodes or to prefixes attached to these nodes. Examples of 1004 these algorithms are metric based Shortest Path First (SPF), various 1005 sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV (Type: TBD, 1006 suggested value 19) allows the router to advertise the algorithms 1007 that the router is currently using. The following value has been 1008 defined: 1010 0: Shortest Path First (SPF) algorithm based on link metric. 1012 The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability 1013 TLV-242 that is defined in [RFC4971]. 1015 The Router Capability TLV specifies flags that control its 1016 advertisement. The SR-Algorithm MUST be propagated throughout the 1017 level and need not to be advertised across level boundaries. 1018 Therefore Router Capability TLV distribution flags MUST be set 1019 accordingly, i.e.: the S flag MUST be unset. 1021 The SR-Algorithm Sub-TLV is optional, it MAY only appear a single 1022 time inside the Router Capability TLV. If the SID-Label Capability 1023 Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be 1024 advertised. 1026 It has following format: 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type | Length | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 where: 1038 Type: TBD, suggested value 19 1040 Length: variable. 1042 Algorithm: 1 octet of algorithm Section 2.2 1044 4. IANA Considerations 1046 This documents request allocation for the following TLVs and subTLVs. 1048 4.1. Sub TLVs for Type 22,23,222 and 223 1050 This document makes the following registrations in the "Sub-TLVs for 1051 TLV 22, 23, 222 and 223" registry. 1053 Type: TBD (suggested value 31) 1055 Description: Adjacency Segment Identifier 1057 TLV 22: yes 1059 TLV 23: yes 1061 TLV 222: yes 1063 TLV 223: yes 1065 Reference: This document (Section 2.3.1) 1067 Type: TBD (suggested value 32) 1069 Description: LAN Adjacency Segment Identifier 1070 TLV 22: yes 1072 TLV 23: yes 1074 TLV 222: yes 1076 TLV 223: yes 1078 Reference: This document (Section 2.3.2) 1080 4.2. Sub TLVs for Type 135,235,236 and 237 1082 This document makes the following registrations in the "Sub-TLVs for 1083 TLV 135,235,236 and 237" registry. 1085 Type: TBD (suggested value 3) 1087 Description: Prefix Segment Identifier 1089 TLV 135: yes 1091 TLV 235: yes 1093 TLV 236: yes 1095 TLV 237: yes 1097 Reference: This document (Section 2.2) 1099 4.3. Sub TLVs for Type 242 1101 This document makes the following registrations in the "Sub-TLVs for 1102 TLV 242" registry. 1104 Type: TBD (suggested value 2) 1106 Description: Segment Routing Capability 1108 Reference: This document (Section 3.1) 1110 Type: TBD (suggested value 19) 1112 Description: Segment Routing Algorithm 1113 Reference: This document (Section 3.2) 1115 4.4. New TLV Codepoint and Sub-TLV registry 1117 This document registers the following TLV: 1119 Type: TBD (suggested value 149) 1121 name: Segment Identifier / Label Binding 1123 IIH: no 1125 LSP: yes 1127 SNP: no 1129 Purge: no 1131 Reference: This document (Section 2.4) 1133 This document creates the following Sub-TLV Registry: 1135 Registry: Sub-TLVs for TLV 149 1137 Registration Procedure: Expert review 1139 Reference: This document (Section 2.4) 1141 Type: TBD, suggested value 1 1143 Description: SID/Label 1145 Reference: This document (Section 2.1) 1147 Type: TBD, suggested value 2 1149 Description: ERO Metric 1151 Reference: This document (Section 2.4.6) 1153 Type: TBD, suggested value 3 1154 Description: IPv4 ERO 1156 Reference: This document (Section 2.4.7) 1158 Type: TBD, suggested value 4 1160 Description: IPv6 ERO 1162 Reference: This document (Section 2.4.8) 1164 Type: TBD, suggested value 5 1166 Description: Unnumbered Interface-ID ERO 1168 Reference: This document (Section 2.4.9) 1170 Type: TBD, suggested value 6 1172 Description: IPv4 Backup ERO 1174 Reference: This document (Section 2.4.10) 1176 Type: TBD, suggested value 7 1178 Description: IPv6 Backup ERO 1180 Reference: This document (Section 2.4.11) 1182 Type: TBD, suggested value 8 1184 Description: Unnumbered Interface-ID Backup ERO 1186 Reference: This document (Section 2.4.12) 1188 5. Manageability Considerations 1190 TBD 1192 6. Security Considerations 1194 TBD 1196 7. Contributors 1198 The following people gave a substantial contribution to the content 1199 of this document: Martin Horneffer, Bruno Decraene, Igor Milojevic, 1200 Rob Shakir, Saku Ytti, Wim Henderickx, Les Ginsberg and Steven Luong. 1202 8. Acknowledgements 1204 We would like to thank Dave Ward, Dan Frost, Stewart Bryant and 1205 Pierre Francois for their contribution to the content of this 1206 document. 1208 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1209 earlier incarnations of the "Binding / MPLS Label TLV". 1211 9. References 1213 9.1. Normative References 1215 [ISO10589] 1216 International Organization for Standardization, 1217 "Intermediate system to Intermediate system intra-domain 1218 routeing information exchange protocol for use in 1219 conjunction with the protocol for providing the 1220 connectionless-mode Network Service (ISO 8473)", ISO/IEC 1221 10589:2002, Second Edition, Nov 2002. 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, March 1997. 1226 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1227 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1228 Tunnels", RFC 3209, December 2001. 1230 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1231 in Resource ReSerVation Protocol - Traffic Engineering 1232 (RSVP-TE)", RFC 3477, January 2003. 1234 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1235 System to Intermediate System (IS-IS) Extensions for 1236 Advertising Router Information", RFC 4971, July 2007. 1238 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1239 Topology (MT) Routing in Intermediate System to 1240 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1242 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1243 Engineering", RFC 5305, October 2008. 1245 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1246 2008. 1248 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1249 "Simplified Extension of Link State PDU (LSP) Space for 1250 IS-IS", RFC 5311, February 2009. 1252 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1253 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1254 Traffic Engineering", RFC 5316, December 2008. 1256 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1257 Engineering in IS-IS", RFC 6119, February 2011. 1259 9.2. Informative References 1261 [I-D.filsfils-rtgwg-segment-routing] 1262 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1263 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1264 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1265 "Segment Routing Architecture", draft-filsfils-rtgwg- 1266 segment-routing-01 (work in progress), October 2013. 1268 [I-D.filsfils-spring-segment-routing-use-cases] 1269 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1270 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1271 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1272 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1273 spring-segment-routing-use-cases-00 (work in progress), 1274 March 2014. 1276 Authors' Addresses 1277 Stefano Previdi (editor) 1278 Cisco Systems, Inc. 1279 Via Del Serafico, 200 1280 Rome 00142 1281 Italy 1283 Email: sprevidi@cisco.com 1285 Clarence Filsfils 1286 Cisco Systems, Inc. 1287 Brussels 1288 BE 1290 Email: cfilsfil@cisco.com 1292 Ahmed Bashandy 1293 Cisco Systems, Inc. 1294 170, West Tasman Drive 1295 San Jose, CA 95134 1296 US 1298 Email: bashandy@cisco.com 1300 Hannes Gredler 1301 Juniper Networks, Inc. 1302 1194 N. Mathilda Ave. 1303 Sunnyvale, CA 94089 1304 US 1306 Email: hannes@juniper.net 1308 Stephane Litkowski 1309 Orange 1310 FR 1312 Email: stephane.litkowski@orange.com 1313 Jeff Tantsura 1314 Ericsson 1315 300 Holger Way 1316 San Jose, CA 95134 1317 US 1319 Email: Jeff.Tantsura@ericsson.com