idnits 2.17.1 draft-previdi-isis-segment-routing-extensions-03.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 3841 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-03 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 75 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 76 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 15 77 2.4.6. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 15 78 2.4.7. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 79 2.4.8. Unnumbered Interface ID ERO subTLV . . . . . . . . . . 16 80 2.4.9. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . . 17 81 2.4.10. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . . 18 82 2.4.11. Unnumbered Interface ID Backup ERO subTLV . . . . . . 18 83 2.4.12. Prefix ERO and Prefix Backup ERO subTLV path 84 semantics . . . . . . . . . . . . . . . . . . . . . . 19 85 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 86 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 87 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . . 21 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 5. Manageability Considerations . . . . . . . . . . . . . . . . . 22 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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: TBA 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: TBA 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: TBA 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 containing the set 397 of Adj-SIDs the router assigned to each of its LAN neighbors. 399 The format of the LAN-Adj-SID Sub-TLV is as follows: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length | Flags | Weight | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | System-ID (6 octets) | 409 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | SID/Label Sub-TLV (variable) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 where: 419 Type: TBA. 421 Length: variable. 423 Flags: 1 octet field of following flags: 425 0 1 2 3 4 5 6 7 426 +-+-+-+-+-+-+-+ 427 |F|B| | 428 +-+-+-+-+-+-+-+ 430 where: 432 F-Flag: Address Family flag. If unset, then the Adj-SID refers 433 to an adjacency with outgoing IPv4 encapsulation. If set then 434 the Adj-SID refers to an adjacency with outgoing IPv6 435 encapsulation. 437 B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an 438 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 439 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 441 Other bits: MUST be zero when originated and ignored when 442 received. 444 Weight: 1 octet. The value represents the weight of the Adj-SID 445 for the purpose of load balancing. The use of the weight is 446 defined in [I-D.filsfils-rtgwg-segment-routing]. 448 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 449 defined in [ISO10589]. 451 SID/Label Sub-TLV: contains the SID/Label value as defined in 452 Section 2.1. 454 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 456 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 457 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 458 advertisements of the adjacency to the DIS MUST be used, MUST have 459 the same metric and SHOULD be inserted within the same LSP fragment. 461 Each router within the level, by receiving the DIS PN LSP as well as 462 the non-PN LSP of each router in the LAN, is capable of 463 reconstructing the LAN topology as well as the set of Adj-SID each 464 router uses for each of its neighbors. 466 2.4. SID/Label Binding TLV 468 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 469 domain. The router may advertise a SID/Label binding to a FEC along 470 with at least a single 'nexthop style' anchor. The protocol supports 471 more than one 'nexthop style' anchor to be attached to a SID/Label 472 binding, which results into a simple path description language. In 473 analogy to RSVP the terminology for this is called an 'Explicit Route 474 Object' (ERO). Since ERO style path notation allows to anchor SID/ 475 label bindings to to both link and node IP addresses any label 476 switched path, can be described. Furthermore also SID/Label Bindings 477 from external protocols can get easily re-advertised. 479 The SID/Label Binding TLV may be used for advertising SID/Label 480 Bindings and their associated Primary and Backup paths. In one 481 single TLV either a primary ERO Path, a backup ERO Path or both are 482 advertised. If a router wants to advertise multiple parallel paths 483 then it can generate several TLVs for the same Prefix/FEC. Each 484 occurence of a Binding TLV with respect with a given FEC Prefix has 485 accumulating and not canceling semantics. Due the space constraints 486 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 487 ERO path in one SID/Label Binding TLV and the backup ERO path in a 488 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 489 Sub-TLV MUST be identical in both TLVs. 491 The SID/Label Binding TLV has type TBA and has the following format: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | Flags | Weight | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Range | Prefix Length | FEC Prefix | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 // FEC Prefix (continued, variable) // 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | optional subTLVs (variable) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 1: SID/Label Binding TLV format 507 o 1 octet of flags 509 o 1 octet of Prefix length 511 o 0-16 octets of FEC Prefix 512 o 2 octets of Range 514 o sub-TLVs, where each sub-TLV consists of a sequence of: 516 * 1 octet of sub-TLV type 518 * 1 octet of length of the value field of the sub-TLV 520 * 0-255 octets of value 522 2.4.1. Flags 524 Flags: 1 octet field of following flags: 526 0 1 2 3 4 5 6 7 527 +-+-+-+-+-+-+-+-+ 528 |F|M|X|S| | 529 +-+-+-+-+-+-+-+-+ 531 where: 533 F-Flag: Address Family flag. If unset, then the Prefix FEC 534 carries an IPv4 Prefix. If set then the Prefix FEC carries an 535 IPv6 Prefix. 537 M-Flag: Mirror Context flag. Set if the advertised SID/path 538 corresponds to a mirrored context. 540 X-Flag: Index flag. Set if the value of the SID/Label Sub-TLV 541 carries an index. Unset if the value of the SID/Label Sub-TLV 542 carries a local SID/Label. 544 S-Flag: subTLV present 'S' flag: Set if there are subTLVs present. 546 Other bits: MUST be zero when originated and ignored when 547 received. 549 2.4.2. Weight 551 Weight: 1 octet: The value represents the weight of the path for the 552 purpose of load balancing. The use of the weight is defined in 553 [I-D.filsfils-rtgwg-segment-routing]. 555 2.4.3. Range 557 The 'Range' field provides the ability to specify a range of 558 addresses and their associated Prefix SIDs. It is essentially a 559 compression scheme to distribute a continuous Prefix and their 560 continuous, corresponding SID/Label Block. If a single SID is 561 advertised then the range field MUST be set to one. For range 562 advertisments > 1, the number of addresses that need to be mapped 563 into a Prefix-SID and the starting value of the Prefix-SID range. 565 Example 1: if the following router addresses (loopback addresses) 566 need to be mapped into the corresponding Prefix SID indexes. 568 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 569 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 570 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 571 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Type | Length |0|0|1|1| | Weight | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Range = 4 | /32 | 192 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | .0 | .2 | .1 | Sub-TLV Type | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Sub-TLV Length| 1 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Example-2: If the following prefixes need to be mapped into the 586 corresponding Prefix-SID indexes: 588 10.1.1/24, Prefix-SID: Index 51 589 10.1.2/24, Prefix-SID: Index 52 590 10.1.3/24, Prefix-SID: Index 53 591 10.1.4/24, Prefix-SID: Index 54 592 10.1.5/24, Prefix-SID: Index 55 593 10.1.6/24, Prefix-SID: Index 56 594 10.1.7/24, Prefix-SID: Index 57 596 0 1 2 3 597 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Length |0|0|1|1| | Weight | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Range = 7 | /24 | 10 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | .1 | .1 | Sub-TLV Type | Sub-TLV Length| 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | 51 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 It is not expected that a network operator will be able to keep fully 609 continuous FEC Prefix / SID/Index mappings. In order to support 610 noncontinuous mapping ranges an implementation MAY generate several 611 instances of Binding TLVs. 613 For example if a router wants to advertise the following ranges: 615 Range 16: { 192.168.1.1-15, Index 1-15 } 617 Range 6: { 192.168.1.22-27, Index 22-27 } 619 Range 41: { 192.168.1.44-84, Index 80-120 } 621 A router would need to advertise three instances of the Binding TLV. 623 2.4.4. Prefix Length, Prefix 625 The 'FEC Prefix' represents the Forwarding equivalence class at the 626 tail-end of the advertised path. The 'FEC Prefix' does not need to 627 correspond to a routable prefix of the originating node. 629 The 'Prefix Length' field contains the length of the prefix in bits. 630 Only the most significant octets of the Prefix FEC are encoded. I.e. 631 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 632 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 633 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 634 prefix length 113 up to 128. 636 2.4.5. SID/Label Sub-TLV 638 The SID/Label Sub-TLV contains the SID/Label value as defined in 639 Section 2.1. It MUST be present in every SID/Label Binding TLV. 641 2.4.6. IPv4 ERO subTLV 643 The IPv4 ERO subTLV (Type TBA) describes a path segment using IPv4 644 address style of encoding. Its semantics have been borrowed from 645 [RFC3209]. 647 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 648 set, then the value of the attribute is 'loose.' Otherwise, the 649 value of the attribute is 'strict.' 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Type | Length |L| Reserved | IPv4 address | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | IPv4 address (continued) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 2: IPv4 ERO subTLV format 660 2.4.7. IPv6 ERO subTLV 662 The IPv6 ERO subTLV (Type TBA) describes a path segment using IPv6 663 Address style of encoding. Its semantics have been borrowed from 664 [RFC3209]. 666 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 667 set, then the value of the attribute is 'loose.' Otherwise, the 668 value of the attribute is 'strict.' 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type | Length |L| Reserved | IPv6 address | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | IPv6 Address (continued) | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | IPv6 Address (continued) | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | IPv6 Address (continued) | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | IPv6 Address (continued) | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 3: IPv6 ERO subTLV format 686 2.4.8. Unnumbered Interface ID ERO subTLV 688 The appearance and semantics of the 'Unnumbered Interface ID' have 689 been borrowed from Section 4 [RFC3477]. 691 The Unnumbered Interface-ID ERO subTLV (Type TBA) describes a path 692 segment that spans over an unnumbered interface. Unnumbered 693 interfaces are referenced using the interface index. Interface 694 indices are assigned local to the router and therefore not unique 695 within a domain. All elements in an ERO path need to be unique 696 within a domain and hence need to be disambiguated using a domain 697 unique Router-ID. 699 The 'Router-ID' field contains the router ID of the router which has 700 assigned the 'Interface ID' field. Its purpose is to disambiguate 701 the 'Interface ID' field from other routers in the domain. 703 IS-IS supports two Router-ID formats: 705 o (TLV 134, 32-Bit format) [RFC5305] 707 o (TLV 140, 128-Bit format) [RFC6119] 709 The actual Router-ID format gets derived from the 'Length' field. 711 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 713 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 715 The 'Interface ID' is the identifier assigned to the link by the 716 router specified by the router ID. 718 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 719 set, then the value of the attribute is 'loose.' Otherwise, the 720 value of the attribute is 'strict.' 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Type | Length |L| Reserved | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 // Router ID (32 or 128 bits) // 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Interface ID (32 bits) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Figure 4: Unnumbered Interface ID ERO subTLV format 734 2.4.9. IPv4 Backup ERO subTLV 736 The IPv4 Backup ERO subTLV (Type TBA) describes a Backup path segment 737 using IPv4 Address style of encoding. Its appearance and semantics 738 have been borrowed from [RFC3209]. 740 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 741 set, then the value of the attribute is 'loose.' Otherwise, the 742 value of the attribute is 'strict.' 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type | Length |L| Reserved | IPv4 address | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | IPv4 address (continued) | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 5: IPv4 Backup ERO subTLV format 753 2.4.10. IPv6 Backup ERO subTLV 755 The IPv6 Backup ERO subTLV (Type TBA) describes a Backup path segment 756 using IPv6 Address style of encoding. Its appearance and semantics 757 have been borrowed from [RFC3209]. 759 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 760 set, then the value of the attribute is 'loose.' Otherwise, the 761 value of the attribute is 'strict.' 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length |L| Reserved | IPv6 address | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | IPv6 Address (continued) | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | IPv6 Address (continued) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | IPv6 Address (continued) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | IPv6 Address (continued) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 Figure 6: IPv6 Backup ERO subTLV format 779 2.4.11. Unnumbered Interface ID Backup ERO subTLV 781 The appearance and semantics of the 'Unnumbered Interface ID' have 782 been borrowed from Section 4 [RFC3477]. 784 The Unnumbered Interface-ID Backup ERO subTLV (Type TBA) describes a 785 Backup LSP path segment that spans over an unnumbered interface. 786 Unnumbered interfaces are referenced using the interface index. 787 Interface indices are assigned local to the router and therefore not 788 unique within a domain. All elements in an ERO path need to be 789 unique within a domain and hence need to be disambiguated using a 790 domain unique Router-ID. 792 The 'Router-ID' field contains the router ID of the router which has 793 assigned the 'Interface ID' field. Its purpose is to disambiguate 794 the 'Interface ID' field from other routers in the domain. 796 IS-IS supports two Router-ID formats: 798 o (TLV 134, 32-Bit format) [RFC5305] 800 o (TLV 140, 128-Bit format) [RFC6119] 802 The actual Router-ID format gets derived from the 'Length' field. 804 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 806 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 808 The 'Interface ID' is the identifier assigned to the link by the 809 router specified by the router ID. 811 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 812 set, then the value of the attribute is 'loose.' Otherwise, the 813 value of the attribute is 'strict.' 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type | Length |L| Reserved | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 // Router ID (32 or 128 bits) // 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Interface ID (32 bits) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 827 2.4.12. Prefix ERO and Prefix Backup ERO subTLV path semantics 829 All 'ERO' and 'Backup ERO' information represents an ordered set 830 which describes the segments of a path. The last ERO subTLV 831 describes the segment closest to the egress point of the path. 832 Contrary the first ERO subTLV describes the first segment of a path. 833 If a router extends or stitches a label switched path it MUST prepend 834 the new segments path information to the ERO list. The same ordering 835 applies for the Backup ERO labels. An implementation SHOULD first 836 encode all primary path EROs followed by the bypass EROs. 838 3. Router Capabilities 840 3.1. SR-Capabilities Sub-TLV 842 Segment Routing requires each router to advertise its SR data-plane 843 capability and the range of SID/Label values it uses for Segment 844 Routing. Data-plane capabilities and SID/Label ranges are advertised 845 using the newly defined SR-Capabilities Sub-TLV inserted into the 846 IS-IS Router Capability TLV-242 that is defined in [RFC4971]. 848 The Router Capability TLV specifies flags that control its 849 advertisement. The SR Capabilities Sub-TLV MUST be propagated 850 throughout the level and need not to be advertised across level 851 boundaries. Therefore Router Capability TLV distribution flags MUST 852 be set accordingly, i.e.: the S flag MUST be unset. 854 The SR Capabilities Sub-TLV is optional, MAY appear multiple times 855 inside the Router Capability TLV and has following format: 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Length | Flags | Range | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Range (cont.) | SID/Label Sub-TLV (variable size) | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 where: 867 Type: TBA. 869 Length: variable. 871 Flags: 1 octet of flags. The following are defined: 873 0 874 0 1 2 3 4 5 6 7 875 +-+-+-+-+-+-+-+-+ 876 |I|V| | 877 +-+-+-+-+-+-+-+-+ 879 where: 881 I-Flag: IPv4 flag. If set, then the router is capable of 882 outgoing IPv4 encapsulation on all interfaces. 884 V-Flag: IPv6 flag. If set, then the router is capable of 885 outgoing IPv6 encapsulation on all interfaces. 887 Range: 2 octets value defining the number of values of the range 888 from the starting value defined in the SID/Label Sub-TLV. 890 SID/Label Sub-TLV: SID/Label value as defined in Section 2.1. 892 If multiple occurrence of the SR-Capabilities Sub-TLV are advertised 893 by the same router, only the Flags in the first occurrence of the 894 Sub-TLV are to be taken into account. 896 3.2. SR-Algorithm Sub-TLV 898 The router may use various algorithms when calculating reachability 899 to other nodes or to prefixes attached to these nodes. Examples of 900 these algorithms are metric based Shortest Path First (SPF), various 901 sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV allows the 902 router to advertise the algorithms that the router is currently 903 using. The following value has been defined: 905 0: Shortest Path First (SPF) algorithm based on link metric. 907 The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability 908 TLV-242 that is defined in [RFC4971]. 910 The Router Capability TLV specifies flags that control its 911 advertisement. The SR-Algorithm MUST be propagated throughout the 912 level and need not to be advertised across level boundaries. 913 Therefore Router Capability TLV distribution flags MUST be set 914 accordingly, i.e.: the S flag MUST be unset. 916 The SR-Algorithm Sub-TLV is optional, it MAY only appear a single 917 time inside the Router Capability TLV. If the SID-Label Capability 918 Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be 919 advertised. 921 It has following format: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Length | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 where: 933 Type: TBA. 935 Length: variable. 937 Algorithm: 1 octet of algorithm Section 2.2 939 4. IANA Considerations 941 TBD 943 5. Manageability Considerations 945 TBD 947 6. Security Considerations 949 TBD 951 7. Contributors 953 The following people gave a substantial contribution to the content 954 of this document: Martin Horneffer, Bruno Decraene, Igor Milojevic, 955 Rob Shakir, Saku Ytti and Wim Henderickx. 957 8. Acknowledgements 959 We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart 960 Bryant and Pierre Francois for their contribution to the content of 961 this document. 963 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 964 earlier incarnations of the "Binding / MPLS Label TLV" in 965 [I-D.gredler-isis-label-advertisement]. 967 9. References 969 9.1. Normative References 971 [ISO10589] 972 International Organization for Standardization, 973 "Intermediate system to Intermediate system intra-domain 974 routeing information exchange protocol for use in 975 conjunction with the protocol for providing the 976 connectionless-mode Network Service (ISO 8473)", ISO/ 977 IEC 10589:2002, Second Edition, Nov 2002. 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, March 1997. 982 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 983 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 984 Tunnels", RFC 3209, December 2001. 986 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 987 in Resource ReSerVation Protocol - Traffic Engineering 988 (RSVP-TE)", RFC 3477, January 2003. 990 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 991 System to Intermediate System (IS-IS) Extensions for 992 Advertising Router Information", RFC 4971, July 2007. 994 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 995 Topology (MT) Routing in Intermediate System to 996 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 998 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 999 Engineering", RFC 5305, October 2008. 1001 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1002 October 2008. 1004 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1005 "Simplified Extension of Link State PDU (LSP) Space for 1006 IS-IS", RFC 5311, February 2009. 1008 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1009 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1010 Traffic Engineering", RFC 5316, December 2008. 1012 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1013 Engineering in IS-IS", RFC 6119, February 2011. 1015 9.2. Informative References 1017 [I-D.filsfils-rtgwg-segment-routing] 1018 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1019 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1020 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1021 "Segment Routing Architecture", 1022 draft-filsfils-rtgwg-segment-routing-00 (work in 1023 progress), June 2013. 1025 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1026 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1027 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1028 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1029 "Segment Routing Use Cases", 1030 draft-filsfils-rtgwg-segment-routing-use-cases-01 (work in 1031 progress), July 2013. 1033 [I-D.gredler-isis-label-advertisement] 1034 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1035 "Advertising MPLS labels in IS-IS", 1036 draft-gredler-isis-label-advertisement-03 (work in 1037 progress), May 2013. 1039 Authors' Addresses 1041 Stefano Previdi (editor) 1042 Cisco Systems, Inc. 1043 Via Del Serafico, 200 1044 Rome 00142 1045 Italy 1047 Email: sprevidi@cisco.com 1049 Clarence Filsfils 1050 Cisco Systems, Inc. 1051 Brussels, 1052 BE 1054 Email: cfilsfil@cisco.com 1056 Ahmed Bashandy 1057 Cisco Systems, Inc. 1058 170, West Tasman Drive 1059 San Jose, CA 95134 1060 US 1062 Email: bashandy@cisco.com 1063 Hannes Gredler 1064 Juniper Networks, Inc. 1065 1194 N. Mathilda Ave. 1066 Sunnyvale, CA 94089 1067 US 1069 Email: hannes@juniper.net 1071 Stephane Litkowski 1072 Orange 1073 FR 1075 Email: stephane.litkowski@orange.com