idnits 2.17.1 draft-previdi-isis-segment-routing-extensions-05.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 (February 13, 2014) is 3723 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) -- 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) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: August 17, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 Orange 10 J. Tantsura 11 Ericsson 12 February 13, 2014 14 IS-IS Extensions for Segment Routing 15 draft-previdi-isis-segment-routing-extensions-05 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 August 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 69 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . . 5 71 2.3. Adjacency Segment Identifier . . . . . . . . . . . . . . . 8 72 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . 9 73 2.3.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 74 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 12 75 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 76 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 13 78 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 79 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 15 80 2.4.6. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . . 16 81 2.4.7. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 82 2.4.8. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 17 83 2.4.9. Unnumbered Interface ID ERO subTLV . . . . . . . . . . 17 84 2.4.10. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . . 18 85 2.4.11. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . . 19 86 2.4.12. Unnumbered Interface ID Backup ERO subTLV . . . . . . 19 87 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path 88 semantics . . . . . . . . . . . . . . . . . . . . . . 20 89 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 21 90 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 21 91 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . . 22 92 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 5. Manageability Considerations . . . . . . . . . . . . . . . . . 24 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 Segment Routing (SR) allows for a flexible definition of end-to-end 105 paths within IGP topologies by encoding paths as sequences of 106 topological sub-paths, called "segments". These segments are 107 advertised by the link-state routing protocols (IS-IS and OSPF). Two 108 types of segments are defined, Prefix segments and Adjacency 109 segments. Prefix segments represent an ecmp-aware shortest-path to a 110 prefix, as per the state of the IGP topology. Adjacency segments 111 represent a hop over a specific adjacency between two nodes in the 112 IGP. A prefix segment is typically a multi-hop path while an 113 adjacency segment, in most of the cases, is a one-hop path. SR's 114 control-plane can be applied to both IPv6 and MPLS data-planes, and 115 do not require any additional signaling (other than the regular IGP). 116 For example, when used in MPLS networks, SR paths do not require any 117 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 118 of LSPs established with RSVP or LDP. 120 This draft describes the necessary IS-IS extensions that need to be 121 introduced for Segment Routing. 123 Segment Routing architecture is described in 124 [I-D.filsfils-rtgwg-segment-routing]. 126 Segment Routing use cases are described in 127 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 129 2. Segment Routing Identifiers 131 Segment Routing architecture ([I-D.filsfils-rtgwg-segment-routing]) 132 defines different types of Segment Identifiers (SID). This document 133 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 134 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 136 2.1. SID/Label Sub-TLV 138 The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this 139 document and contains a SID or a MPLS Label. The SID/Label Sub-TLV 140 has the following format: 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Type | Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | SID/Label (variable) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 where: 152 Type: 1 154 Length: variable (3 or 4) 156 SID/Label: if length is set to 3 then the 20 rightmost bits 157 represent a MPLS label. If length is 4 then the value represents 158 a 32 bits SID. 160 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) 162 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 163 (Prefix-SID Sub-TLV). 165 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as 166 defined in [I-D.filsfils-rtgwg-segment-routing]. The 'Prefix SID' 167 must be unique within a given IGP domain. The 'Prefix SID' is an 168 index to determine the actual SID/label value inside the set of all 169 advertised SID/label ranges of a given router. A receiving router 170 uses the index to determine the actual SID/label value in order to 171 construct forwarding state to a particular destination router. 173 In many use-cases a 'stable transport' IP Address is overloaded as an 174 identifier of a given node. Because the IP Prefixes may be re- 175 advertised into other levels there may be some ambiguity (e.g. 176 Originating router vs. L1L2 router) for which node a particular IP 177 prefix serves as identifier. The Prefix-SID Sub-TLV contains the 178 necessary flags to disambiguate IP Prefix to node mappings. 179 Furthermore if a given node has several 'stable transport' IP 180 addresses there are flags to differentiate those among other IP 181 Prefixes advertised from a given node. 183 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 184 and MAY be present in any of the following TLVs: 186 TLV-135 (IPv4) defined in [RFC5305]. 188 TLV-235 (MT-IPv4) defined in [RFC5120]. 190 TLV-236 (IPv6) defined in [RFC5308]. 192 TLV-237 (MT-IPv6) defined in [RFC5120]. 194 The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP 195 Reachability TLV gets propagated across level boundaries. 197 The Prefix-SID Sub-TLV has the following format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Flags | Algorithm | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | SID/Index | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 where: 209 Type: 3 211 Length: variable. 213 Flags: 1 octet field of following flags: 215 0 1 2 3 4 5 6 7 216 +-+-+-+-+-+-+-+-+ 217 |R|N|P| | 218 +-+-+-+-+-+-+-+-+ 220 where: 222 R-Flag: Re-advertisement flag. If set, then the prefix to 223 which this Prefix-SID is attached, has been propagated by the 224 router either from another level (i.e.: from level-1 to level-2 225 or the opposite) or from redistribution (e.g.: from another 226 protocol). 228 N-Flag: Node-SID flag. Optional and, if set, then the Prefix- 229 SID refers to the router identified by the prefix. Typically, 230 the N-Flag is set on Prefix-SIDs attached to a router loopback 231 address. The N-Flag is set when the Prefix-SID is a Node-SID 232 as described in [I-D.filsfils-rtgwg-segment-routing]. 234 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 235 pop the Prefix-SID before delivering the packet to the node 236 that advertised the Prefix-SID. 238 Other bits: MUST be zero when originated and ignored when 239 received. 241 Algorithm: the router may use various algorithms when calculating 242 reachability to other nodes or to prefixes attached to these 243 nodes. Examples of these algorithms are metric based Shortest 244 Path First (SPF), various sorts of Constrained SPF, etc. The 245 Algorithm field allows a router to advertise algorithms that 246 router is currently using. SR-Algorithm TLV has following 247 structure: one octet identifying the algorithm to which the 248 Prefix-SID is associated. Currently, the following value has been 249 defined: 251 0: Shortest Path First (SPF) algorithm based on link metric. 253 Definitions and use of algorithms in Segment Routing are 254 described in [I-D.filsfils-rtgwg-segment-routing] 256 SID/Index: 32 bit index defining the offset in the SID/Label space 257 advertised by this router using the encodings defined in 258 Section 3.1. 260 Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which 261 case each SID is encoded as a separate Sub-TLV. When multiple 262 Prefix-SID Sub-TLVs are present, the receiving router MUST use the 263 first encoded SID and MAY use the subsequent ones. 265 The No-PHP flag MUST be set on the Prefix-SIDs associated with 266 reachability advertisements which were originated by other routers 267 and leaked (either from Level-1 to Level-2 or vice versa). 269 The R-Flag MUST be set for prefixes that are not local to the router 270 and either: 272 advertised because of propagation (Level-1 into Level-2); 274 advertised because of leaking (Level-2 into Level-1); 276 advertised because redistribution (e.g.: from another protocol). 278 In the case where a Level-1-2 router has local interface addresses 279 configured in one level, it may also propagate these addresses into 280 the other level. In such case, the Level-1-2 router MUST NOT set the 281 R bit. The R-bit MUST be set only for prefixes that are not local to 282 the router and advertised by the router because of propagation and/or 283 leaking. 285 The N-Flag is used in order to define a Node-SID. A router MAY set 286 the N-Flag only if all of the following conditions are met: 288 The prefix to which the Prefix-SID is attached is local to the 289 router. I.e.: the prefix is configured on one of the local 290 interfaces. (e.g.: 'stable transport' loopback). 292 The prefix to which the Prefix-SID is attached MUST have a Prefix 293 length of either /32 (IPv4) or /128 (IPv6). 295 The router MUST ignore the N-Flag on a received Prefix-SID if the 296 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 298 The router behavior determined by the P, R and N flags are described 299 in [I-D.filsfils-rtgwg-segment-routing]. 301 2.3. Adjacency Segment Identifier 303 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 304 TLV (Adj-SID Sub-TLV). 306 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 307 Routing IGP-Adjacency-SID as defined in 308 [I-D.filsfils-rtgwg-segment-routing] with flags and fields that may 309 be used, in future extensions of Segment Routing, for carrying other 310 types of SIDs. 312 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 313 below: 315 TLV-22 [RFC5305] 317 TLV-222 [RFC5120] 319 TLV-23 [RFC5311] 321 TLV-223 [RFC5311] 323 TLV-141 [RFC5316] 325 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 326 neighbor. Examples where more than one Adj-SID may be used per IS- 327 neighbor are described in 328 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 330 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 332 The following format is defined for the Adj-SID Sub-TLV: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | Flags | Weight | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | SID/Label Sub-TLV (variable) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 where: 344 Type: 31 346 Length: variable. 348 Flags: 1 octet field of following flags: 350 0 1 2 3 4 5 6 7 351 +-+-+-+-+-+-+-+ 352 |F|B| | 353 +-+-+-+-+-+-+-+ 355 where: 357 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 358 to an adjacency with outgoing IPv4 encapsulation. If set then 359 the Adj-SID refers to an adjacency with outgoing IPv6 360 encapsulation. 362 B-Flag: Backup flag. If set, the Adj-SID refers to an 363 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 364 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 366 Other bits: MUST be zero when originated and ignored when 367 received. 369 Weight: 1 octet. The value represents the weight of the Adj-SID 370 for the purpose of load balancing. The use of the weight is 371 defined in [I-D.filsfils-rtgwg-segment-routing]. 373 SID/Label Sub-TLV: contains the SID/Label value as defined in 374 Section 2.1. 376 An SR capable router MAY allocate an Adj-SID for each of its 377 adjacencies and SHOULD set the B-Flag when the adjacency is 378 protected by a FRR mechanism (IP or MPLS) as described in 379 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 381 The F-flag is used in order for the router to advertise the 382 outgoing encapsulation of the adjacency the Adj-SID is attached 383 to. Use cases of the use of the F-flag are described in 384 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 386 2.3.2. Adjacency Segment Identifiers in LANs 388 In LAN subnetworks, the Designated Intermediate System (DIS) is 389 elected and originates the Pseudonode-LSP (PN-LSP) including all 390 neighbors of the DIS. 392 When Segment Routing is used, each router in the LAN MAY advertise 393 the Adj-SID of each of its neighbors. Since, on LANs, each router 394 only advertises one adjacency to the DIS (and doesn't advertise any 395 other adjacency), each router advertises the set of Adj-SIDs (for 396 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 397 advertising the adjacency to the DIS (e.g.: TLV-22). 399 The following new Sub-TLV is defined: LAN-Adj-SID (Type 32) 400 containing the set of Adj-SIDs the router assigned to each of its LAN 401 neighbors. 403 The format of the LAN-Adj-SID Sub-TLV is as follows: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type | Length | Flags | Weight | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | System-ID (6 octets) | 413 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | SID/Label Sub-TLV (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 423 Type: 32 425 Length: variable. 427 Flags: 1 octet field of following flags: 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+ 431 |F|B| | 432 +-+-+-+-+-+-+-+ 434 where: 436 F-Flag: Address Family flag. If unset, then the Adj-SID refers 437 to an adjacency with outgoing IPv4 encapsulation. If set then 438 the Adj-SID refers to an adjacency with outgoing IPv6 439 encapsulation. 441 B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an 442 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 443 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 445 Other bits: MUST be zero when originated and ignored when 446 received. 448 Weight: 1 octet. The value represents the weight of the Adj-SID 449 for the purpose of load balancing. The use of the weight is 450 defined in [I-D.filsfils-rtgwg-segment-routing]. 452 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 453 defined in [ISO10589]. 455 SID/Label Sub-TLV: contains the SID/Label value as defined in 456 Section 2.1. 458 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 460 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 461 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 462 advertisements of the adjacency to the DIS MUST be used, MUST have 463 the same metric and SHOULD be inserted within the same LSP fragment. 465 Each router within the level, by receiving the DIS PN LSP as well as 466 the non-PN LSP of each router in the LAN, is capable of 467 reconstructing the LAN topology as well as the set of Adj-SID each 468 router uses for each of its neighbors. 470 2.4. SID/Label Binding TLV 472 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 473 domain. The router may advertise a SID/Label binding to a FEC along 474 with at least a single 'nexthop style' anchor. The protocol supports 475 more than one 'nexthop style' anchor to be attached to a SID/Label 476 binding, which results into a simple path description language. In 477 analogy to RSVP the terminology for this is called an 'Explicit Route 478 Object' (ERO). Since ERO style path notation allows to anchor SID/ 479 label bindings to to both link and node IP addresses any label 480 switched path, can be described. Furthermore also SID/Label Bindings 481 from external protocols can get easily re-advertised. 483 The SID/Label Binding TLV may be used for advertising SID/Label 484 Bindings and their associated Primary and Backup paths. In one 485 single TLV either a primary ERO Path, a backup ERO Path or both are 486 advertised. If a router wants to advertise multiple parallel paths 487 then it can generate several TLVs for the same Prefix/FEC. Each 488 occurrence of a Binding TLV with respect with a given FEC Prefix has 489 accumulating and not canceling semantics. Due the space constraints 490 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 491 ERO path in one SID/Label Binding TLV and the backup ERO path in a 492 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 493 Sub-TLV MUST be identical in both TLVs. 495 The SID/Label Binding TLV has type 149 and has the following format: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type | Length | Flags | Weight | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Range | Prefix Length | FEC Prefix | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 // FEC Prefix (continued, variable) // 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | SubTLVs (variable) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 1: SID/Label Binding TLV format 511 o Type: 149 513 o Length: variable. 515 o 1 octet of flags 516 o 1 octet of Weight 518 o 2 octets of Range 520 o 1 octet of Prefix Length 522 o 0-16 octets of FEC Prefix 524 o sub-TLVs, where each sub-TLV consists of a sequence of: 526 * 1 octet of sub-TLV type 528 * 1 octet of length of the value field of the sub-TLV 530 * 0-243 octets of value 532 2.4.1. Flags 534 Flags: 1 octet field of following flags: 536 0 1 2 3 4 5 6 7 537 +-+-+-+-+-+-+-+-+ 538 |F|M| | 539 +-+-+-+-+-+-+-+-+ 541 where: 543 F-Flag: Address Family flag. If unset, then the Prefix FEC 544 carries an IPv4 Prefix. If set then the Prefix FEC carries an 545 IPv6 Prefix. 547 M-Flag: Mirror Context flag. Set if the advertised SID/path 548 corresponds to a mirrored context. The use of the M flag is 549 described in [I-D.filsfils-rtgwg-segment-routing]. 551 Other bits: MUST be zero when originated and ignored when 552 received. 554 2.4.2. Weight 556 Weight: 1 octet: The value represents the weight of the path for the 557 purpose of load balancing. The use of the weight is defined in 558 [I-D.filsfils-rtgwg-segment-routing]. 560 2.4.3. Range 562 The 'Range' field provides the ability to specify a range of 563 addresses and their associated Prefix SIDs. It is essentially a 564 compression scheme to distribute a continuous Prefix and their 565 continuous, corresponding SID/Label Block. If a single SID is 566 advertised then the range field MUST be set to one. For range 567 advertisements > 1, the number of addresses that need to be mapped 568 into a Prefix-SID and the starting value of the Prefix-SID range. 570 Example 1: if the following router addresses (loopback addresses) 571 need to be mapped into the corresponding Prefix SID indexes. 573 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 574 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 575 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 576 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type | Length |0|0| | Weight | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Range = 4 | /32 | 192 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | .0 | .2 | .1 | Sub-TLV Type | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Sub-TLV Length| 1 | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 Example-2: If the following prefixes need to be mapped into the 591 corresponding Prefix-SID indexes: 593 10.1.1/24, Prefix-SID: Index 51 594 10.1.2/24, Prefix-SID: Index 52 595 10.1.3/24, Prefix-SID: Index 53 596 10.1.4/24, Prefix-SID: Index 54 597 10.1.5/24, Prefix-SID: Index 55 598 10.1.6/24, Prefix-SID: Index 56 599 10.1.7/24, Prefix-SID: Index 57 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length |0|0| | Weight | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Range = 7 | /24 | 10 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | .1 | .1 | Sub-TLV Type | Sub-TLV Length| 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | 51 | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 It is not expected that a network operator will be able to keep fully 613 continuous FEC Prefix / SID/Index mappings. In order to support 614 noncontinuous mapping ranges an implementation MAY generate several 615 instances of Binding TLVs. 617 For example if a router wants to advertise the following ranges: 619 Range 16: { 192.168.1.1-15, Index 1-15 } 621 Range 6: { 192.168.1.22-27, Index 22-27 } 623 Range 41: { 192.168.1.44-84, Index 80-120 } 625 A router would need to advertise three instances of the Binding TLV. 627 2.4.4. Prefix Length, Prefix 629 The 'FEC Prefix' represents the Forwarding equivalence class at the 630 tail-end of the advertised path. The 'FEC Prefix' does not need to 631 correspond to a routable prefix of the originating node. 633 The 'Prefix Length' field contains the length of the prefix in bits. 634 Only the most significant octets of the Prefix FEC are encoded. I.e. 635 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 636 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 637 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 638 prefix length 113 up to 128. 640 2.4.5. SID/Label Sub-TLV 642 The SID/Label Sub-TLV (Type 1) contains the SID/Label value as 643 defined in Section 2.1. It MUST be present in every SID/Label 644 Binding TLV. 646 2.4.6. ERO Metric sub-TLV 648 ERO Metric sub-TLV (Type 2) is a Sub-TLV of the SID/Label Binding 649 TLV. 651 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 652 to compare the cost of a given source/destination path. A router MAY 653 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 654 SHOULD be set to the cumulative IGP or TE path cost of the advertised 655 ERO. Since manipulation of the Metric field may attract or distract 656 traffic from and to the advertised segment it MAY be manually 657 overridden. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type | Length | Metric | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Metric (continued) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 ERO Metric sub-TLV format 669 where: 671 Type: 2 673 Length: 4 675 Metric: 4 bytes 677 2.4.7. IPv4 ERO subTLV 679 The IPv4 ERO subTLV (Type 3) describes a path segment using IPv4 680 address style of encoding. Its semantics have been borrowed from 681 [RFC3209]. 683 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 684 set, then the value of the attribute is 'loose.' Otherwise, the 685 value of the attribute is 'strict.' 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type | Length |L| Reserved | IPv4 address | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | IPv4 address (continued) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 2: IPv4 ERO subTLV format 696 2.4.8. IPv6 ERO subTLV 698 The IPv6 ERO subTLV (Type 4) describes a path segment using IPv6 699 Address style of encoding. Its semantics have been borrowed from 700 [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 | IPv6 address | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | IPv6 Address (continued) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | IPv6 Address (continued) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | IPv6 Address (continued) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | IPv6 Address (continued) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure 3: IPv6 ERO subTLV format 722 2.4.9. Unnumbered Interface ID ERO subTLV 724 The appearance and semantics of the 'Unnumbered Interface ID' have 725 been borrowed from Section 4 [RFC3477]. 727 The Unnumbered Interface-ID ERO subTLV (Type 5) describes a path 728 segment that spans over an unnumbered interface. Unnumbered 729 interfaces are referenced using the interface index. Interface 730 indices are assigned local to the router and therefore not unique 731 within a domain. All elements in an ERO path need to be unique 732 within a domain and hence need to be disambiguated using a domain 733 unique Router-ID. 735 The 'Router-ID' field contains the router ID of the router which has 736 assigned the 'Interface ID' field. Its purpose is to disambiguate 737 the 'Interface ID' field from other routers in the domain. 739 IS-IS supports two Router-ID formats: 741 o (TLV 134, 32-Bit format) [RFC5305] 743 o (TLV 140, 128-Bit format) [RFC6119] 745 The actual Router-ID format gets derived from the 'Length' field. 747 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 749 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 751 The 'Interface ID' is the identifier assigned to the link by the 752 router specified by the router ID. 754 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 755 set, then the value of the attribute is 'loose.' Otherwise, the 756 value of the attribute is 'strict.' 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Length |L| Reserved | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 // Router ID (32 or 128 bits) // 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Interface ID (32 bits) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Figure 4: Unnumbered Interface ID ERO subTLV format 770 2.4.10. IPv4 Backup ERO subTLV 772 The IPv4 Backup ERO subTLV (Type 6) describes a Backup path segment 773 using IPv4 Address style of encoding. Its appearance and semantics 774 have been borrowed from [RFC3209]. 776 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 777 set, then the value of the attribute is 'loose.' Otherwise, the 778 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 | IPv4 address | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | IPv4 address (continued) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 5: IPv4 Backup ERO subTLV format 789 2.4.11. IPv6 Backup ERO subTLV 791 The IPv6 Backup ERO subTLV (Type 7) describes a Backup path segment 792 using IPv6 Address style of encoding. Its appearance and semantics 793 have been borrowed from [RFC3209]. 795 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 796 set, then the value of the attribute is 'loose.' Otherwise, the 797 value of the attribute is 'strict.' 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length |L| Reserved | IPv6 address | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | IPv6 Address (continued) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | IPv6 Address (continued) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | IPv6 Address (continued) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | IPv6 Address (continued) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 6: IPv6 Backup ERO subTLV format 815 2.4.12. Unnumbered Interface ID Backup ERO subTLV 817 The appearance and semantics of the 'Unnumbered Interface ID' have 818 been borrowed from Section 4 [RFC3477]. 820 The Unnumbered Interface-ID Backup ERO subTLV (Type 8) describes a 821 Backup LSP path segment that spans over an unnumbered interface. 822 Unnumbered interfaces are referenced using the interface index. 823 Interface indices are assigned local to the router and therefore not 824 unique within a domain. All elements in an ERO path need to be 825 unique within a domain and hence need to be disambiguated using a 826 domain unique Router-ID. 828 The 'Router-ID' field contains the router ID of the router which has 829 assigned the 'Interface ID' field. Its purpose is to disambiguate 830 the 'Interface ID' field from other routers in the domain. 832 IS-IS supports two Router-ID formats: 834 o (TLV 134, 32-Bit format) [RFC5305] 836 o (TLV 140, 128-Bit format) [RFC6119] 838 The actual Router-ID format gets derived from the 'Length' field. 840 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 842 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 844 The 'Interface ID' is the identifier assigned to the link by the 845 router specified by the router ID. 847 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 848 set, then the value of the attribute is 'loose.' Otherwise, the 849 value of the attribute is 'strict.' 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Type | Length |L| Reserved | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 // Router ID (32 or 128 bits) // 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Interface ID (32 bits) | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 863 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path semantics 865 All 'ERO' and 'Backup ERO' information represents an ordered set 866 which describes the segments of a path. The last ERO subTLV 867 describes the segment closest to the egress point of the path. 868 Contrary the first ERO subTLV describes the first segment of a path. 869 If a router extends or stitches a label switched path it MUST prepend 870 the new segments path information to the ERO list. The same ordering 871 applies for the Backup ERO labels. An implementation SHOULD first 872 encode all primary path EROs followed by the bypass EROs. 874 3. Router Capabilities 876 3.1. SR-Capabilities Sub-TLV 878 Segment Routing requires each router to advertise its SR data-plane 879 capability and the range of SID/Label values it uses for Segment 880 Routing. Data-plane capabilities and SID/Label ranges are advertised 881 using the newly defined SR-Capabilities Sub-TLV inserted into the 882 IS-IS Router Capability TLV-242 that is defined in [RFC4971]. 884 The Router Capability TLV specifies flags that control its 885 advertisement. The SR Capabilities Sub-TLV MUST be propagated 886 throughout the level and need not to be advertised across level 887 boundaries. Therefore Router Capability TLV distribution flags MUST 888 be set accordingly, i.e.: the S flag MUST be unset. 890 The SR Capabilities Sub-TLV (Type 2) is optional, MAY appear multiple 891 times inside the Router Capability TLV and has following format: 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Type | Length | Flags | Range | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Range (cont.) | SID/Label Sub-TLV (variable) | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 where: 903 Type: 2 905 Length: variable. 907 Flags: 1 octet of flags. The following are defined: 909 0 910 0 1 2 3 4 5 6 7 911 +-+-+-+-+-+-+-+-+ 912 |I|V| | 913 +-+-+-+-+-+-+-+-+ 915 where: 917 I-Flag: IPv4 flag. If set, then the router is capable of 918 outgoing IPv4 encapsulation on all interfaces. 920 V-Flag: IPv6 flag. If set, then the router is capable of 921 outgoing IPv6 encapsulation on all interfaces. 923 Range: 3 octets value defining the number of values of the range 924 from the starting value defined in the SID/Label Sub-TLV. 926 SID/Label Sub-TLV: SID/Label value as defined in Section 2.1. 928 If multiple occurrence of the SR-Capabilities Sub-TLV are advertised 929 by the same router, only the Flags in the first occurrence of the 930 Sub-TLV are to be taken into account. 932 3.2. SR-Algorithm Sub-TLV 934 The router may use various algorithms when calculating reachability 935 to other nodes or to prefixes attached to these nodes. Examples of 936 these algorithms are metric based Shortest Path First (SPF), various 937 sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV (Type 15) 938 allows the router to advertise the algorithms that the router is 939 currently using. The following value has been defined: 941 0: Shortest Path First (SPF) algorithm based on link metric. 943 The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability 944 TLV-242 that is defined in [RFC4971]. 946 The Router Capability TLV specifies flags that control its 947 advertisement. The SR-Algorithm MUST be propagated throughout the 948 level and need not to be advertised across level boundaries. 949 Therefore Router Capability TLV distribution flags MUST be set 950 accordingly, i.e.: the S flag MUST be unset. 952 The SR-Algorithm Sub-TLV is optional, it MAY only appear a single 953 time inside the Router Capability TLV. If the SID-Label Capability 954 Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be 955 advertised. 957 It has following format: 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 where: 969 Type: 15 971 Length: variable. 973 Algorithm: 1 octet of algorithm Section 2.2 975 4. IANA Considerations 977 This documents request allocation for the following TLVs and subTLVs. 979 +-----+--------------+-------------+---------+---------+------------+ 980 | PDU | TLV | subTLV | Type | subType | #Occurence | 981 +-----+--------------+-------------+---------+---------+------------+ 982 | LSP | IS Neighbor | | 22, 23, | | >=0 | 983 | | | | 222, | | | 984 | | | | 223 | | | 985 | | | SID/Label | | 31 | >0 | 986 | | | LAN | | 32 | >0 | 987 | | | SID/Label | | | | 988 | LSP | IP | | 135, | | >=0 | 989 | | reachability | | 235, | | | 990 | | | | 236, | | | 991 | | | | 237 | | | 992 | | | SID/Label | | 3 | >0 | 993 | LSP | SID/MPLS | | 149 | | >=0 | 994 | | Binding | | | | | 995 | | | SID/Label | | 1 | >0 | 996 | | | ERO Metric | | 2 | 1 | 997 | | | IPv4 ERO | | 3 | >=0 | 998 | | | IPv6 ERO | | 4 | >=0 | 999 | | | Unnumbered | | 5 | >=0 | 1000 | | | Interface | | | | 1001 | | | ID ERO | | | | 1002 | | | IPv4 Backup | | 6 | >=0 | 1003 | | | ERO | | | | 1004 | | | IPv6 Backup | | 7 | >=0 | 1005 | | | ERO | | | | 1006 | | | Unnumbered | | 8 | >=0 | 1007 | | | Interface | | | | 1008 | | | ID Backup | | | | 1009 | | | ERO | | | | 1010 | LSP | Router | | 242 | | >=0 | 1011 | | Capability | | | | | 1012 | | | SR | | 2 | >=0 | 1013 | | | Capability | | | | 1014 | | | SR | | 15 | 1 | 1015 | | | Algorithm | | | | 1016 +-----+--------------+-------------+---------+---------+------------+ 1018 Table 1: IANA allocations 1020 The SID/MPLS Binding TLV requires a new sub-registry. Type value 149 1021 has been assigned, with a starting sub-TLV value of 1, range from 1022 1-255, and managed by Expert Review. 1024 5. Manageability Considerations 1026 TBD 1028 6. Security Considerations 1030 TBD 1032 7. Contributors 1034 The following people gave a substantial contribution to the content 1035 of this document: Martin Horneffer, Bruno Decraene, Igor Milojevic, 1036 Rob Shakir, Saku Ytti, Wim Henderickx, Jeff Tantsura, Les Ginsberg 1037 and Steven Luong. 1039 8. Acknowledgements 1041 We would like to thank Dave Ward, Dan Frost, Stewart Bryant and 1042 Pierre Francois for their contribution to the content of this 1043 document. 1045 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1046 earlier incarnations of the "Binding / MPLS Label TLV" in 1047 [I-D.gredler-isis-label-advertisement]. 1049 9. References 1051 9.1. Normative References 1053 [ISO10589] 1054 International Organization for Standardization, 1055 "Intermediate system to Intermediate system intra-domain 1056 routeing information exchange protocol for use in 1057 conjunction with the protocol for providing the 1058 connectionless-mode Network Service (ISO 8473)", ISO/ 1059 IEC 10589:2002, Second Edition, Nov 2002. 1061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1062 Requirement Levels", BCP 14, RFC 2119, March 1997. 1064 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1065 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1066 Tunnels", RFC 3209, December 2001. 1068 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1069 in Resource ReSerVation Protocol - Traffic Engineering 1070 (RSVP-TE)", RFC 3477, January 2003. 1072 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1073 System to Intermediate System (IS-IS) Extensions for 1074 Advertising Router Information", RFC 4971, July 2007. 1076 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1077 Topology (MT) Routing in Intermediate System to 1078 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1080 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1081 Engineering", RFC 5305, October 2008. 1083 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1084 October 2008. 1086 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1087 "Simplified Extension of Link State PDU (LSP) Space for 1088 IS-IS", RFC 5311, February 2009. 1090 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1091 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1092 Traffic Engineering", RFC 5316, December 2008. 1094 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1095 Engineering in IS-IS", RFC 6119, February 2011. 1097 9.2. Informative References 1099 [I-D.filsfils-rtgwg-segment-routing] 1100 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1101 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1102 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1103 "Segment Routing Architecture", 1104 draft-filsfils-rtgwg-segment-routing-01 (work in 1105 progress), October 2013. 1107 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1108 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1109 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1110 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1111 Crabbe, "Segment Routing Use Cases", 1112 draft-filsfils-rtgwg-segment-routing-use-cases-02 (work in 1113 progress), October 2013. 1115 [I-D.gredler-isis-label-advertisement] 1116 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1117 "Advertising MPLS labels in IS-IS", 1118 draft-gredler-isis-label-advertisement-03 (work in 1119 progress), May 2013. 1121 Authors' Addresses 1123 Stefano Previdi (editor) 1124 Cisco Systems, Inc. 1125 Via Del Serafico, 200 1126 Rome 00142 1127 Italy 1129 Email: sprevidi@cisco.com 1131 Clarence Filsfils 1132 Cisco Systems, Inc. 1133 Brussels, 1134 BE 1136 Email: cfilsfil@cisco.com 1138 Ahmed Bashandy 1139 Cisco Systems, Inc. 1140 170, West Tasman Drive 1141 San Jose, CA 95134 1142 US 1144 Email: bashandy@cisco.com 1145 Hannes Gredler 1146 Juniper Networks, Inc. 1147 1194 N. Mathilda Ave. 1148 Sunnyvale, CA 94089 1149 US 1151 Email: hannes@juniper.net 1153 Stephane Litkowski 1154 Orange 1155 FR 1157 Email: stephane.litkowski@orange.com 1159 Jeff Tantsura 1160 Ericsson 1161 300 Holger Way 1162 San Jose, CA 95134 1163 US 1165 Email: Jeff.Tantsura@ericsson.com