idnits 2.17.1 draft-previdi-isis-segment-routing-extensions-01.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 (July 1, 2013) is 3952 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-00 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: January 2, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 B. Decraene 9 S. Litkowski 10 Orange 11 R. Geib 12 Deutsche Telekom 13 I. Milojevic 14 Telekom Srbija 15 R. Shakir 16 British Telecom 17 S. Ytti 18 TDC Oy 19 W. Henderickx 20 Alcatel-Lucent 21 J. Tantsura 22 Ericsson 23 July 1, 2013 25 IS-IS Extensions for Segment Routing 26 draft-previdi-isis-segment-routing-extensions-01 28 Abstract 30 Segment Routing (SR) allows for a flexible definition of end-to-end 31 paths within IGP topologies by encoding paths as sequences of 32 topological sub-paths, called "segments". These segments are 33 advertised by the link-state routing protocols (IS-IS and OSPF). 35 This draft describes the necessary IS-IS extensions that need to be 36 introduced for Segment Routing. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 2, 2014. 61 Copyright Notice 63 Copyright (c) 2013 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 80 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 81 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . . 5 82 2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . . . 8 83 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . 9 84 2.3.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 85 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 12 86 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 87 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . 13 88 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 13 89 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 90 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 15 91 2.4.6. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 92 2.4.7. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 16 93 2.4.8. Unnumbered Interface ID ERO subTLV . . . . . . . . . . 17 94 2.4.9. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . . 18 95 2.4.10. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . . 18 96 2.4.11. Unnumbered Interface ID Backup ERO subTLV . . . . . . 19 97 2.4.12. Prefix ERO and Prefix Backup ERO subTLV path 98 semantics . . . . . . . . . . . . . . . . . . . . . . 20 99 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 100 3.1. SID/Label Range Sub-TLV . . . . . . . . . . . . . . . . . 20 101 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . . 21 102 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 5. Manageability Considerations . . . . . . . . . . . . . . . . . 22 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 Segment Routing (SR) allows for a flexible definition of end-to-end 114 paths within IGP topologies by encoding paths as sequences of 115 topological sub-paths, called "segments". These segments are 116 advertised by the link-state routing protocols (IS-IS and OSPF). Two 117 types of segments are defined, Prefix segments and Adjacency 118 segments. Prefix segments represent an ecmp-aware shortest-path to a 119 prefix, as per the state of the IGP topology. Adjacency segments 120 represent a hop over a specific adjacency between two nodes in the 121 IGP. A prefix segment is typically a multi-hop path while an 122 adjacency segment, in most of the cases, is a one-hop path. SR's 123 control-plane can be applied to both IPv6 and MPLS data-planes, and 124 do not require any additional signaling (other than the regular IGP). 125 For example, when used in MPLS networks, SR paths do not require any 126 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 127 of LSPs established with RSVP or LDP . 129 This draft describes the necessary IS-IS extensions that need to be 130 introduced for Segment Routing. 132 Segment Routing architecture is described in 133 [I-D.filsfils-rtgwg-segment-routing]. 135 Segment Routing use cases are described in 136 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 138 2. Segment Routing Identifiers 140 Segment Routing architecture ([I-D.filsfils-rtgwg-segment-routing]) 141 defines different types of Segment Identifiers (SID). This document 142 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 143 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 145 2.1. SID/Label Sub-TLV 147 The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this 148 document and contains a SID or a MPLS Label. The SID/Label Sub-TLV 149 has the following format: 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | SID/Label (variable) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 where: 161 Type: TBA 163 Length: variable (3 or 4) 165 SID/Label: if length is set to 3 then the 20 rightmost bits 166 represent a MPLS label. If length is 4 then the value represents 167 a 32 bits SID. 169 2.2. Prefix Segment Identifier (Prefix-SID Sub-TLV) 171 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 172 (Prefix-SID Sub-TLV). 174 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as 175 defined in [I-D.filsfils-rtgwg-segment-routing]. The 'Prefix SID' 176 must be unique within a given IGP domain. The 'Prefix SID' is an 177 index to determine the actual SID/label value inside the set of all 178 advertised SID/label ranges of a given router. A receiving router 179 uses the index to determine the actual SID/label value in order to 180 construct forwarding state to a particular destination router. 182 In many use-cases a 'stable transport' IP Address is overloaded as an 183 identifier of a given node. Because the IP Prefixes may be re- 184 advertised into other levels there may be some ambiguity (e.g. 185 Originating router vs. L1L2 router) for which node a particular IP 186 prefix serves as identifier. The Prefix-SID Sub-TLV contains the 187 necessary flags to dissambiguate IP Prefix to node mappings. 188 Furthermore if a given node has several 'stable transport' IP 189 adresses there are flags to differentiate those among other IP 190 Prefixes advertised from a given node. 192 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 193 and MAY be present in any of the following TLVs: 195 TLV-135 (IPv4) defined in [RFC5305]. 197 TLV-235 (MT-IPv4) defined in [RFC5120]. 199 TLV-236 (IPv6) defined in [RFC5308]. 201 TLV-237 (MT-IPv6) defined in [RFC5120]. 203 The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP 204 Reachability TLV gets propagated across level boundaries. 206 The Prefix-SID Sub-TLV has the following format: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | Flags | Algorithm | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | SID/Index | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 where: 218 Type: TBA 220 Length: variable. 222 Flags: 1 octet field of following flags: 224 0 1 2 3 4 5 6 7 225 +-+-+-+-+-+-+-+-+ 226 |R|N|P| | 227 +-+-+-+-+-+-+-+-+ 229 where: 231 R-Flag: Re-advertisement flag. If set, then the prefix to 232 which this Prefix-SID is attached, has been propagated by the 233 router either from another level (i.e.: from level-1 to level-2 234 or the opposite) or from redistribution (e.g.: from another 235 protocol). 237 N-Flag: Node-SID flag. Optional and, if set, then the Prefix- 238 SID refers to the router identified by the prefix. Typically, 239 the N-Flag is set on Prefix-SIDs attached to a router loopback 240 address. The N-Flag is set when the Prefix-SID is a Node-SID 241 as described in [I-D.filsfils-rtgwg-segment-routing]. 243 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 244 pop the Prefix-SID before delivering the packet to the node 245 that advertised the Prefix-SID. 247 Other bits: MUST be zero when originated and ignored when 248 received. 250 Algorithm: the router may use various algorithms when calculating 251 reachability to other nodes or to prefixes attached to these 252 nodes. Examples of these algorithms are metric based Shortest 253 Path First (SPF), various sorts of Constrained SPF, etc. The 254 Algorithm field allows a router to advertise algorithms that 255 router is currently using. SR-Algorithm TLV has following 256 structure: one octet identifying the algorithm to which the 257 Prefix-SID is associated. Currently, the following value has been 258 defined: 260 0: Shortest Path First (SPF) algorithm based on link metric. 262 Definitions and use of algorithms in Segment Routing are 263 described in [I-D.filsfils-rtgwg-segment-routing] 265 SID/Index: 32 bit index defining the offset in the SID/Label space 266 advertised by this router using the encodings defined in 267 Section 3.1. 269 Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which 270 case each SID is encoded as a separate Sub-TLV. When multiple 271 Prefix-SID Sub-TLVs are present, the receiving router MUST use the 272 first encoded SID and MAY use the subsequent ones. 274 The No-PHP flag MUST be set on the Prefix-SIDs associated with 275 reachability advertisements which were originated by other routers 276 and leaked (either from Level-1 to Level-2 or vice versa). 278 The R-Flag MUST be set for prefixes that are not local to the router 279 and either: 281 advertised because of propagation (Level-1 into Level-2); 283 advertised because of leaking (Level-2 into Level-1); 285 advertised because redistribution (e.g.: from another protocol). 287 In the case where a Level-1-2 router has local interface addresses 288 configured in one level, it may also propagate these addresses into 289 the other level. In such case, the Level-1-2 router MUST NOT set the 290 R bit. The R-bit MUST be set only for prefixes that are not local to 291 the router and advertised by the router because of propagation and/or 292 leaking. 294 The N-Flag is used in order to define a Node-SID. A router MAY set 295 the N-Flag only if all of the following conditions are met: 297 The prefix to which the Prefix-SID is attached is local to the 298 router. I.e.: the prefix is configured on one of the local 299 interfaces. (e.g.: 'stable transport' loopback). 301 The prefix to which the Prefix-SID is attached MUST have a Prefix 302 length of either /32 (IPv4) or /128 (IPv6). 304 The router MUST ignore the N-Flag on a received Prefix-SID if the 305 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 307 The router behavior determined by the P, R and N flags are described 308 in [I-D.filsfils-rtgwg-segment-routing]. 310 2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV 312 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 313 TLV (Adj-SID Sub-TLV). 315 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 316 Routing IGP-Adjacency-SID as defined in 317 [I-D.filsfils-rtgwg-segment-routing] with flags and fields that may 318 be used, in future extensions of Segment Routing, for carrying other 319 types of SIDs. 321 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 322 below: 324 TLV-22 [RFC5305] 326 TLV-222 [RFC5120] 328 TLV-23 [RFC5311] 330 TLV-223 [RFC5311] 332 TLV-141 [RFC5316] 334 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 335 neighbor. Examples where more than one Adj-SID may be used per IS- 336 neighbor are described in 337 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 339 2.3.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 341 The following format is defined for the Adj-SID Sub-TLV: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length | Flags | Weight | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | SID/Label Sub-TLV (variable) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 where: 353 Type: TBA 355 Length: variable. 357 Flags: 1 octet field of following flags: 359 0 1 2 3 4 5 6 7 360 +-+-+-+-+-+-+-+ 361 |F|B| | 362 +-+-+-+-+-+-+-+ 364 where: 366 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 367 to an adjacency with outgoing IPv4 encapsulation. If set then 368 the Adj-SID refers to an adjacency with outgoing IPv6 369 encapsulation. 371 B-Flag: Backup flag. If set, the Adj-SID refers to an 372 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 373 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 375 Other bits: MUST be zero when originated and ignored when 376 received. 378 Weight: 1 octet. The value represents the weight of the Adj-SID 379 for the purpose of load balancing. The use of the weight is 380 defined in [I-D.filsfils-rtgwg-segment-routing]. 382 SID/Label Sub-TLV: contains the SID/Label value as defined in 383 Section 2.1. 385 An SR capable router MAY allocate an Adj-SID for each of its 386 adjacencies and SHOULD set the B-Flag when the adjacency is 387 protected by a FRR mechanism (IP or MPLS) as described in 388 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 390 The F-flag is used in order for the router to advertise the 391 outgoing encapsulation of the adjacency the Adj-SID is attached 392 to. Use cases of the use of the F-flag are described in 393 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 395 2.3.2. Adjacency Segment Identifiers in LANs 397 In LAN subnetworks, the Designated Intermediate System (DIS) is 398 elected and originates the Pseudonode-LSP (PN-LSP) including all 399 neighbors of the DIS. 401 When Segment Routing is used, each router in the LAN MAY advertise 402 the Adj-SID of each of its neighbors. Since, on LANs, each router 403 only advertises one adjacency to the DIS (and doesn't advertise any 404 other adjacency), each router advertises the set of Adj-SIDs (for 405 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 406 advertising the adjacency to the DIS (e.g.: TLV-22). 408 The following new Sub-TLV is defined: LAN-Adj-SID containing the set 409 of Adj-SIDs the router assigned to each of its LAN neighbors. 411 The format of the LAN-Adj-SID Sub-TLV is as follows: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Flags | Weight | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | System-ID (6 octets) | 421 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | SID/Label Sub-TLV (variable) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 where: 431 Type: TBA. 433 Length: variable. 435 Flags: 1 octet field of following flags: 437 0 1 2 3 4 5 6 7 438 +-+-+-+-+-+-+-+ 439 |F|B| | 440 +-+-+-+-+-+-+-+ 442 where: 444 F-Flag: Family flag. If unset, then the Adj-SID refers to an 445 adjacency with outgoing IPv4 encapsulation. If set then the 446 Adj-SID refers to an adjacency with outgoing IPv6 447 encapsulation. 449 B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an 450 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 451 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 453 Other bits: MUST be zero when originated and ignored when 454 received. 456 Weight: 1 octet. The value represents the weight of the Adj-SID 457 for the purpose of load balancing. The use of the weight is 458 defined in [I-D.filsfils-rtgwg-segment-routing]. 460 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 461 defined in [ISO10589]. 463 SID/Label Sub-TLV: contains the SID/Label value as defined in 464 Section 2.1. 466 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 468 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 469 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 470 advertisements of the adjacency to the DIS MUST be used, MUST have 471 the same metric and SHOULD be inserted within the same LSP fragment. 473 Each router within the level, by receiving the DIS PN LSP as well as 474 the non-PN LSP of each router in the LAN, is capable of 475 reconstructing the LAN topology as well as the set of Adj-SID each 476 router uses for each of its neighbors. 478 2.4. SID/Label Binding TLV 480 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 481 domain. The router may advertise a SID/Label binding to a FEC along 482 with at least a single 'nexthop style' anchor. The protocol supports 483 more than one 'nexthop style' anchor to be attached to a SID/Label 484 binding, which results into a simple path description language. In 485 analogy to RSVP the terminology for this is called an 'Explicit Route 486 Object' (ERO). Since ERO style path notation allows to anchor SID/ 487 label bindings to to both link and node IP addresses any label 488 switched path, can be described. Furthermore also SID/Label Bindings 489 from external protocols can get easily re-advertised. 491 The SID/Label Binding TLV may be used for advertising SID/Label 492 Bindings and their associated Primary and Backup paths. In one 493 single TLV either a primary ERO Path, a backup ERO Path or both are 494 advertised. If a router wants to advertise multiple parallel paths 495 then it can generate several TLVs for the same Prefix/FEC. Each 496 occurence of a Binding TLV with respect with a given FEC Prefix has 497 accumulating and not canceling semantics. Due the space constraints 498 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 499 ERO path in one SID/Label Binding TLV and the backup ERO path in a 500 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 501 Sub-TLV MUST be identical in both TLVs. 503 The SID/Label Binding TLV has type TBA and has the following format: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type | Length |F|M|S| Reserved| Weight | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Range | Prefix Length | FEC Prefix | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 // FEC Prefix (continued, variable) // 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | optional subTLVs (variable) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 1: SID/Label Binding TLV format 519 o 521 o 1 octet of flags 523 o 1 octet of Prefix length 524 o 0-16 octets of FEC Prefix 526 o 2 octets of Range 528 o sub-TLVs, where each sub-TLV consists of a sequence of: 530 * 1 octet of sub-TLV type 532 * 1 octet of length of the value field of the sub-TLV 534 * 0-255 octets of value 536 2.4.1. Flags 538 Flags: 1 octet field of following flags: 540 0 1 2 3 4 5 6 7 541 +-+-+-+-+-+-+-+-+ 542 |F|M|X|S| | 543 +-+-+-+-+-+-+-+-+ 545 where: 547 F-Flag: Family flag. If unset, then the Prefix FEC carries an 548 IPv4 Prefix. If set then the Prefix FEC carries an IPv6 Prefix. 550 M-Flag: Mirror Context flag. Set if the advertised SID/path 551 corresponds to a mirrored context. 553 X-Flag: Index flag. Set if the value of the SID/Label Sub-TLV 554 carries an index. Unset if the value of the SID/Label Sub-TLV 555 carries a local SID/Label. 557 S-Flag: subTLV present 'S' flag: Set if there are subTLVs present. 559 Other bits: MUST be zero when originated and ignored when 560 received. 562 2.4.2. Weight 564 Weight: 1 octet: The value represents the weight of the path for the 565 purpose of load balancing. The use of the weight is defined in 566 [I-D.filsfils-rtgwg-segment-routing]. 568 2.4.3. Range 570 The 'Range' field provides the ability to specify a range of 571 addresses and their associated Prefix SIDs. It is essentially a 572 compression scheme to distribute a continuous Prefix and their 573 continuous, corresponding SID/Label Block. If a single SID is 574 advertised then the range field MUST be set to one. For range 575 advertisments > 1, the number of addresses that need to be mapped 576 into a Prefix-SID and the starting value of the Prefix-SID range. 578 Example 1: if the following router addresses (loopback addresses) 579 need to be mapped into the corresponding Prefix SID indexes. 581 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 582 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 583 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 584 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length |0|0|1|1| | Weight | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Range = 4 | /32 | 192 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | .0 | .2 | .1 | Sub-TLV Type | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Sub-TLV Length| 1 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Example-2: If the following prefixes need to be mapped into the 599 corresponding Prefix-SID indexes: 601 10.1.1/24, Prefix-SID: Index 51 602 10.1.2/24, Prefix-SID: Index 52 603 10.1.3/24, Prefix-SID: Index 53 604 10.1.4/24, Prefix-SID: Index 54 605 10.1.5/24, Prefix-SID: Index 55 606 10.1.6/24, Prefix-SID: Index 56 607 10.1.7/24, Prefix-SID: Index 57 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type | Length |0|0|1|1| | Weight | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Range = 7 | /24 | 10 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | .1 | .1 | Sub-TLV Type | Sub-TLV Length| 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | 51 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 It is not expected that a network operator will be able to keep fully 621 continuous FEC Prefix / SID/Index mappings. In order to support 622 noncontinuous mapping ranges an implementation MAY generate several 623 instances of Binding TLVs. 625 For example if a router wants to advertise the following ranges: 627 Range 16: { 192.168.1.1-15, Index 1-15 } 629 Range 6: { 192.168.1.22-27, Index 22-27 } 631 Range 41: { 192.168.1.44-84, Index 80-120 } 633 A router would need to advertise three instances of the Binding TLV. 635 2.4.4. Prefix Length, Prefix 637 The 'FEC Prefix' represents the Forwarding equivalence class at the 638 tail-end of the advertised path. The 'FEC Prefix' does not need to 639 correspond to a routable prefix of the originating node. 641 The 'Prefix Length' field contains the length of the prefix in bits. 642 Only the most significant octets of the Prefix FEC are encoded. I.e. 643 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 644 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 645 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 646 prefix length 113 up to 128. 648 2.4.5. SID/Label Sub-TLV 650 The SID/Label Sub-TLV contains the SID/Label value as defined in 651 Section 2.1. It MUST be present in every SID/Label Binding TLV. 653 2.4.6. IPv4 ERO subTLV 655 The IPv4 ERO subTLV (Type TBA) describes a path segment using IPv4 656 address style of encoding. Its semantics have been borrowed from 657 [RFC3209]. 659 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 660 set, then the value of the attribute is 'loose.' Otherwise, the 661 value of the attribute is 'strict.' 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Length |L| Reserved | IPv4 address | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | IPv4 address (continued) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Figure 2: IPv4 ERO subTLV format 673 2.4.7. IPv6 ERO subTLV 675 The IPv6 ERO subTLV (Type TBA) describes a path segment using IPv6 676 Address style of encoding. Its semantics have been borrowed from 677 [RFC3209]. 679 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 680 set, then the value of the attribute is 'loose.' Otherwise, the 681 value of the attribute is 'strict.' 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Type | Length |L| Reserved | IPv6 address | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | IPv6 Address (continued) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | IPv6 Address (continued) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | IPv6 Address (continued) | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | IPv6 Address (continued) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Figure 3: IPv6 ERO subTLV format 699 2.4.8. Unnumbered Interface ID ERO subTLV 701 The appearance and semantics of the 'Unnumbered Interface ID' have 702 been borrowed from Section 4 [RFC3477]. 704 The Unnumbered Interface-ID ERO subTLV (Type TBA) describes a path 705 segment that spans over an unnumbered interface. Unnumbered 706 interfaces are referenced using the interface index. Interface 707 indices are assigned local to the router and therefore not unique 708 within a domain. All elements in an ERO path need to be unique 709 within a domain and hence need to be disambiguated using a domain 710 unique Router-ID. 712 The 'Router-ID' field contains the router ID of the router which has 713 assigned the 'Interface ID' field. Its purpose is to disambiguate 714 the 'Interface ID' field from other routers in the domain. 716 IS-IS supports two Router-ID formats: 718 o (TLV 134, 32-Bit format) [RFC5305] 720 o (TLV 140, 128-Bit format) [RFC6119] 722 The actual Router-ID format gets derived from the 'Length' field. 724 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 726 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 728 The 'Interface ID' is the identifier assigned to the link by the 729 router specified by the router ID. 731 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 732 set, then the value of the attribute is 'loose.' Otherwise, the 733 value of the attribute is 'strict.' 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length |L| Reserved | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 // Router ID (32 or 128 bits) // 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Interface ID (32 bits) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Figure 4: Unnumbered Interface ID ERO subTLV format 747 2.4.9. IPv4 Backup ERO subTLV 749 The IPv4 Backup ERO subTLV (Type TBA) describes a Backup path segment 750 using IPv4 Address style of encoding. Its appearance and semantics 751 have been borrowed from [RFC3209]. 753 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 754 set, then the value of the attribute is 'loose.' Otherwise, the 755 value of the attribute is 'strict.' 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length |L| Reserved | IPv4 address | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | IPv4 address (continued) | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Figure 5: IPv4 Backup ERO subTLV format 767 2.4.10. IPv6 Backup ERO subTLV 769 The IPv6 Backup ERO subTLV (Type TBA) describes a Backup path segment 770 using IPv6 Address style of encoding. Its appearance and semantics 771 have been borrowed from [RFC3209]. 773 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 774 set, then the value of the attribute is 'loose.' Otherwise, the 775 value of the attribute is 'strict.' 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Length |L| Reserved | IPv6 address | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | IPv6 Address (continued) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | IPv6 Address (continued) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | IPv6 Address (continued) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | IPv6 Address (continued) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 6: IPv6 Backup ERO subTLV format 793 2.4.11. Unnumbered Interface ID Backup ERO subTLV 795 The appearance and semantics of the 'Unnumbered Interface ID' have 796 been borrowed from Section 4 [RFC3477]. 798 The Unnumbered Interface-ID Backup ERO subTLV (Type TBA) describes a 799 Backup LSP path segment that spans over an unnumbered interface. 800 Unnumbered interfaces are referenced using the interface index. 801 Interface indices are assigned local to the router and therefore not 802 unique within a domain. All elements in an ERO path need to be 803 unique within a domain and hence need to be disambiguated using a 804 domain unique Router-ID. 806 The 'Router-ID' field contains the router ID of the router which has 807 assigned the 'Interface ID' field. Its purpose is to disambiguate 808 the 'Interface ID' field from other routers in the domain. 810 IS-IS supports two Router-ID formats: 812 o (TLV 134, 32-Bit format) [RFC5305] 814 o (TLV 140, 128-Bit format) [RFC6119] 816 The actual Router-ID format gets derived from the 'Length' field. 818 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 820 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 822 The 'Interface ID' is the identifier assigned to the link by the 823 router specified by the router ID. 825 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 826 set, then the value of the attribute is 'loose.' Otherwise, the 827 value of the attribute is 'strict.' 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Type | Length |L| Reserved | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 // Router ID (32 or 128 bits) // 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Interface ID (32 bits) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 841 2.4.12. Prefix ERO and Prefix Backup ERO subTLV path semantics 843 All 'ERO' and 'Backup ERO' information represents an ordered set 844 which describes the segments of a path. The last ERO subTLV 845 describes the segment closest to the egress point of the path. 846 Contrary the first ERO subTLV describes the first segment of a path. 847 If a router extends or stitches a label switched path it MUST prepend 848 the new segments path information to the ERO list. The same ordering 849 applies for the Backup ERO labels. An implementation SHOULD first 850 encode all primary path EROs followed by the bypass EROs. 852 3. Router Capabilities 854 3.1. SID/Label Range Sub-TLV 856 Segment Routing requires each router to advertise the range of SID/ 857 Label values it uses for Segment Routing. The SID/Label ranges are 858 advertised using the newly defined SID/Label Range Sub-TLV inserted 859 into the IS-IS Router Capability TLV-242 that is defined in 860 [RFC4971]. 862 The Router Capability TLV specifies flags that control its 863 advertisement. The SID/Label Range Sub-TLV MUST be propagated 864 throughout the level and need not to be advertised across level 865 boundaries. Therefore Router Capability TLV distribution flags MUST 866 be set accordingly, i.e.: the S flag MUST be unset. 868 The SID/Label Range Sub-TLV is optional, MAY appear multiple times 869 inside the Router Capability TLV and has following format: 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Type | Length | Range | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | SID/Label Sub-TLV (variable) | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 where: 881 Type: TBA. 883 Length: variable. 885 Range: 2 octet value defining the number of values of the range 886 from the starting value defined in the SID/Label Sub-TLV. 888 SID/Label Sub-TLV: SID/Label value as defined in Section 2.1. 890 3.2. SR-Algorithm Sub-TLV 892 The router may use various algorithms when calculating reachability 893 to other nodes or to prefixes attached to these nodes. Examples of 894 these algorithms are metric based Shortest Path First (SPF), various 895 sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV allows the 896 router to advertise the algorithms that the router is currently 897 using. The following value has been defined: 899 0: Shortest Path First (SPF) algorithm based on link metric. 901 The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability 902 TLV-242 that is defined in [RFC4971]. 904 The Router Capability TLV specifies flags that control its 905 advertisement. The SR-Algorithm MUST be propagated throughout the 906 level and need not to be advertised across level boundaries. 907 Therefore Router Capability TLV distribution flags MUST be set 908 accordingly, i.e.: the S flag MUST be unset. 910 The SR-Algorithm Sub-TLV is optional, it MAY only appear a single 911 time inside the Router Capability TLV. If the SID-Label Capability 912 Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be 913 advertised. 915 It has following format: 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type | Length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 where: 927 Type: TBA. 929 Length: variable. 931 Algorithm: 1 octet of algorithm Section 2.2 933 4. IANA Considerations 935 TBD 937 5. Manageability Considerations 939 TBD 941 6. Security Considerations 943 TBD 945 7. Acknowledgements 947 We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart 948 Bryant, Pierre Francois and Martin Horneffer for their contribution 949 to the content of this document. 951 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 952 earlier incarnations of the "Binding / MPLS Label TLV" in 953 [I-D.gredler-isis-label-advertisement]. 955 8. References 957 8.1. Normative References 959 [ISO10589] 960 International Organization for Standardization, 961 "Intermediate system to Intermediate system intra-domain 962 routeing information exchange protocol for use in 963 conjunction with the protocol for providing the 964 connectionless-mode Network Service (ISO 8473)", ISO/ 965 IEC 10589:2002, Second Edition, Nov 2002. 967 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 968 Requirement Levels", BCP 14, RFC 2119, March 1997. 970 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 971 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 972 Tunnels", RFC 3209, December 2001. 974 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 975 in Resource ReSerVation Protocol - Traffic Engineering 976 (RSVP-TE)", RFC 3477, January 2003. 978 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 979 System to Intermediate System (IS-IS) Extensions for 980 Advertising Router Information", RFC 4971, July 2007. 982 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 983 Topology (MT) Routing in Intermediate System to 984 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 986 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 987 Engineering", RFC 5305, October 2008. 989 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 990 October 2008. 992 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 993 "Simplified Extension of Link State PDU (LSP) Space for 994 IS-IS", RFC 5311, February 2009. 996 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 997 Support of Inter-Autonomous System (AS) MPLS and GMPLS 998 Traffic Engineering", RFC 5316, December 2008. 1000 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1001 Engineering in IS-IS", RFC 6119, February 2011. 1003 8.2. Informative References 1005 [I-D.filsfils-rtgwg-segment-routing] 1006 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1007 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1008 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1009 "Segment Routing Architecture", 1010 draft-filsfils-rtgwg-segment-routing-00 (work in 1011 progress), June 2013. 1013 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1014 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1015 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1016 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1017 "Segment Routing Use Cases", 1018 draft-filsfils-rtgwg-segment-routing-use-cases-00 (work in 1019 progress), June 2013. 1021 [I-D.gredler-isis-label-advertisement] 1022 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1023 "Advertising MPLS labels in IS-IS", 1024 draft-gredler-isis-label-advertisement-03 (work in 1025 progress), May 2013. 1027 Authors' Addresses 1029 Stefano Previdi (editor) 1030 Cisco Systems, Inc. 1031 Via Del Serafico, 200 1032 Rome 00142 1033 Italy 1035 Email: sprevidi@cisco.com 1037 Clarence Filsfils 1038 Cisco Systems, Inc. 1039 Brussels, 1040 BE 1042 Email: cfilsfil@cisco.com 1044 Ahmed Bashandy 1045 Cisco Systems, Inc. 1046 170, West Tasman Drive 1047 San Jose, CA 95134 1048 US 1050 Email: bashandy@cisco.com 1052 Hannes Gredler 1053 Juniper Networks, Inc. 1054 1194 N. Mathilda Ave. 1055 Sunnyvale, CA 94089 1056 US 1058 Email: hannes@juniper.net 1059 Bruno Decraene 1060 Orange 1061 FR 1063 Email: bruno.decraene@orange.com 1065 Stephane Litkowski 1066 Orange 1067 FR 1069 Email: stephane.litkowski@orange.com 1071 Rudiger Geib 1072 Deutsche Telekom 1073 DE 1075 Email: Rudiger.Geib@telekom.de 1077 Igor Milojevic 1078 Telekom Srbija 1079 Takovska 2 1080 Belgrade 1081 RS 1083 Email: igormilojevic@telekom.rs 1085 Rob Shakir 1086 British Telecom 1087 London 1088 UK 1090 Email: rob.shakir@bt.com 1092 Saku Ytti 1093 TDC Oy 1094 Mechelininkatu 1a 1095 TDC 00094 1096 FI 1098 Email: saku@ytti.fi 1099 Wim Henderickx 1100 Alcatel-Lucent 1101 Copernicuslaan 50 1102 Antwerp 2018 1103 BE 1105 Email: wim.henderickx@alcatel-lucent.com 1107 Jeff Tantsura 1108 Ericsson 1109 300 Holger Way 1110 San Jose, CA 95134 1111 US 1113 Email: Jeff.Tantsura@ericsson.com