idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2015) is 3221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '100' on line 1270 -- Looks like a reference, but probably isn't: '199' on line 1270 -- Looks like a reference, but probably isn't: '1000' on line 1271 -- Looks like a reference, but probably isn't: '1099' on line 1271 -- Looks like a reference, but probably isn't: '500' on line 1272 -- Looks like a reference, but probably isn't: '599' on line 1272 == Outdated reference: A later version (-04) exists of draft-ietf-isis-prefix-attributes-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-01 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-06 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 10 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 1, 2016 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 B. Decraene 10 Orange 11 J. Tantsura 12 Ericsson 13 June 30, 2015 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-05 18 Abstract 20 Segment Routing (SR) allows for a flexible definition of end-to-end 21 paths within IGP topologies by encoding paths as sequences of 22 topological sub-paths, called "segments". These segments are 23 advertised by the link-state routing protocols (IS-IS and OSPF). 25 This draft describes the necessary IS-IS extensions that need to be 26 introduced for Segment Routing. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 1, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 69 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 70 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 72 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 9 73 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 74 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 75 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 76 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 77 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 78 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 16 79 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 17 80 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 18 81 2.4.5. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 82 2.4.6. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 20 83 2.4.7. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 20 84 2.4.8. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 20 85 2.4.9. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 21 86 2.4.10. Unnumbered Interface ID ERO subTLV . . . . . . . . . 21 87 2.4.11. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 22 88 2.4.12. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 23 89 2.4.13. Unnumbered Interface ID Backup ERO subTLV . . . . . . 23 90 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path 91 semantics . . . . . . . . . . . . . . . . . . . . . . 24 92 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 25 93 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 26 94 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 26 95 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 28 97 4. Non backward compatible changes with prior versions of this 98 document . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 29 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 101 5.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 30 102 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 31 103 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 31 104 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 31 105 6. Manageability Considerations . . . . . . . . . . . . . . . . 34 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 111 10.2. Informative References . . . . . . . . . . . . . . . . . 35 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 114 1. Introduction 116 Segment Routing (SR) allows for a flexible definition of end-to-end 117 paths within IGP topologies by encoding paths as sequences of 118 topological sub-paths, called "segments". These segments are 119 advertised by the link-state routing protocols (IS-IS and OSPF). Two 120 types of segments are defined, Prefix segments and Adjacency 121 segments. Prefix segments represent an ecmp-aware shortest-path to a 122 prefix, as per the state of the IGP topology. Adjacency segments 123 represent a hop over a specific adjacency between two nodes in the 124 IGP. A prefix segment is typically a multi-hop path while an 125 adjacency segment, in most of the cases, is a one-hop path. SR's 126 control-plane can be applied to both IPv6 and MPLS data-planes, and 127 do not require any additional signaling (other than the regular IGP). 128 For example, when used in MPLS networks, SR paths do not require any 129 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 130 of LSPs established with RSVP or LDP. 132 This draft describes the necessary IS-IS extensions that need to be 133 introduced for Segment Routing. 135 Segment Routing architecture is described in 136 [I-D.ietf-spring-segment-routing]. 138 Segment Routing use cases are described in 139 [I-D.filsfils-spring-segment-routing-use-cases]. 141 2. Segment Routing Identifiers 143 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 144 defines different types of Segment Identifiers (SID). This document 145 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 146 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 148 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 150 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 151 (Prefix-SID sub-TLV). 153 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 154 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 155 be unique within a given IGP domain (when the L-flag is not set). 156 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 157 that determines the actual SID/label value inside the set of all 158 advertised SID/label ranges of a given router. A receiving router 159 uses the index to determine the actual SID/label value in order to 160 construct forwarding state to a particular destination router. 162 In many use-cases a 'stable transport' IP Address is overloaded as an 163 identifier of a given node. Because the IP Prefixes may be re- 164 advertised into other levels there may be some ambiguity (e.g. 165 Originating router vs. L1L2 router) for which node a particular IP 166 prefix serves as identifier. The Prefix-SID sub-TLV contains the 167 necessary flags to disambiguate IP Prefix to node mappings. 168 Furthermore if a given node has several 'stable transport' IP 169 addresses there are flags to differentiate those among other IP 170 Prefixes advertised from a given node. 172 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 173 and MAY be present in any of the following TLVs: 175 TLV-135 (IPv4) defined in [RFC5305]. 177 TLV-235 (MT-IPv4) defined in [RFC5120]. 179 TLV-236 (IPv6) defined in [RFC5308]. 181 TLV-237 (MT-IPv6) defined in [RFC5120]. 183 Binding-TLV defined in Section 2.4. 185 When the IP Reachability TLV is propagated across level boundaries, 186 the Prefix-SID sub-TLV SHOULD be kept. 188 The Prefix-SID sub-TLV has the following format: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | Flags | Algorithm | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | SID/Index/Label (variable) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 where: 200 Type: TBD, suggested value 3 202 Length: variable. 204 Flags: 1 octet field of following flags: 206 0 1 2 3 4 5 6 7 207 +-+-+-+-+-+-+-+-+ 208 |R|N|P|E|V|L| | 209 +-+-+-+-+-+-+-+-+ 211 where: 213 R-Flag: Re-advertisement flag. If set, then the prefix to 214 which this Prefix-SID is attached, has been propagated by the 215 router either from another level (i.e.: from level-1 to level-2 216 or the opposite) or from redistribution (e.g.: from another 217 protocol). 219 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 220 the router identified by the prefix. Typically, the N-Flag is 221 set on Prefix-SIDs attached to a router loopback address. The 222 N-Flag is set when the Prefix-SID is a Node-SID as described in 223 [I-D.ietf-spring-segment-routing]. 225 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 226 pop the Prefix-SID before delivering the packet to the node 227 that advertised the Prefix-SID. 229 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 230 the Prefix-SID originator MUST replace the Prefix-SID with a 231 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 232 IPv6) before forwarding the packet. 234 V-Flag: Value flag. If set, then the Prefix-SID carries a 235 value (instead of an index). By default the flag is UNSET. 237 L-Flag: Local Flag. If set, then the value/index carried by 238 the Prefix-SID has local significance. By default the flag is 239 UNSET. 241 Other bits: MUST be zero when originated and ignored when 242 received. 244 Algorithm: the router may use various algorithms when calculating 245 reachability to other nodes or to prefixes attached to these 246 nodes. Algorithms identifiers are defined in Section 3.2. 247 Examples of these algorithms are metric based Shortest Path First 248 (SPF), various sorts of Constrained SPF, etc. The algorithm field 249 of the Prefix-SID contains the identifier of the algorithm the 250 router has used in order to compute the reachability of the prefix 251 the Prefix-SID is associated to. 253 At origination, the Prefix-SID algorithm field MUST be set to 0 on 254 all Prefix-SID of prefixes computed using SPF algorithm (Shortest 255 Path First). On reception of the Prefix-SID sub-TLV, any non-zero 256 algorithm value MUST match what advertised in the SR-Algorithm 257 sub-TLV (Section 3.2). 259 A router receiving a Prefix-SID from a remote node and with an 260 algorithm value that such remote node has not advertised in the 261 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 262 TLV. 264 SID/Index/Label: according to the V and L flags, it contains 265 either: 267 * A 4 octet index defining the offset in the SID/Label space 268 advertised by this router using the encodings defined in 269 Section 3.1. In this case the V and L flags MUST be unset. 271 * A 3 octet local label where the 20 rightmost bits are used for 272 encoding the label value. In this case the V and L flags MUST 273 be set. 275 2.1.1. Flags 277 2.1.1.1. R and N Flags 279 The R-Flag MUST be set for prefixes that are not local to the router 280 and either: 282 advertised because of propagation (Level-1 into Level-2); 284 advertised because of leaking (Level-2 into Level-1); 285 advertised because of redistribution (e.g.: from another 286 protocol). 288 In the case where a Level-1-2 router has local interface addresses 289 configured in one level, it may also propagate these addresses into 290 the other level. In such case, the Level-1-2 router MUST NOT set the 291 R bit. The R-bit MUST be set only for prefixes that are not local to 292 the router and advertised by the router because of propagation and/or 293 leaking. 295 The N-Flag is used in order to define a Node-SID. A router MAY set 296 the N-Flag only if all of the following conditions are met: 298 The prefix to which the Prefix-SID is attached is local to the 299 router. I.e.: the prefix is configured on one of the local 300 interfaces. (e.g.: 'stable transport' loopback). 302 The prefix to which the Prefix-SID is attached MUST have a Prefix 303 length of either /32 (IPv4) or /128 (IPv6). 305 The router MUST ignore the N-Flag on a received Prefix-SID if the 306 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 308 [I-D.ietf-isis-prefix-attributes] also defines the N and R flags and 309 with the same semantics of the equivalent flags defined in this 310 document. There will be a transition period where both sets of flags 311 will be used and eventually only the flags of the Prefix Attributes 312 will remain. During the transition period implementations supporting 313 the N and R flags defined in this document and the N and R flags 314 defined in [I-D.ietf-isis-prefix-attributes] MUST advertise and parse 315 all flags. In case the received flags have different values, the 316 value of the flags defined in [I-D.ietf-isis-prefix-attributes] 317 prevails. 319 2.1.1.2. E and P Flags 321 When calculating the outgoing label for the prefix, the router MUST 322 take into account E and P flags advertised by the next-hop router, if 323 next-hop router advertised the SID for the prefix. This MUST be done 324 regardless of next-hop router contributing to the best path to the 325 prefix or not. 327 When propagating (either from Level-1 to Level-2 or vice versa) a 328 reachability advertisement originated by another IS-IS speaker, the 329 router MUST set the P-flag and MUST clear the E-flag of the related 330 Prefix-SIDs. 332 The following behavior is associated with the settings of the E and P 333 flags: 335 o If the P-flag is not set then any upstream neighbor of the Prefix- 336 SID originator MUST pop the Prefix-SID. This is equivalent to the 337 penultimate hop popping mechanism used in the MPLS dataplane which 338 improves performance of the ultimate hop. MPLS EXP bits of the 339 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 340 being removed). If the P-flag is unset the received E-flag is 341 ignored. 343 o If the P-flag is set then: 345 * If the E-flag is not set then any upstream neighbor of the 346 Prefix-SID originator MUST keep the Prefix-SID on top of the 347 stack. This is useful when, e.g., the originator of the 348 Prefix-SID must stitch the incoming packet into a continuing 349 MPLS LSP to the final destination. This could occur at an 350 inter-area border router (prefix propagation from one area to 351 another) or at an inter-domain border router (prefix 352 propagation from one domain to another). 354 * If the E-flag is set then any upstream neighbor of the Prefix- 355 SID originator MUST replace the PrefixSID with a Prefix-SID 356 having an Explicit-NULL value. This is useful, e.g., when the 357 originator of the Prefix-SID is the final destination for the 358 related prefix and the originator wishes to receive the packet 359 with the original EXP bits. 361 2.1.2. Prefix-SID Propagation 363 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 364 gets propagated across level boundaries. 366 The level-1-2 router that propagates the Prefix-SID sub-TLV between 367 levels MUST set the R-flag. 369 If the Prefix-SID contains a global index (L and V flags unset) and 370 it is propagated as such (with L and V flags unset), the value of the 371 index MUST be preserved when propagated between levels. 373 The level-1-2 router that propagates the Prefix-SID sub-TLV between 374 levels MAY change the setting of the L and V flags in case a local 375 label value is encoded in the Prefix-SID instead of the received 376 value. 378 2.2. Adjacency Segment Identifier 380 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 381 TLV (Adj-SID sub-TLV). 383 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 384 Routing IGP-Adjacency-SID as defined in 385 [I-D.ietf-spring-segment-routing] with flags and fields that may be 386 used, in future extensions of Segment Routing, for carrying other 387 types of SIDs. 389 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 390 below: 392 TLV-22 [RFC5305] 394 TLV-222 [RFC5120] 396 TLV-23 [RFC5311] 398 TLV-223 [RFC5311] 400 TLV-141 [RFC5316] 402 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 403 neighbor. Examples where more than one Adj-SID may be used per IS- 404 neighbor are described in 405 [I-D.filsfils-spring-segment-routing-use-cases]. 407 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 409 The following format is defined for the Adj-SID sub-TLV: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | Flags | Weight | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | SID/Label/Index (variable) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 where: 421 Type: TBD, suggested value 31 423 Length: variable. 425 Flags: 1 octet field of following flags: 427 0 1 2 3 4 5 6 7 428 +-+-+-+-+-+-+-+-+ 429 |F|B|V|L|S| | 430 +-+-+-+-+-+-+-+-+ 432 where: 434 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 435 to an adjacency with outgoing IPv4 encapsulation. If set then 436 the Adj-SID refers to an adjacency with outgoing IPv6 437 encapsulation. 439 B-Flag: Backup flag. If set, the Adj-SID is eligible for 440 protection (e.g.: using IPFRR or MPLS-FRR) as described in 441 [I-D.ietf-spring-resiliency-use-cases]. 443 V-Flag: Value flag. If set, then the Adj-SID carries a value. 444 By default the flag is SET. 446 L-Flag: Local Flag. If set, then the value/index carried by 447 the Adj-SID has local significance. By default the flag is 448 SET. 450 S-Flag. Set Flag. When set, the S-Flag indicates that the 451 Adj-SID refers to a set of adjacencies (and therefore MAY be 452 assigned to other adjacencies as well). 454 Other bits: MUST be zero when originated and ignored when 455 received. 457 Weight: 1 octet. The value represents the weight of the Adj-SID 458 for the purpose of load balancing. The use of the weight is 459 defined in [I-D.ietf-spring-segment-routing]. 461 SID/Index/Label: according to the V and L flags, it contains 462 either: 464 * A 3 octet local label where the 20 rightmost bits are used for 465 encoding the label value. In this case the V and L flags MUST 466 be set. 468 * A 4 octet index defining the offset in the SID/Label space 469 advertised by this router using the encodings defined in 470 Section 3.1. In this case V and L flags MUST be unset. 472 * A 16 octet IPv6 address. In this case the V flag MUST be set. 473 The L flag MUST be unset if the IPv6 address is globally 474 unique. 476 An SR capable router MAY allocate an Adj-SID for each of its 477 adjacencies and SHOULD set the B-Flag when the adjacency is 478 eligible for protection (IP or MPLS). 480 An SR capable router MAY allocate more than one Adj-SID to an 481 adjacency. 483 An SR capable router MAY allocate the same Adj-SID to different 484 adjacencies. 486 Examples of use of the Adj-SID sub-TLV are described in 487 [I-D.ietf-spring-segment-routing]. and 488 [I-D.previdi-6man-segment-routing-header]. 490 The F-flag is used in order for the router to advertise the 491 outgoing encapsulation of the adjacency the Adj-SID is attached 492 to. Use cases of the use of the F-flag are described in 493 [I-D.filsfils-spring-segment-routing-use-cases]. 495 2.2.2. Adjacency Segment Identifiers in LANs 497 In LAN subnetworks, the Designated Intermediate System (DIS) is 498 elected and originates the Pseudonode-LSP (PN-LSP) including all 499 neighbors of the DIS. 501 When Segment Routing is used, each router in the LAN MAY advertise 502 the Adj-SID of each of its neighbors. Since, on LANs, each router 503 only advertises one adjacency to the DIS (and doesn't advertise any 504 other adjacency), each router advertises the set of Adj-SIDs (for 505 each of its neighbors) inside a newly defined sub-TLV part of the TLV 506 advertising the adjacency to the DIS (e.g.: TLV-22). 508 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 509 suggested value 32) containing the set of Adj-SIDs the router 510 assigned to each of its LAN neighbors. 512 The format of the LAN-Adj-SID sub-TLV is as follows: 514 0 1 2 3 515 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | Flags | Weight | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | System-ID (6 octets) | 522 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | SID/Label/Index (variable) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 where: 532 Type: TBD, suggested value 32 534 Length: variable. 536 Flags: 1 octet field of following flags: 538 0 1 2 3 4 5 6 7 539 +-+-+-+-+-+-+-+-+ 540 |F|B|V|L|S| | 541 +-+-+-+-+-+-+-+-+ 543 where F, B, V, L and S flags are defined in Section 2.2.1. Other 544 bits: MUST be zero when originated and ignored when received. 546 Weight: 1 octet. The value represents the weight of the Adj-SID 547 for the purpose of load balancing. The use of the weight is 548 defined in [I-D.ietf-spring-segment-routing]. 550 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 551 defined in [ISO10589]. 553 SID/Index/Label: according to the V and L flags, it contains 554 either: 556 * A 3 octet local label where the 20 rightmost bits are used for 557 encoding the label value. In this case the V and L flags MUST 558 be set. 560 * A 4 octet index defining the offset in the SID/Label space 561 advertised by this router using the encodings defined in 562 Section 3.1. In this case V and L flags MUST be unset. 564 * A 16 octet IPv6 address. In this case the V flag MUST be set. 565 The L flag MUST be unset if the IPv6 address is globally 566 unique. 568 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 570 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 571 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 572 advertisements of the adjacency to the DIS MUST be used and all 573 advertisements MUST have the same metric. 575 Each router within the level, by receiving the DIS PN LSP as well as 576 the non-PN LSP of each router in the LAN, is capable of 577 reconstructing the LAN topology as well as the set of Adj-SID each 578 router uses for each of its neighbors. 580 A label is encoded in 3 octets (in the 20 rightmost bits). 582 An index is encoded in 4 octets. 584 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined 585 in [I-D.previdi-6man-segment-routing-header]). 587 2.3. SID/Label Sub-TLV 589 The SID/Label sub-TLV is present in the following sub-TLVs defined in 590 this document: 592 Binding TLV Section 2.4. 594 SR Capability sub-TLV Section 3.1. 596 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 597 sub-TLV has the following format: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Length | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | SID/Label (variable) | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 where: 609 Type: TBD, suggested value 1 611 Length: variable 613 SID/Label: if length is set to 3 then the 20 rightmost bits 614 represent a MPLS label. 616 2.4. SID/Label Binding TLV 618 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 619 domain. There are multiple uses of the SID/Label Binding TLV: 621 o The router may advertise a SID/Label binding to a FEC along with 622 at least a single 'nexthop style' anchor. The protocol supports 623 more than one 'nexthop style' anchor to be attached to a SID/Label 624 binding, which results into a simple path description language. 625 In analogy to RSVP the terminology for this is called an 'Explicit 626 Route Object' (ERO). Since ERO style path notation allows to 627 anchor SID/label bindings to both link and node IP addresses any 628 label switched path, can be described. Furthermore also SID/Label 629 Bindings from external protocols can get easily re-advertised. 631 o The SID/Label Binding TLV may be used for advertising SID/Label 632 Bindings and their associated Primary and Backup paths. In one 633 single TLV either a primary ERO Path, a backup ERO Path or both 634 are advertised. If a router wants to advertise multiple parallel 635 paths then it can generate several TLVs for the same Prefix/FEC. 636 Each occurrence of a Binding TLV with respect with a given FEC 637 Prefix has accumulating and not canceling semantics. Due the 638 space constraints in the 8-Bit IS-IS TLVs an originating router 639 MAY encode a primary ERO path in one SID/Label Binding TLV and the 640 backup ERO path in a second SID/Label Binding TLV. Note that the 641 FEC Prefix and SID/Label sub-TLV MUST be identical in both TLVs. 643 o The SID/Label Binding TLV may also be used in order to advertise 644 prefixes to SID/Label mappings. This functionality is called the 645 'Mapping Server' and it's used when, in a heterogeneous network, 646 not all nodes are capable of advertising their own SIDs/Labels. 647 When the SID/Label Binding TLV is used by the Mapping Server in 648 order to advertise prefix to SID/label mappings, the index/label 649 MUST include the Prefix-SID SubTLV (Section 2.1). 651 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 652 the following format: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | Flags | Weight | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Range | Prefix Length | FEC Prefix | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 // FEC Prefix (continued, variable) // 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | SubTLVs (variable) | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 1: SID/Label Binding TLV format 668 o Type: TBD, suggested value 149 670 o Length: variable. 672 o 1 octet of flags 674 o 1 octet of Weight 676 o 2 octets of Range 678 o 1 octet of Prefix Length 680 o 0-16 octets of FEC Prefix 682 o sub-TLVs, where each sub-TLV consists of a sequence of: 684 * 1 octet of sub-TLV type 686 * 1 octet of length of the value field of the sub-TLV 688 * 0-243 octets of value 690 2.4.1. Flags 692 Flags: 1 octet field of following flags: 694 0 1 2 3 4 5 6 7 695 +-+-+-+-+-+-+-+-+ 696 |F|M|S|D|A| | 697 +-+-+-+-+-+-+-+-+ 699 where: 701 F-Flag: Address Family flag. If unset, then the Prefix FEC 702 carries an IPv4 Prefix. If set then the Prefix FEC carries an 703 IPv6 Prefix. 705 M-Flag: Mirror Context flag. Set if the advertised SID/path 706 corresponds to a mirrored context. The use of the M flag is 707 described in [I-D.ietf-spring-segment-routing]. 709 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 710 the entire routing domain. If the S flag is not set, the SID/ 711 Label Binding TLV MUST NOT be leaked between levels. This bit 712 MUST NOT be altered during the TLV leaking. 714 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 715 level-1, the D bit MUST be set. Otherwise, this bit MUST be 716 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 717 leaked from level-1 to level-2. This is to prevent TLV looping 718 across levels. 720 A-Flag: Attached flag. The originator of the SID/Label Binding 721 TLV MAY set the A bit in order to signal that the prefixes and 722 SIDs advertised in the SID/Label Binding TLV are directly 723 connected to their originators. The mechanisms through which the 724 originator of the SID/Label Binding TLV can figure out if a prefix 725 is attached or not are outside the scope of this document (e.g.: 726 through explicit configuration). If the Binding TLV is leaked to 727 other areas/levels the A-flag MUST be cleared. 729 An implementation MAY decide not to honor the S-flag in order not 730 to leak Binding TLV's between levels (for policy reasons). In all 731 cases, the D flag MUST always be set by any router leaking the 732 Binding TLV from level-2 into level-1 and MUST be checked when 733 propagating the Binding TLV from level-1 into level-2. If the D 734 flag is set, the Binding TLV MUST NOT be propagated into level-2. 736 Other bits: MUST be zero when originated and ignored when 737 received. 739 2.4.2. Weight 741 Weight: 1 octet: The value represents the weight of the path for the 742 purpose of load balancing. The use of the weight is defined in 743 [I-D.ietf-spring-segment-routing]. 745 2.4.3. Range 747 The 'Range' field provides the ability to specify a range of 748 addresses and their associated Prefix SIDs. This functionality is 749 called "Mapping Server". It is essentially a compression scheme to 750 distribute a continuous Prefix and their continuous, corresponding 751 SID/Label Block. If a single SID is advertised then the range field 752 MUST be set to one. For range advertisements > 1, the number of 753 addresses that need to be mapped into a Prefix-SID and the starting 754 value of the Prefix-SID range. 756 Example 1: if the following router addresses (loopback addresses) 757 need to be mapped into the corresponding Prefix SID indexes. 759 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 760 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 761 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 762 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Type | Length |0|0| | Weight | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Range = 4 | /32 | 192 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | .0 | .2 | .1 |Prefix-SID Type| 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | sub-TLV Length| Flags | Algorithm | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | 1 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Example-2: If the following prefixes need to be mapped into the 779 corresponding Prefix-SID indexes: 781 10.1.1/24, Prefix-SID: Index 51 782 10.1.2/24, Prefix-SID: Index 52 783 10.1.3/24, Prefix-SID: Index 53 784 10.1.4/24, Prefix-SID: Index 54 785 10.1.5/24, Prefix-SID: Index 55 786 10.1.6/24, Prefix-SID: Index 56 787 10.1.7/24, Prefix-SID: Index 57 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type | Length |0|0| | Weight | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Range = 7 | /24 | 10 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Flags | Algorithm | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | 51 | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 It is not expected that a network operator will be able to keep fully 803 continuous FEC Prefix / SID/Index mappings. In order to support 804 noncontinuous mapping ranges an implementation MAY generate several 805 instances of Binding TLVs. 807 For example if a router wants to advertise the following ranges: 809 Range 16: { 192.168.1.1-15, Index 1-15 } 811 Range 6: { 192.168.1.22-27, Index 22-27 } 813 Range 41: { 192.168.1.44-84, Index 80-120 } 815 A router would need to advertise three instances of the Binding TLV. 817 2.4.4. Prefix Length, Prefix 819 The 'FEC Prefix' represents the Forwarding equivalence class at the 820 tail-end of the advertised path. The 'FEC Prefix' does not need to 821 correspond to a routable prefix of the originating node. 823 The 'Prefix Length' field contains the length of the prefix in bits. 824 Only the most significant octets of the Prefix FEC are encoded. I.e. 825 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 826 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 827 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 828 prefix length 113 up to 128. 830 2.4.5. Mapping Server Prefix-SID 832 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 833 and contains the SID/index/label value associated with the prefix and 834 range. The Prefix-SID SubTLV MUST be used when the SID/Label Binding 835 TLV is used by the Mapping Server (i.e.: advertising one or a range 836 of prefixes and their associated SIDs/Labels). 838 A node receiving a MS entry for a prefix MUST check the existence of 839 such prefix in its link-state database prior to consider and use the 840 associated SID. 842 For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV 843 and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the 844 Prefix-SID advertised within the Prefix TLV MUST be preferred while 845 the MS entry MUST be ignored. 847 2.4.5.1. Prefix-SID Flags 849 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 850 MAY advertise a mapping with the N flag set when the prefix being 851 mapped is known in the link-state topology with a mask length of 32 852 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 853 mechanisms through which the operator defines that a prefix 854 represents a node are outside the scope of this document (typically 855 it will be through configuration). 857 The other flags defined in Section 2.1 are not used by the Mapping 858 Server and MUST be ignored at reception. 860 2.4.5.2. PHP Behavior when using Mapping Server Advertisements 862 As the mapping server does not specify the originator of a prefix 863 advertisement it is not possible to determine PHP behavior solely 864 based on the Mapping Server Advertisement. However, if additional 865 information is available PHP behavior may safely be done. The 866 required information consists of: 868 o A prefix reachability advertisement for the prefix has been 869 received which includes the Extended Reachability Attribute Flags 870 sub-TLV ([I-D.ietf-isis-prefix-attributes]). 872 o X and R flags are both set to 0 in the Extended Reachability 873 Attribute Flags sub-TLV. 875 In the absence of an Extended Reachability Attribute Flags sub-TLV 876 ([I-D.ietf-isis-prefix-attributes]) the A flag in the binding TLV 877 indicates that the originator of a prefix reachability advertisement 878 is directly connected to the prefix and thus PHP MUST be done by the 879 neighbors of the router originating the prefix reachability 880 advertisement. Note that A-flag is only valid in the original area 881 in which the Binding TLV is advertised. 883 2.4.5.3. Prefix-SID Algorithm 885 The algorithm field contains the identifier of the algorithm the 886 router MUST use in order to compute reachability to the range of 887 prefixes. Use of the algorithm field is described in Section 2.1. 889 2.4.6. SID/Label Sub-TLV 891 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 892 SID/Label value as defined in Section 2.3. It MAY be present in the 893 SID/Label Binding TLV. 895 2.4.7. ERO Metric sub-TLV 897 ERO Metric sub-TLV (Type: TBD, suggested value 10) is a sub-TLV of 898 the SID/Label Binding TLV. 900 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 901 to compare the cost of a given source/destination path. A router MAY 902 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 903 SHOULD be set to the cumulative IGP or TE path cost of the advertised 904 ERO. Since manipulation of the Metric field may attract or distract 905 traffic from and to the advertised segment it MAY be manually 906 overridden. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Type | Length | Metric | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Metric (continued) | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 ERO Metric sub-TLV format 918 where: 920 Type: TBD, suggested value 10 922 Length: 4 924 Metric: 4 bytes 926 2.4.8. IPv4 ERO subTLV 928 The IPv4 ERO subTLV (Type: TBD, suggested value 11) describes a path 929 segment using IPv4 address style of encoding. Its semantics have 930 been borrowed from [RFC3209]. 932 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 933 set, then the value of the attribute is 'loose.' Otherwise, the 934 value of the attribute is 'strict.' 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Type | Length |L| Reserved | IPv4 address | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | IPv4 address (continued) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 2: IPv4 ERO subTLV format 946 2.4.9. IPv6 ERO subTLV 948 The IPv6 ERO subTLV (Type: TBD, suggested value 12) describes a path 949 segment using IPv6 Address style of encoding. Its semantics have 950 been borrowed from [RFC3209]. 952 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 953 set, then the value of the attribute is 'loose.' Otherwise, the 954 value of the attribute is 'strict.' 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Length |L| Reserved | IPv6 address | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | IPv6 Address (continued) | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | IPv6 Address (continued) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | IPv6 Address (continued) | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | IPv6 Address (continued) | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Figure 3: IPv6 ERO subTLV format 972 2.4.10. Unnumbered Interface ID ERO subTLV 974 The appearance and semantics of the 'Unnumbered Interface ID' have 975 been borrowed from Section 4 [RFC3477]. 977 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 978 13) describes a path segment that spans over an unnumbered interface. 979 Unnumbered interfaces are referenced using the interface index. 981 Interface indices are assigned local to the router and therefore not 982 unique within a domain. All elements in an ERO path need to be 983 unique within a domain and hence need to be disambiguated using a 984 domain unique Router-ID. 986 The 'Router-ID' field contains the router ID of the router which has 987 assigned the 'Interface ID' field. Its purpose is to disambiguate 988 the 'Interface ID' field from other routers in the domain. 990 IS-IS supports two Router-ID formats: 992 o (TLV 134, 32-Bit format) [RFC5305] 994 o (TLV 140, 128-Bit format) [RFC6119] 996 The actual Router-ID format gets derived from the 'Length' field. 998 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1000 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1002 The 'Interface ID' is the identifier assigned to the link by the 1003 router specified by the router ID. 1005 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1006 set, then the value of the attribute is 'loose.' Otherwise, the 1007 value of the attribute is 'strict.' 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Type | Length |L| Reserved | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 // Router ID (32 or 128 bits) // 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Interface ID (32 bits) | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 Figure 4: Unnumbered Interface ID ERO subTLV format 1021 2.4.11. IPv4 Backup ERO subTLV 1023 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 14) describes 1024 a Backup path segment using IPv4 Address style of encoding. Its 1025 appearance and semantics have been borrowed from [RFC3209]. 1027 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1028 set, then the value of the attribute is 'loose.' Otherwise, the 1029 value of the attribute is 'strict.' 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length |L| Reserved | IPv4 address | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | IPv4 address (continued) | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Figure 5: IPv4 Backup ERO subTLV format 1041 2.4.12. IPv6 Backup ERO subTLV 1043 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 15) describes 1044 a Backup path segment using IPv6 Address style of encoding. Its 1045 appearance and semantics have been borrowed from [RFC3209]. 1047 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1048 set, then the value of the attribute is 'loose.' Otherwise, the 1049 value of the attribute is 'strict.' 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Type | Length |L| Reserved | IPv6 address | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | IPv6 Address (continued) | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | IPv6 Address (continued) | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | IPv6 Address (continued) | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | IPv6 Address (continued) | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 6: IPv6 Backup ERO subTLV format 1067 2.4.13. Unnumbered Interface ID Backup ERO subTLV 1069 The appearance and semantics of the 'Unnumbered Interface ID' have 1070 been borrowed from Section 4 [RFC3477]. 1072 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 1073 value 16) describes a Backup LSP path segment that spans over an 1074 unnumbered interface. Unnumbered interfaces are referenced using the 1075 interface index. Interface indices are assigned local to the router 1076 and therefore not unique within a domain. All elements in an ERO 1077 path need to be unique within a domain and hence need to be 1078 disambiguated using a domain unique Router-ID. 1080 The 'Router-ID' field contains the router ID of the router which has 1081 assigned the 'Interface ID' field. Its purpose is to disambiguate 1082 the 'Interface ID' field from other routers in the domain. 1084 IS-IS supports two Router-ID formats: 1086 o (TLV 134, 32-Bit format) [RFC5305] 1088 o (TLV 140, 128-Bit format) [RFC6119] 1090 The actual Router-ID format gets derived from the 'Length' field. 1092 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1094 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1096 The 'Interface ID' is the identifier assigned to the link by the 1097 router specified by the router ID. 1099 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1100 set, then the value of the attribute is 'loose.' Otherwise, the 1101 value of the attribute is 'strict.' 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Type | Length |L| Reserved | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 // Router ID (32 or 128 bits) // 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Interface ID (32 bits) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 1115 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics 1117 All 'ERO' and 'Backup ERO' information represents an ordered set 1118 which describes the segments of a path. The last ERO subTLV 1119 describes the segment closest to the egress point of the path. 1120 Contrary the first ERO subTLV describes the first segment of a path. 1121 If a router extends or stitches a label switched path it MUST prepend 1122 the new segments path information to the ERO list. The same ordering 1123 applies for the Backup ERO labels. An implementation SHOULD first 1124 encode all primary path EROs followed by the bypass EROs. 1126 2.5. Multi-Topology SID/Label Binding TLV 1128 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 1129 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 1130 has the same format as the SID/Label Binding TLV defined in 1131 Section 2.4 with the difference consisting of a Multitopology 1132 Identifier (MTID) as defined here below: 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Type | Length | MTID | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Flags | Weight | Range | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Prefix Length | FEC Prefix | FEC Prefix (variable) | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | SubTLVs (variable) | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 Figure 8: Multi-Topology SID/Label Binding TLV format 1148 where: 1150 Type: TBD, suggested value 150 1152 Length: variable 1154 MTID is the multitopology identifier defined as: 1156 0 1 1157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | RESVD | MTID | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 RESVD: reserved bits. MUST be reset on transmission and 1163 ignored on receive. 1165 MTID: a 12-bit field containing the non-zero ID of the topology 1166 being announced. The TLV MUST be ignored if the ID is zero. 1167 This is to ensure the consistent view of the standard unicast 1168 topology. 1170 The other fields and SubTLVs are defined in Section 2.4. 1172 3. Router Capabilities 1174 3.1. SR-Capabilities Sub-TLV 1176 Segment Routing requires each router to advertise its SR data-plane 1177 capability and the range of MPLS label values it uses for Segment 1178 Routing in the case where global SIDs are allocated (i.e.: global 1179 indexes). Data-plane capabilities and label ranges are advertised 1180 using the newly defined SR-Capabilities sub-TLV inserted into the IS- 1181 IS Router Capability TLV-242 that is defined in [RFC4971]. 1183 The Router Capability TLV specifies flags that control its 1184 advertisement. The SR Capabilities sub-TLV MUST be propagated 1185 throughout the level and SHOULD NOT be advertised across level 1186 boundaries. Therefore Router Capability TLV distribution flags 1187 SHOULD be set accordingly, i.e.: the S flag in the Router Capability 1188 TLV ([RFC4971]) MUST be unset. 1190 The SR Capabilities sub-TLV has following format: 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Type | Length | Flags | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Type: TBD, suggested value 2 1200 Length: variable. 1202 Flags: 1 octet of flags. The following are defined: 1204 0 1 2 3 4 5 6 7 1205 +-+-+-+-+-+-+-+-+ 1206 |I|V|H| | 1207 +-+-+-+-+-+-+-+-+ 1209 where: 1211 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 1212 processing SR MPLS encapsulated IPv4 packets on all interfaces. 1214 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 1215 processing SR MPLS encapsulated IPv6 packets on all interfaces. 1217 H-Flag: SR-IPv6 flag. If set, then the router is capable of 1218 processing the IPv6 Segment Routing Header on all interfaces as 1219 defined in [I-D.previdi-6man-segment-routing-header]. 1221 One or more SRGB Descriptor entries, each of which have the 1222 following format: 1224 Range: 3 octets. 1226 SID/Label sub-TLV (as defined in Section 2.3). 1228 SID/Label sub-TLV contains the first value of the SRGB while the 1229 range contains the number of SRGB elements. The range value MUST be 1230 higher than 0. 1232 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 1233 but a router MUST NOT advertise more than one SR-Capabilities sub- 1234 TLV. When multiple SR-Capabilities sub-TLVs are received from a 1235 given router the behavior of the receiving system is undefined. 1237 When multiple SRGB Descriptors are advertised the entries define an 1238 ordered set of ranges on which a SID index is to be applied. For 1239 this reason changing the order in which the descriptors are 1240 advertised will have a disruptive effect on forwarding. 1242 When a router adds a new SRGB Descriptor to an existing SR- 1243 Capabilities sub-TLV the new Descriptor SHOULD add the newly 1244 configured block at the end of the sub-TLV and SHOULD NOT change the 1245 order of previously advertised blocks. Changing the order of the 1246 advertised descriptors will create label churn in the FIB and 1247 blackhole / misdirect some traffic during the IGP convergence. In 1248 particular, if a range which is not the last is extended it's 1249 preferable to add a new range rather than extending the previously 1250 advertised range. 1252 The originating router MUST ensure the order is same after a graceful 1253 restart (using checkpointing, non-volatile storage or any other 1254 mechanism) in order to guarantee the same order before and after GR. 1256 The originating router MUST NOT advertise overlapping ranges. A 1257 router receiving multiple overlapping ranges MUST ignore all of them 1258 and SHOULD log an error message. 1260 Here follows an example of advertisement of multiple ranges: 1262 The originating router advertises following ranges: 1263 SR-Cap: range: 100, SID value: 100 1264 SR-Cap: range: 100, SID value: 1000 1265 SR-Cap: range: 100, SID value: 500 1267 The receiving routers concatenate the ranges in the received 1268 order and build the SRGB as follows: 1270 SRGB = [100, 199] 1271 [1000, 1099] 1272 [500, 599] 1274 The indexes span multiple ranges: 1276 index=0 means label 100 1277 ... 1278 index 99 means label 199 1279 index 100 means label 1000 1280 index 199 means label 1099 1281 ... 1282 index 200 means label 500 1283 ... 1285 3.2. SR-Algorithm Sub-TLV 1287 The router may use various algorithms when calculating reachability 1288 to other nodes or to prefixes attached to these nodes. Examples of 1289 these algorithms are metric based Shortest Path First (SPF), various 1290 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1291 suggested value 19) allows the router to advertise the algorithms 1292 that the router is currently using. The following value has been 1293 defined: 1295 0: Shortest Path First (SPF) algorithm based on link metric. This 1296 is the well-known shortest path algorithm as computed by the IS-IS 1297 Decision process. Consistent with the deployed practice for link- 1298 state protocols, algorithm 0 permits any node to overwrite the SPF 1299 path with a different path based on local policy. 1301 1: Strict Shortest Path First (SPF) algorithm based on link 1302 metric. The algorithm is identical to algorithm 0 but algorithm 1 1303 requires that all nodes along the path will honor the SPF routing 1304 decision. Local policy MUST NOT alter the forwarding decision 1305 computed by algorithm 1 at the node claiming to support algorithm 1306 1. 1308 The SR-Algorithm sub-TLV is inserted into the IS-IS Router Capability 1309 TLV-242 that is defined in [RFC4971]. 1311 The Router Capability TLV specifies flags that control its 1312 advertisement. The SR-Algorithm MUST be propagated throughout the 1313 level and need not to be advertised across level boundaries. 1314 Therefore Router Capability TLV distribution flags MUST be set 1315 accordingly, i.e.: the S flag MUST be unset. 1317 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1318 time inside the Router Capability TLV. 1320 When the originating router does not advertise the SR-Algorithm sub- 1321 TLV, then all the Prefix-SID advertised by the router MUST have 1322 algorithm field set to 0. Any receiving router MUST assume SPF 1323 algorithm (i.e.: Shortest Path First). 1325 When the originating router does advertise the SR-Algorithm sub-TLV, 1326 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1328 The SR-Algorithm sub-TLV has following format: 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Type | Length | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 where: 1340 Type: TBD, suggested value 19 1342 Length: variable. 1344 Algorithm: 1 octet of algorithm Section 2.1 1346 4. Non backward compatible changes with prior versions of this document 1348 This section describes the changes that have been applied to this 1349 document that are not backward compatible with previous versions. 1351 4.1. Encoding of Multiple SRGBs 1353 Version -04 of this document introduced a change in Section 3.1 1354 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1355 and made the support of multiple SRGBs REQUIRED. 1357 The modified method consists of having a single SR-Cap Sub-TLV where 1358 all SRGBs are encoded. In previous versions (prior to version -04) 1359 of this document it was allowed to have multiple occurrences of the 1360 SR-Cap Sub-TLV. 1362 At the time of writing this document, no existing implementations are 1363 affected by the change since no implementations actually (i.e.: at 1364 the time of updating this document) encode multiple SRGBs anyway. 1366 5. IANA Considerations 1368 This documents request allocation for the following TLVs and subTLVs. 1370 5.1. Sub TLVs for Type 22,23,222 and 223 1372 This document makes the following registrations in the "sub-TLVs for 1373 TLV 22, 23, 222 and 223" registry. 1375 Type: TBD (suggested value 31) 1377 Description: Adjacency Segment Identifier 1379 TLV 22: yes 1381 TLV 23: yes 1383 TLV 222: yes 1385 TLV 223: yes 1387 Reference: This document (Section 2.2.1) 1389 Type: TBD (suggested value 32) 1391 Description: LAN Adjacency Segment Identifier 1393 TLV 22: yes 1395 TLV 23: yes 1397 TLV 222: yes 1399 TLV 223: yes 1401 Reference: This document (Section 2.2.2) 1403 5.2. Sub TLVs for Type 135,235,236 and 237 1405 This document makes the following registrations in the "sub-TLVs for 1406 TLV 135,235,236 and 237" registry. 1408 Type: TBD (suggested value 3) 1410 Description: Prefix Segment Identifier 1412 TLV 135: yes 1414 TLV 235: yes 1416 TLV 236: yes 1418 TLV 237: yes 1420 Reference: This document (Section 2.1) 1422 5.3. Sub TLVs for Type 242 1424 This document makes the following registrations in the "sub-TLVs for 1425 TLV 242" registry. 1427 Type: TBD (suggested value 2) 1429 Description: Segment Routing Capability 1431 Reference: This document (Section 3.1) 1433 Type: TBD (suggested value 19) 1435 Description: Segment Routing Algorithm 1437 Reference: This document (Section 3.2) 1439 5.4. New TLV Codepoint and Sub-TLV registry 1441 This document registers the following TLV: 1443 Type: TBD (suggested value 149) 1445 name: Segment Identifier / Label Binding 1446 IIH: no 1448 LSP: yes 1450 SNP: no 1452 Purge: no 1454 Reference: This document (Section 2.4) 1456 Type: TBD (suggested value 150) 1458 name: Multi-Topology Segment Identifier / Label Binding 1460 IIH: no 1462 LSP: yes 1464 SNP: no 1466 Purge: no 1468 Reference: This document (Section 2.5) 1470 This document creates the following sub-TLV Registry: 1472 Registry: sub-TLVs for TLV 149 and 150 1474 Registration Procedure: Expert review 1476 Reference: This document (Section 2.4) 1478 Type: TBD, suggested value 1 1480 Description: SID/Label 1482 Reference: This document (Section 2.3) 1484 Type: TBD, suggested value 3 1486 Description: Prefix-SID 1488 Reference: This document (Section 2.1) 1489 Type: TBD, suggested value 10 1491 Description: ERO Metric 1493 Reference: This document (Section 2.4.7) 1495 Type: TBD, suggested value 11 1497 Description: IPv4 ERO 1499 Reference: This document (Section 2.4.8) 1501 Type: TBD, suggested value 12 1503 Description: IPv6 ERO 1505 Reference: This document (Section 2.4.9) 1507 Type: TBD, suggested value 13 1509 Description: Unnumbered Interface-ID ERO 1511 Reference: This document (Section 2.4.10) 1513 Type: TBD, suggested value 14 1515 Description: IPv4 Backup ERO 1517 Reference: This document (Section 2.4.11) 1519 Type: TBD, suggested value 15 1521 Description: IPv6 Backup ERO 1523 Reference: This document (Section 2.4.12) 1524 Type: TBD, suggested value 16 1526 Description: Unnumbered Interface-ID Backup ERO 1528 Reference: This document (Section 2.4.13) 1530 6. Manageability Considerations 1532 TBD 1534 7. Security Considerations 1536 TBD 1538 8. Contributors 1540 The following people gave a substantial contribution to the content 1541 of this document: Les Ginsberg, Martin Horneffer, Igor Milojevic, Rob 1542 Shakir, Saku Ytti, Wim Henderickx, Steven Luong and Jesper Skriver. 1544 9. Acknowledgements 1546 We would like to thank Dave Ward, Dan Frost, Stewart Bryant and 1547 Pierre Francois for their contribution to the content of this 1548 document. 1550 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1551 earlier incarnations of the "Binding / MPLS Label TLV". 1553 10. References 1555 10.1. Normative References 1557 [I-D.ietf-isis-prefix-attributes] 1558 Ginsberg, L., Decraene, B., Filsfils, C., Litkowski, S., 1559 Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix 1560 Attributes for Extended IP and IPv6 Reachability", draft- 1561 ietf-isis-prefix-attributes-01 (work in progress), June 1562 2015. 1564 [I-D.ietf-spring-segment-routing] 1565 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1566 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1567 spring-segment-routing-03 (work in progress), May 2015. 1569 [ISO10589] 1570 International Organization for Standardization, 1571 "Intermediate system to Intermediate system intra-domain 1572 routeing information exchange protocol for use in 1573 conjunction with the protocol for providing the 1574 connectionless-mode Network Service (ISO 8473)", ISO/IEC 1575 10589:2002, Second Edition, Nov 2002. 1577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1578 Requirement Levels", BCP 14, RFC 2119, March 1997. 1580 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1581 System to Intermediate System (IS-IS) Extensions for 1582 Advertising Router Information", RFC 4971, July 2007. 1584 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1585 Topology (MT) Routing in Intermediate System to 1586 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1588 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1589 Engineering", RFC 5305, October 2008. 1591 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1592 2008. 1594 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1595 Engineering in IS-IS", RFC 6119, February 2011. 1597 10.2. Informative References 1599 [I-D.filsfils-spring-segment-routing-use-cases] 1600 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1601 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1602 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1603 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1604 spring-segment-routing-use-cases-01 (work in progress), 1605 October 2014. 1607 [I-D.ietf-spring-resiliency-use-cases] 1608 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 1609 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 1610 resiliency-use-cases-01 (work in progress), March 2015. 1612 [I-D.previdi-6man-segment-routing-header] 1613 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 1614 Segment Routing Header (SRH)", draft-previdi-6man-segment- 1615 routing-header-06 (work in progress), May 2015. 1617 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1618 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1619 Tunnels", RFC 3209, December 2001. 1621 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1622 in Resource ReSerVation Protocol - Traffic Engineering 1623 (RSVP-TE)", RFC 3477, January 2003. 1625 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1626 "Simplified Extension of Link State PDU (LSP) Space for 1627 IS-IS", RFC 5311, February 2009. 1629 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1630 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1631 Traffic Engineering", RFC 5316, December 2008. 1633 Authors' Addresses 1635 Stefano Previdi (editor) 1636 Cisco Systems, Inc. 1637 Via Del Serafico, 200 1638 Rome 00142 1639 Italy 1641 Email: sprevidi@cisco.com 1643 Clarence Filsfils 1644 Cisco Systems, Inc. 1645 Brussels 1646 BE 1648 Email: cfilsfil@cisco.com 1650 Ahmed Bashandy 1651 Cisco Systems, Inc. 1652 170, West Tasman Drive 1653 San Jose, CA 95134 1654 US 1656 Email: bashandy@cisco.com 1657 Hannes Gredler 1658 Juniper Networks, Inc. 1659 1194 N. Mathilda Ave. 1660 Sunnyvale, CA 94089 1661 US 1663 Email: hannes@juniper.net 1665 Stephane Litkowski 1666 Orange 1667 FR 1669 Email: stephane.litkowski@orange.com 1671 Bruno Decraene 1672 Orange 1673 FR 1675 Email: bruno.decraene@orange.com 1677 Jeff Tantsura 1678 Ericsson 1679 300 Holger Way 1680 San Jose, CA 95134 1681 US 1683 Email: Jeff.Tantsura@ericsson.com