idnits 2.17.1 draft-previdi-isis-segment-routing-extensions-04.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 (October 21, 2013) is 3812 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) == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 == Outdated reference: A later version (-02) exists of draft-filsfils-rtgwg-segment-routing-use-cases-01 Summary: 2 errors (**), 0 flaws (~~), 4 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: April 24, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 Orange 10 October 21, 2013 12 IS-IS Extensions for Segment Routing 13 draft-previdi-isis-segment-routing-extensions-04 15 Abstract 17 Segment Routing (SR) allows for a flexible definition of end-to-end 18 paths within IGP topologies by encoding paths as sequences of 19 topological sub-paths, called "segments". These segments are 20 advertised by the link-state routing protocols (IS-IS and OSPF). 22 This draft describes the necessary IS-IS extensions that need to be 23 introduced for Segment Routing. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 24, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 66 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . . 5 68 2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . . . 8 69 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . 9 70 2.3.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 71 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 12 72 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 73 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . 13 74 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 14 75 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 76 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 15 77 2.4.6. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . . 16 78 2.4.7. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 79 2.4.8. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 17 80 2.4.9. Unnumbered Interface ID ERO subTLV . . . . . . . . . . 17 81 2.4.10. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . . 18 82 2.4.11. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . . 19 83 2.4.12. Unnumbered Interface ID Backup ERO subTLV . . . . . . 19 84 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path 85 semantics . . . . . . . . . . . . . . . . . . . . . . 20 86 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 21 87 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 21 88 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . . 22 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 5. Manageability Considerations . . . . . . . . . . . . . . . . . 24 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 Segment Routing (SR) allows for a flexible definition of end-to-end 102 paths within IGP topologies by encoding paths as sequences of 103 topological sub-paths, called "segments". These segments are 104 advertised by the link-state routing protocols (IS-IS and OSPF). Two 105 types of segments are defined, Prefix segments and Adjacency 106 segments. Prefix segments represent an ecmp-aware shortest-path to a 107 prefix, as per the state of the IGP topology. Adjacency segments 108 represent a hop over a specific adjacency between two nodes in the 109 IGP. A prefix segment is typically a multi-hop path while an 110 adjacency segment, in most of the cases, is a one-hop path. SR's 111 control-plane can be applied to both IPv6 and MPLS data-planes, and 112 do not require any additional signaling (other than the regular IGP). 113 For example, when used in MPLS networks, SR paths do not require any 114 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 115 of LSPs established with RSVP or LDP. 117 This draft describes the necessary IS-IS extensions that need to be 118 introduced for Segment Routing. 120 Segment Routing architecture is described in 121 [I-D.filsfils-rtgwg-segment-routing]. 123 Segment Routing use cases are described in 124 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 126 2. Segment Routing Identifiers 128 Segment Routing architecture ([I-D.filsfils-rtgwg-segment-routing]) 129 defines different types of Segment Identifiers (SID). This document 130 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 131 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 133 2.1. SID/Label Sub-TLV 135 The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this 136 document and contains a SID or a MPLS Label. The SID/Label Sub-TLV 137 has the following format: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | SID/Label (variable) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 where: 149 Type: 1 151 Length: variable (3 or 4) 153 SID/Label: if length is set to 3 then the 20 rightmost bits 154 represent a MPLS label. If length is 4 then the value represents 155 a 32 bits SID. 157 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) 159 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 160 (Prefix-SID Sub-TLV). 162 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as 163 defined in [I-D.filsfils-rtgwg-segment-routing]. The 'Prefix SID' 164 must be unique within a given IGP domain. The 'Prefix SID' is an 165 index to determine the actual SID/label value inside the set of all 166 advertised SID/label ranges of a given router. A receiving router 167 uses the index to determine the actual SID/label value in order to 168 construct forwarding state to a particular destination router. 170 In many use-cases a 'stable transport' IP Address is overloaded as an 171 identifier of a given node. Because the IP Prefixes may be re- 172 advertised into other levels there may be some ambiguity (e.g. 173 Originating router vs. L1L2 router) for which node a particular IP 174 prefix serves as identifier. The Prefix-SID Sub-TLV contains the 175 necessary flags to dissambiguate IP Prefix to node mappings. 176 Furthermore if a given node has several 'stable transport' IP 177 adresses there are flags to differentiate those among other IP 178 Prefixes advertised from a given node. 180 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 181 and MAY be present in any of the following TLVs: 183 TLV-135 (IPv4) defined in [RFC5305]. 185 TLV-235 (MT-IPv4) defined in [RFC5120]. 187 TLV-236 (IPv6) defined in [RFC5308]. 189 TLV-237 (MT-IPv6) defined in [RFC5120]. 191 The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP 192 Reachability TLV gets propagated across level boundaries. 194 The Prefix-SID Sub-TLV has the following format: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | Flags | Algorithm | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | SID/Index | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 where: 206 Type: 3 208 Length: variable. 210 Flags: 1 octet field of following flags: 212 0 1 2 3 4 5 6 7 213 +-+-+-+-+-+-+-+-+ 214 |R|N|P| | 215 +-+-+-+-+-+-+-+-+ 217 where: 219 R-Flag: Re-advertisement flag. If set, then the prefix to 220 which this Prefix-SID is attached, has been propagated by the 221 router either from another level (i.e.: from level-1 to level-2 222 or the opposite) or from redistribution (e.g.: from another 223 protocol). 225 N-Flag: Node-SID flag. Optional and, if set, then the Prefix- 226 SID refers to the router identified by the prefix. Typically, 227 the N-Flag is set on Prefix-SIDs attached to a router loopback 228 address. The N-Flag is set when the Prefix-SID is a Node-SID 229 as described in [I-D.filsfils-rtgwg-segment-routing]. 231 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 232 pop the Prefix-SID before delivering the packet to the node 233 that advertised the Prefix-SID. 235 Other bits: MUST be zero when originated and ignored when 236 received. 238 Algorithm: the router may use various algorithms when calculating 239 reachability to other nodes or to prefixes attached to these 240 nodes. Examples of these algorithms are metric based Shortest 241 Path First (SPF), various sorts of Constrained SPF, etc. The 242 Algorithm field allows a router to advertise algorithms that 243 router is currently using. SR-Algorithm TLV has following 244 structure: one octet identifying the algorithm to which the 245 Prefix-SID is associated. Currently, the following value has been 246 defined: 248 0: Shortest Path First (SPF) algorithm based on link metric. 250 Definitions and use of algorithms in Segment Routing are 251 described in [I-D.filsfils-rtgwg-segment-routing] 253 SID/Index: 32 bit index defining the offset in the SID/Label space 254 advertised by this router using the encodings defined in 255 Section 3.1. 257 Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which 258 case each SID is encoded as a separate Sub-TLV. When multiple 259 Prefix-SID Sub-TLVs are present, the receiving router MUST use the 260 first encoded SID and MAY use the subsequent ones. 262 The No-PHP flag MUST be set on the Prefix-SIDs associated with 263 reachability advertisements which were originated by other routers 264 and leaked (either from Level-1 to Level-2 or vice versa). 266 The R-Flag MUST be set for prefixes that are not local to the router 267 and either: 269 advertised because of propagation (Level-1 into Level-2); 271 advertised because of leaking (Level-2 into Level-1); 273 advertised because redistribution (e.g.: from another protocol). 275 In the case where a Level-1-2 router has local interface addresses 276 configured in one level, it may also propagate these addresses into 277 the other level. In such case, the Level-1-2 router MUST NOT set the 278 R bit. The R-bit MUST be set only for prefixes that are not local to 279 the router and advertised by the router because of propagation and/or 280 leaking. 282 The N-Flag is used in order to define a Node-SID. A router MAY set 283 the N-Flag only if all of the following conditions are met: 285 The prefix to which the Prefix-SID is attached is local to the 286 router. I.e.: the prefix is configured on one of the local 287 interfaces. (e.g.: 'stable transport' loopback). 289 The prefix to which the Prefix-SID is attached MUST have a Prefix 290 length of either /32 (IPv4) or /128 (IPv6). 292 The router MUST ignore the N-Flag on a received Prefix-SID if the 293 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 295 The router behavior determined by the P, R and N flags are described 296 in [I-D.filsfils-rtgwg-segment-routing]. 298 2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV 300 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 301 TLV (Adj-SID Sub-TLV). 303 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 304 Routing IGP-Adjacency-SID as defined in 305 [I-D.filsfils-rtgwg-segment-routing] with flags and fields that may 306 be used, in future extensions of Segment Routing, for carrying other 307 types of SIDs. 309 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 310 below: 312 TLV-22 [RFC5305] 314 TLV-222 [RFC5120] 316 TLV-23 [RFC5311] 318 TLV-223 [RFC5311] 320 TLV-141 [RFC5316] 322 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 323 neighbor. Examples where more than one Adj-SID may be used per IS- 324 neighbor are described in 325 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 327 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 329 The following format is defined for the Adj-SID Sub-TLV: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | Flags | Weight | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | SID/Label Sub-TLV (variable) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 where: 341 Type: 31 343 Length: variable. 345 Flags: 1 octet field of following flags: 347 0 1 2 3 4 5 6 7 348 +-+-+-+-+-+-+-+ 349 |F|B| | 350 +-+-+-+-+-+-+-+ 352 where: 354 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 355 to an adjacency with outgoing IPv4 encapsulation. If set then 356 the Adj-SID refers to an adjacency with outgoing IPv6 357 encapsulation. 359 B-Flag: Backup flag. If set, the Adj-SID refers to an 360 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 361 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 363 Other bits: MUST be zero when originated and ignored when 364 received. 366 Weight: 1 octet. The value represents the weight of the Adj-SID 367 for the purpose of load balancing. The use of the weight is 368 defined in [I-D.filsfils-rtgwg-segment-routing]. 370 SID/Label Sub-TLV: contains the SID/Label value as defined in 371 Section 2.1. 373 An SR capable router MAY allocate an Adj-SID for each of its 374 adjacencies and SHOULD set the B-Flag when the adjacency is 375 protected by a FRR mechanism (IP or MPLS) as described in 376 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 378 The F-flag is used in order for the router to advertise the 379 outgoing encapsulation of the adjacency the Adj-SID is attached 380 to. Use cases of the use of the F-flag are described in 381 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 383 2.3.2. Adjacency Segment Identifiers in LANs 385 In LAN subnetworks, the Designated Intermediate System (DIS) is 386 elected and originates the Pseudonode-LSP (PN-LSP) including all 387 neighbors of the DIS. 389 When Segment Routing is used, each router in the LAN MAY advertise 390 the Adj-SID of each of its neighbors. Since, on LANs, each router 391 only advertises one adjacency to the DIS (and doesn't advertise any 392 other adjacency), each router advertises the set of Adj-SIDs (for 393 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 394 advertising the adjacency to the DIS (e.g.: TLV-22). 396 The following new Sub-TLV is defined: LAN-Adj-SID (Type 32) 397 containing the set of Adj-SIDs the router assigned to each of its LAN 398 neighbors. 400 The format of the LAN-Adj-SID Sub-TLV is as follows: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | Flags | Weight | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | System-ID (6 octets) | 410 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | SID/Label Sub-TLV (variable) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 where: 420 Type: 32 422 Length: variable. 424 Flags: 1 octet field of following flags: 426 0 1 2 3 4 5 6 7 427 +-+-+-+-+-+-+-+ 428 |F|B| | 429 +-+-+-+-+-+-+-+ 431 where: 433 F-Flag: Address Family flag. If unset, then the Adj-SID refers 434 to an adjacency with outgoing IPv4 encapsulation. If set then 435 the Adj-SID refers to an adjacency with outgoing IPv6 436 encapsulation. 438 B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an 439 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 440 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 442 Other bits: MUST be zero when originated and ignored when 443 received. 445 Weight: 1 octet. The value represents the weight of the Adj-SID 446 for the purpose of load balancing. The use of the weight is 447 defined in [I-D.filsfils-rtgwg-segment-routing]. 449 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 450 defined in [ISO10589]. 452 SID/Label Sub-TLV: contains the SID/Label value as defined in 453 Section 2.1. 455 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 457 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 458 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 459 advertisements of the adjacency to the DIS MUST be used, MUST have 460 the same metric and SHOULD be inserted within the same LSP fragment. 462 Each router within the level, by receiving the DIS PN LSP as well as 463 the non-PN LSP of each router in the LAN, is capable of 464 reconstructing the LAN topology as well as the set of Adj-SID each 465 router uses for each of its neighbors. 467 2.4. SID/Label Binding TLV 469 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 470 domain. The router may advertise a SID/Label binding to a FEC along 471 with at least a single 'nexthop style' anchor. The protocol supports 472 more than one 'nexthop style' anchor to be attached to a SID/Label 473 binding, which results into a simple path description language. In 474 analogy to RSVP the terminology for this is called an 'Explicit Route 475 Object' (ERO). Since ERO style path notation allows to anchor SID/ 476 label bindings to to both link and node IP addresses any label 477 switched path, can be described. Furthermore also SID/Label Bindings 478 from external protocols can get easily re-advertised. 480 The SID/Label Binding TLV may be used for advertising SID/Label 481 Bindings and their associated Primary and Backup paths. In one 482 single TLV either a primary ERO Path, a backup ERO Path or both are 483 advertised. If a router wants to advertise multiple parallel paths 484 then it can generate several TLVs for the same Prefix/FEC. Each 485 occurence of a Binding TLV with respect with a given FEC Prefix has 486 accumulating and not canceling semantics. Due the space constraints 487 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 488 ERO path in one SID/Label Binding TLV and the backup ERO path in a 489 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 490 Sub-TLV MUST be identical in both TLVs. 492 The SID/Label Binding TLV has type TBA and has the following format: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Length | Flags | Weight | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Range | Prefix Length | FEC Prefix | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 // FEC Prefix (continued, variable) // 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | optional subTLVs (variable) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 1: SID/Label Binding TLV format 508 o Type: 149 510 o Length: variable. 512 o 1 octet of flags 513 o 1 octet of Prefix length 515 o 0-16 octets of FEC Prefix 517 o 2 octets of Range 519 o sub-TLVs, where each sub-TLV consists of a sequence of: 521 * 1 octet of sub-TLV type 523 * 1 octet of length of the value field of the sub-TLV 525 * 0-255 octets of value 527 2.4.1. Flags 529 Flags: 1 octet field of following flags: 531 0 1 2 3 4 5 6 7 532 +-+-+-+-+-+-+-+-+ 533 |F|M|X|S| | 534 +-+-+-+-+-+-+-+-+ 536 where: 538 F-Flag: Address Family flag. If unset, then the Prefix FEC 539 carries an IPv4 Prefix. If set then the Prefix FEC carries an 540 IPv6 Prefix. 542 M-Flag: Mirror Context flag. Set if the advertised SID/path 543 corresponds to a mirrored context. 545 X-Flag: Index flag. Set if the value of the SID/Label Sub-TLV 546 carries an index. Unset if the value of the SID/Label Sub-TLV 547 carries a local SID/Label. 549 S-Flag: subTLV present 'S' flag: Set if there are subTLVs present. 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 advertisments > 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|1|1| | 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|1|1| | 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 653 SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric 654 sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the 655 advertised ERO. Since manipulation of the Metric field may attract 656 or distract traffic from and to the advertised segment it MAY be 657 manually 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 size) | 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: 2 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 and Wim Henderickx. 1038 8. Acknowledgements 1040 We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart 1041 Bryant and Pierre Francois for their contribution to the content of 1042 this document. 1044 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1045 earlier incarnations of the "Binding / MPLS Label TLV" in 1046 [I-D.gredler-isis-label-advertisement]. 1048 9. References 1050 9.1. Normative References 1052 [ISO10589] 1053 International Organization for Standardization, 1054 "Intermediate system to Intermediate system intra-domain 1055 routeing information exchange protocol for use in 1056 conjunction with the protocol for providing the 1057 connectionless-mode Network Service (ISO 8473)", ISO/ 1058 IEC 10589:2002, Second Edition, Nov 2002. 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, March 1997. 1063 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1064 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1065 Tunnels", RFC 3209, December 2001. 1067 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1068 in Resource ReSerVation Protocol - Traffic Engineering 1069 (RSVP-TE)", RFC 3477, January 2003. 1071 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1072 System to Intermediate System (IS-IS) Extensions for 1073 Advertising Router Information", RFC 4971, July 2007. 1075 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1076 Topology (MT) Routing in Intermediate System to 1077 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1079 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1080 Engineering", RFC 5305, October 2008. 1082 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1083 October 2008. 1085 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1086 "Simplified Extension of Link State PDU (LSP) Space for 1087 IS-IS", RFC 5311, February 2009. 1089 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1090 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1091 Traffic Engineering", RFC 5316, December 2008. 1093 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1094 Engineering in IS-IS", RFC 6119, February 2011. 1096 9.2. Informative References 1098 [I-D.filsfils-rtgwg-segment-routing] 1099 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1100 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1101 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1102 "Segment Routing Architecture", 1103 draft-filsfils-rtgwg-segment-routing-00 (work in 1104 progress), June 2013. 1106 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1107 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1108 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1109 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1110 "Segment Routing Use Cases", 1111 draft-filsfils-rtgwg-segment-routing-use-cases-01 (work in 1112 progress), July 2013. 1114 [I-D.gredler-isis-label-advertisement] 1115 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1116 "Advertising MPLS labels in IS-IS", 1117 draft-gredler-isis-label-advertisement-03 (work in 1118 progress), May 2013. 1120 Authors' Addresses 1122 Stefano Previdi (editor) 1123 Cisco Systems, Inc. 1124 Via Del Serafico, 200 1125 Rome 00142 1126 Italy 1128 Email: sprevidi@cisco.com 1130 Clarence Filsfils 1131 Cisco Systems, Inc. 1132 Brussels, 1133 BE 1135 Email: cfilsfil@cisco.com 1137 Ahmed Bashandy 1138 Cisco Systems, Inc. 1139 170, West Tasman Drive 1140 San Jose, CA 95134 1141 US 1143 Email: bashandy@cisco.com 1144 Hannes Gredler 1145 Juniper Networks, Inc. 1146 1194 N. Mathilda Ave. 1147 Sunnyvale, CA 94089 1148 US 1150 Email: hannes@juniper.net 1152 Stephane Litkowski 1153 Orange 1154 FR 1156 Email: stephane.litkowski@orange.com