idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-08.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2016) is 2750 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 1262 -- Looks like a reference, but probably isn't: '199' on line 1262 -- Looks like a reference, but probably isn't: '1000' on line 1263 -- Looks like a reference, but probably isn't: '1099' on line 1263 -- Looks like a reference, but probably isn't: '500' on line 1264 -- Looks like a reference, but probably isn't: '599' on line 1264 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-02 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-07 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 5 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: April 16, 2017 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 S. Litkowski 9 B. Decraene 10 Orange 11 J. Tantsura 12 Individual 13 October 13, 2016 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-08 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 April 16, 2017. 50 Copyright Notice 52 Copyright (c) 2016 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 . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 13 77 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 78 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 16 79 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 19 83 2.4.7. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 19 84 2.4.8. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 20 85 2.4.9. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . 24 93 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 25 94 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 25 95 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 28 96 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 29 97 4. Non backward compatible changes with prior versions of this 98 document . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 31 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 101 5.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 31 102 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 32 103 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 32 104 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 33 105 6. Manageability Considerations . . . . . . . . . . . . . . . . 35 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 108 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 111 10.2. Informative References . . . . . . . . . . . . . . . . . 38 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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 [RFC7855]. 140 2. Segment Routing Identifiers 142 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 143 defines different types of Segment Identifiers (SID). This document 144 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 145 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 147 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 149 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 150 (Prefix-SID sub-TLV). 152 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 153 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 154 be unique within a given IGP domain (when the L-flag is not set). 155 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 156 that determines the actual SID/label value inside the set of all 157 advertised SID/label ranges of a given router. A receiving router 158 uses the index to determine the actual SID/label value in order to 159 construct forwarding state to a particular destination router. 161 In many use-cases a 'stable transport' IP Address is overloaded as an 162 identifier of a given node. Because the IP Prefixes may be re- 163 advertised into other levels there may be some ambiguity (e.g. 164 Originating router vs. L1L2 router) for which node a particular IP 165 prefix serves as identifier. The Prefix-SID sub-TLV contains the 166 necessary flags to disambiguate IP Prefix to node mappings. 167 Furthermore if a given node has several 'stable transport' IP 168 addresses there are flags to differentiate those among other IP 169 Prefixes advertised from a given node. 171 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 172 and MAY be present in any of the following TLVs: 174 TLV-135 (IPv4) defined in [RFC5305]. 176 TLV-235 (MT-IPv4) defined in [RFC5120]. 178 TLV-236 (IPv6) defined in [RFC5308]. 180 TLV-237 (MT-IPv6) defined in [RFC5120]. 182 Binding-TLV defined in Section 2.4. 184 When the IP Reachability TLV is propagated across level boundaries, 185 the Prefix-SID sub-TLV SHOULD be kept. 187 The Prefix-SID sub-TLV has the following format: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | Flags | Algorithm | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | SID/Index/Label (variable) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 where: 199 Type: TBD, suggested value 3 201 Length: variable. 203 Flags: 1 octet field of following flags: 205 0 1 2 3 4 5 6 7 206 +-+-+-+-+-+-+-+-+ 207 |R|N|P|E|V|L| | 208 +-+-+-+-+-+-+-+-+ 210 where: 212 R-Flag: Re-advertisement flag. If set, then the prefix to 213 which this Prefix-SID is attached, has been propagated by the 214 router either from another level (i.e.: from level-1 to level-2 215 or the opposite) or from redistribution (e.g.: from another 216 protocol). 218 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 219 the router identified by the prefix. Typically, the N-Flag is 220 set on Prefix-SIDs attached to a router loopback address. The 221 N-Flag is set when the Prefix-SID is a Node-SID as described in 222 [I-D.ietf-spring-segment-routing]. 224 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 225 pop the Prefix-SID before delivering the packet to the node 226 that advertised the Prefix-SID. 228 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 229 the Prefix-SID originator MUST replace the Prefix-SID with a 230 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 231 IPv6) before forwarding the packet. 233 V-Flag: Value flag. If set, then the Prefix-SID carries a 234 value (instead of an index). By default the flag is UNSET. 236 L-Flag: Local Flag. If set, then the value/index carried by 237 the Prefix-SID has local significance. By default the flag is 238 UNSET. 240 Other bits: MUST be zero when originated and ignored when 241 received. 243 Algorithm: the router may use various algorithms when calculating 244 reachability to other nodes or to prefixes attached to these 245 nodes. Algorithms identifiers are defined in Section 3.2. 246 Examples of these algorithms are metric based Shortest Path First 247 (SPF), various sorts of Constrained SPF, etc. The algorithm field 248 of the Prefix-SID contains the identifier of the algorithm the 249 router has used in order to compute the reachability of the prefix 250 the Prefix-SID is associated to. 252 At origination, the Prefix-SID algorithm field MUST be set to 0 on 253 all Prefix-SID of prefixes computed using SPF algorithm (Shortest 254 Path First). On reception of the Prefix-SID sub-TLV, any non-zero 255 algorithm value MUST match what advertised in the SR-Algorithm 256 sub-TLV (Section 3.2). 258 A router receiving a Prefix-SID from a remote node and with an 259 algorithm value that such remote node has not advertised in the 260 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 261 TLV. 263 SID/Index/Label: according to the V and L flags, it contains 264 either: 266 * A 4 octet index defining the offset in the SID/Label space 267 advertised by this router using the encodings defined in 268 Section 3.1. In this case the V and L flags MUST be unset. 270 * A 3 octet local label where the 20 rightmost bits are used for 271 encoding the label value. In this case the V and L flags MUST 272 be set. 274 2.1.1. Flags 276 2.1.1.1. R and N Flags 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); 284 advertised because of redistribution (e.g.: from another 285 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 [RFC7794] also defines the N and R flags and with the same semantics 308 of the equivalent flags defined in this document. There will be a 309 transition period where both sets of flags will be used and 310 eventually only the flags of the Prefix Attributes will remain. 311 During the transition period implementations supporting the N and R 312 flags defined in this document and the N and R flags defined in 313 [RFC7794] MUST advertise and parse all flags. In case the received 314 flags have different values, the value of the flags defined in 315 [RFC7794] prevails. 317 2.1.1.2. E and P Flags 319 When calculating the outgoing label for the prefix, the router MUST 320 take into account E and P flags advertised by the next-hop router, if 321 next-hop router advertised the SID for the prefix. This MUST be done 322 regardless of next-hop router contributing to the best path to the 323 prefix or not. 325 When propagating (either from Level-1 to Level-2 or vice versa) a 326 reachability advertisement originated by another IS-IS speaker, the 327 router MUST set the P-flag and MUST clear the E-flag of the related 328 Prefix-SIDs. 330 The following behavior is associated with the settings of the E and P 331 flags: 333 o If the P-flag is not set then any upstream neighbor of the Prefix- 334 SID originator MUST pop the Prefix-SID. This is equivalent to the 335 penultimate hop popping mechanism used in the MPLS dataplane which 336 improves performance of the ultimate hop. MPLS EXP bits of the 337 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 338 being removed). If the P-flag is unset the received E-flag is 339 ignored. 341 o If the P-flag is set then: 343 * If the E-flag is not set then any upstream neighbor of the 344 Prefix-SID originator MUST keep the Prefix-SID on top of the 345 stack. This is useful when, e.g., the originator of the 346 Prefix-SID must stitch the incoming packet into a continuing 347 MPLS LSP to the final destination. This could occur at an 348 inter-area border router (prefix propagation from one area to 349 another) or at an inter-domain border router (prefix 350 propagation from one domain to another). 352 * If the E-flag is set then any upstream neighbor of the Prefix- 353 SID originator MUST replace the PrefixSID with a Prefix-SID 354 having an Explicit-NULL value. This is useful, e.g., when the 355 originator of the Prefix-SID is the final destination for the 356 related prefix and the originator wishes to receive the packet 357 with the original EXP bits. 359 2.1.2. Prefix-SID Propagation 361 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 362 gets propagated across level boundaries. 364 The level-1-2 router that propagates the Prefix-SID sub-TLV between 365 levels MUST set the R-flag. 367 If the Prefix-SID contains a global index (L and V flags unset) and 368 it is propagated as such (with L and V flags unset), the value of the 369 index MUST be preserved when propagated between levels. 371 The level-1-2 router that propagates the Prefix-SID sub-TLV between 372 levels MAY change the setting of the L and V flags in case a local 373 label value is encoded in the Prefix-SID instead of the received 374 value. 376 2.2. Adjacency Segment Identifier 378 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 379 TLV (Adj-SID sub-TLV). 381 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 382 Routing IGP-Adjacency-SID as defined in 383 [I-D.ietf-spring-segment-routing] with flags and fields that may be 384 used, in future extensions of Segment Routing, for carrying other 385 types of SIDs. 387 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 388 below: 390 TLV-22 [RFC5305] 392 TLV-222 [RFC5120] 394 TLV-23 [RFC5311] 396 TLV-223 [RFC5311] 398 TLV-141 [RFC5316] 400 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 401 neighbor. 403 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 405 The following format is defined for the Adj-SID sub-TLV: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length | Flags | Weight | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SID/Label/Index (variable) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 where: 417 Type: TBD, suggested value 31 419 Length: variable. 421 Flags: 1 octet field of following flags: 423 0 1 2 3 4 5 6 7 424 +-+-+-+-+-+-+-+-+ 425 |F|B|V|L|S| | 426 +-+-+-+-+-+-+-+-+ 428 where: 430 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 431 to an adjacency with outgoing IPv4 encapsulation. If set then 432 the Adj-SID refers to an adjacency with outgoing IPv6 433 encapsulation. 435 B-Flag: Backup flag. If set, the Adj-SID is eligible for 436 protection (e.g.: using IPFRR or MPLS-FRR) as described in 437 [I-D.ietf-spring-resiliency-use-cases]. 439 V-Flag: Value flag. If set, then the Adj-SID carries a value. 440 By default the flag is SET. 442 L-Flag: Local Flag. If set, then the value/index carried by 443 the Adj-SID has local significance. By default the flag is 444 SET. 446 S-Flag. Set Flag. When set, the S-Flag indicates that the 447 Adj-SID refers to a set of adjacencies (and therefore MAY be 448 assigned to other adjacencies as well). 450 Other bits: MUST be zero when originated and ignored when 451 received. 453 Weight: 1 octet. The value represents the weight of the Adj-SID 454 for the purpose of load balancing. The use of the weight is 455 defined in [I-D.ietf-spring-segment-routing]. 457 SID/Index/Label: according to the V and L flags, it contains 458 either: 460 * A 3 octet local label where the 20 rightmost bits are used for 461 encoding the label value. In this case the V and L flags MUST 462 be set. 464 * A 4 octet index defining the offset in the SID/Label space 465 advertised by this router using the encodings defined in 466 Section 3.1. In this case V and L flags MUST be unset. 468 * A 16 octet IPv6 address. In this case the V flag MUST be set. 469 The L flag MUST be unset if the IPv6 address is globally 470 unique. 472 An SR capable router MAY allocate an Adj-SID for each of its 473 adjacencies and SHOULD set the B-Flag when the adjacency is 474 eligible for protection (IP or MPLS). 476 An SR capable router MAY allocate more than one Adj-SID to an 477 adjacency. 479 An SR capable router MAY allocate the same Adj-SID to different 480 adjacencies. 482 Examples of use of the Adj-SID sub-TLV are described in 483 [I-D.ietf-spring-segment-routing]. and 484 [I-D.ietf-6man-segment-routing-header]. 486 The F-flag is used in order for the router to advertise the 487 outgoing encapsulation of the adjacency the Adj-SID is attached 488 to. 490 2.2.2. Adjacency Segment Identifiers in LANs 492 In LAN subnetworks, the Designated Intermediate System (DIS) is 493 elected and originates the Pseudonode-LSP (PN-LSP) including all 494 neighbors of the DIS. 496 When Segment Routing is used, each router in the LAN MAY advertise 497 the Adj-SID of each of its neighbors. Since, on LANs, each router 498 only advertises one adjacency to the DIS (and doesn't advertise any 499 other adjacency), each router advertises the set of Adj-SIDs (for 500 each of its neighbors) inside a newly defined sub-TLV part of the TLV 501 advertising the adjacency to the DIS (e.g.: TLV-22). 503 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 504 suggested value 32) containing the set of Adj-SIDs the router 505 assigned to each of its LAN neighbors. 507 The format of the LAN-Adj-SID sub-TLV is as follows: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Flags | Weight | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | System-ID (6 octets) | 517 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | SID/Label/Index (variable) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 where: 527 Type: TBD, suggested value 32 529 Length: variable. 531 Flags: 1 octet field of following flags: 533 0 1 2 3 4 5 6 7 534 +-+-+-+-+-+-+-+-+ 535 |F|B|V|L|S| | 536 +-+-+-+-+-+-+-+-+ 538 where F, B, V, L and S flags are defined in Section 2.2.1. Other 539 bits: MUST be zero when originated and ignored when received. 541 Weight: 1 octet. The value represents the weight of the Adj-SID 542 for the purpose of load balancing. The use of the weight is 543 defined in [I-D.ietf-spring-segment-routing]. 545 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 546 defined in [ISO10589]. 548 SID/Index/Label: according to the V and L flags, it contains 549 either: 551 * A 3 octet local label where the 20 rightmost bits are used for 552 encoding the label value. In this case the V and L flags MUST 553 be set. 555 * A 4 octet index defining the offset in the SID/Label space 556 advertised by this router using the encodings defined in 557 Section 3.1. In this case V and L flags MUST be unset. 559 * A 16 octet IPv6 address. In this case the V flag MUST be set. 560 The L flag MUST be unset if the IPv6 address is globally 561 unique. 563 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 565 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 566 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 567 advertisements of the adjacency to the DIS MUST be used and all 568 advertisements MUST have the same metric. 570 Each router within the level, by receiving the DIS PN LSP as well as 571 the non-PN LSP of each router in the LAN, is capable of 572 reconstructing the LAN topology as well as the set of Adj-SID each 573 router uses for each of its neighbors. 575 A label is encoded in 3 octets (in the 20 rightmost bits). 577 An index is encoded in 4 octets. 579 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined 580 in [I-D.ietf-6man-segment-routing-header]). 582 2.3. SID/Label Sub-TLV 584 The SID/Label sub-TLV is present in the following sub-TLVs defined in 585 this document: 587 Binding TLV Section 2.4. 589 SR Capability sub-TLV Section 3.1. 591 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 592 sub-TLV has the following format: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type | Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SID/Label (variable) | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 where: 604 Type: TBD, suggested value 1 606 Length: variable 608 SID/Label: if length is set to 3 then the 20 rightmost bits 609 represent a MPLS label. 611 2.4. SID/Label Binding TLV 613 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 614 domain. There are multiple uses of the SID/Label Binding TLV: 616 o The router may advertise a SID/Label binding to a FEC along with 617 at least a single 'nexthop style' anchor. The protocol supports 618 more than one 'nexthop style' anchor to be attached to a SID/Label 619 binding, which results into a simple path description language. 620 In analogy to RSVP the terminology for this is called an 'Explicit 621 Route Object' (ERO). Since ERO style path notation allows to 622 anchor SID/label bindings to both link and node IP addresses any 623 label switched path, can be described. Furthermore also SID/Label 624 Bindings from external protocols can get easily re-advertised. 626 o The SID/Label Binding TLV may be used for advertising SID/Label 627 Bindings and their associated Primary and Backup paths. In one 628 single TLV either a primary ERO Path, a backup ERO Path or both 629 are advertised. If a router wants to advertise multiple parallel 630 paths then it can generate several TLVs for the same Prefix/FEC. 631 Each occurrence of a Binding TLV with respect with a given FEC 632 Prefix has accumulating and not canceling semantics. Due the 633 space constraints in the 8-Bit IS-IS TLVs an originating router 634 MAY encode a primary ERO path in one SID/Label Binding TLV and the 635 backup ERO path in a second SID/Label Binding TLV. Note that the 636 FEC Prefix and SID/Label sub-TLV MUST be identical in both TLVs. 638 o The SID/Label Binding TLV may also be used in order to advertise 639 prefixes to SID/Label mappings. This functionality is called the 640 'Mapping Server' and it's used when, in a heterogeneous network, 641 not all nodes are capable of advertising their own SIDs/Labels. 642 When the SID/Label Binding TLV is used by the Mapping Server in 643 order to advertise prefix to SID/label mappings, the index/label 644 MUST include the Prefix-SID SubTLV (Section 2.1). 646 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 647 the following format: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Type | Length | Flags | Weight | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Range | Prefix Length | FEC Prefix | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 // FEC Prefix (continued, variable) // 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | SubTLVs (variable) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 1: SID/Label Binding TLV format 663 o Type: TBD, suggested value 149 665 o Length: variable. 667 o 1 octet of flags 669 o 1 octet of Weight 670 o 2 octets of Range 672 o 1 octet of Prefix Length 674 o 0-16 octets of FEC Prefix 676 o sub-TLVs, where each sub-TLV consists of a sequence of: 678 * 1 octet of sub-TLV type 680 * 1 octet of length of the value field of the sub-TLV 682 * 0-243 octets of value 684 2.4.1. Flags 686 Flags: 1 octet field of following flags: 688 0 1 2 3 4 5 6 7 689 +-+-+-+-+-+-+-+-+ 690 |F|M|S|D|A| | 691 +-+-+-+-+-+-+-+-+ 693 where: 695 F-Flag: Address Family flag. If unset, then the Prefix FEC 696 carries an IPv4 Prefix. If set then the Prefix FEC carries an 697 IPv6 Prefix. 699 M-Flag: Mirror Context flag. Set if the advertised SID/path 700 corresponds to a mirrored context. The use of the M flag is 701 described in [I-D.ietf-spring-segment-routing]. 703 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 704 the entire routing domain. If the S flag is not set, the SID/ 705 Label Binding TLV MUST NOT be leaked between levels. This bit 706 MUST NOT be altered during the TLV leaking. 708 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 709 level-1, the D bit MUST be set. Otherwise, this bit MUST be 710 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 711 leaked from level-1 to level-2. This is to prevent TLV looping 712 across levels. 714 A-Flag: Attached flag. The originator of the SID/Label Binding 715 TLV MAY set the A bit in order to signal that the prefixes and 716 SIDs advertised in the SID/Label Binding TLV are directly 717 connected to their originators. The mechanisms through which the 718 originator of the SID/Label Binding TLV can figure out if a prefix 719 is attached or not are outside the scope of this document (e.g.: 720 through explicit configuration). If the Binding TLV is leaked to 721 other areas/levels the A-flag MUST be cleared. 723 An implementation MAY decide not to honor the S-flag in order not 724 to leak Binding TLV's between levels (for policy reasons). In all 725 cases, the D flag MUST always be set by any router leaking the 726 Binding TLV from level-2 into level-1 and MUST be checked when 727 propagating the Binding TLV from level-1 into level-2. If the D 728 flag is set, the Binding TLV MUST NOT be propagated into level-2. 730 Other bits: MUST be zero when originated and ignored when 731 received. 733 2.4.2. Weight 735 Weight: 1 octet: The value represents the weight of the path for the 736 purpose of load balancing. The use of the weight is defined in 737 [I-D.ietf-spring-segment-routing]. 739 2.4.3. Range 741 The 'Range' field provides the ability to specify a range of 742 addresses and their associated Prefix SIDs. This functionality is 743 called "Mapping Server". It is essentially a compression scheme to 744 distribute a continuous Prefix and their continuous, corresponding 745 SID/Label Block. If a single SID is advertised then the range field 746 MUST be set to one. For range advertisements > 1, the number of 747 addresses that need to be mapped into a Prefix-SID and the starting 748 value of the Prefix-SID range. 750 Example 1: if the following router addresses (loopback addresses) 751 need to be mapped into the corresponding Prefix SID indexes. 753 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 754 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 755 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 756 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 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 |0|0| | Weight | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Range = 4 | /32 | 192 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | .0 | .2 | .1 |Prefix-SID Type| 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | sub-TLV Length| Flags | Algorithm | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | 1 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Example-2: If the following prefixes need to be mapped into the 772 corresponding Prefix-SID indexes: 774 10.1.1/24, Prefix-SID: Index 51 775 10.1.2/24, Prefix-SID: Index 52 776 10.1.3/24, Prefix-SID: Index 53 777 10.1.4/24, Prefix-SID: Index 54 778 10.1.5/24, Prefix-SID: Index 55 779 10.1.6/24, Prefix-SID: Index 56 780 10.1.7/24, Prefix-SID: Index 57 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Type | Length |0|0| | Weight | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Range = 7 | /24 | 10 | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Flags | Algorithm | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 51 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 It is not expected that a network operator will be able to keep fully 797 continuous FEC Prefix / SID/Index mappings. In order to support 798 noncontinuous mapping ranges an implementation MAY generate several 799 instances of Binding TLVs. 801 For example if a router wants to advertise the following ranges: 803 Range 16: { 192.0.2.1-15, Index 1-15 } 804 Range 6: { 192.0.2.22-27, Index 22-27 } 806 Range 41: { 192.0.2.44-84, Index 80-120 } 808 A router would need to advertise three instances of the Binding TLV. 810 2.4.4. Prefix Length, Prefix 812 The 'FEC Prefix' represents the Forwarding equivalence class at the 813 tail-end of the advertised path. The 'FEC Prefix' does not need to 814 correspond to a routable prefix of the originating node. 816 The 'Prefix Length' field contains the length of the prefix in bits. 817 Only the most significant octets of the Prefix FEC are encoded. I.e. 818 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 819 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 820 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 821 prefix length 113 up to 128. 823 2.4.5. Mapping Server Prefix-SID 825 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 826 and contains the SID/index/label value associated with the prefix and 827 range. The Prefix-SID SubTLV MUST be used when the SID/Label Binding 828 TLV is used by the Mapping Server (i.e.: advertising one or a range 829 of prefixes and their associated SIDs/Labels). 831 A node receiving a MS entry for a prefix MUST check the existence of 832 such prefix in its link-state database prior to consider and use the 833 associated SID. 835 2.4.5.1. Prefix-SID Flags 837 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 838 MAY advertise a mapping with the N flag set when the prefix being 839 mapped is known in the link-state topology with a mask length of 32 840 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 841 mechanisms through which the operator defines that a prefix 842 represents a node are outside the scope of this document (typically 843 it will be through configuration). 845 The other flags defined in Section 2.1 are not used by the Mapping 846 Server and MUST be ignored at reception. 848 2.4.5.2. PHP Behavior when using Mapping Server Advertisements 850 As the mapping server does not specify the originator of a prefix 851 advertisement it is not possible to determine PHP behavior solely 852 based on the Mapping Server Advertisement. However, if additional 853 information is available PHP behavior may safely be done. The 854 required information consists of: 856 o A prefix reachability advertisement for the prefix has been 857 received which includes the Extended Reachability Attribute Flags 858 sub-TLV ([RFC7794]). 860 o X and R flags are both set to 0 in the Extended Reachability 861 Attribute Flags sub-TLV. 863 In the absence of an Extended Reachability Attribute Flags sub-TLV 864 ([RFC7794]) the A flag in the binding TLV indicates that the 865 originator of a prefix reachability advertisement is directly 866 connected to the prefix and thus PHP MUST be done by the neighbors of 867 the router originating the prefix reachability advertisement. Note 868 that A-flag is only valid in the original area in which the Binding 869 TLV is advertised. 871 2.4.5.3. Prefix-SID Algorithm 873 The algorithm field contains the identifier of the algorithm the 874 router MUST use in order to compute reachability to the range of 875 prefixes. Use of the algorithm field is described in Section 2.1. 877 2.4.6. SID/Label Sub-TLV 879 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 880 SID/Label value as defined in Section 2.3. It MAY be present in the 881 SID/Label Binding TLV. 883 2.4.7. ERO Metric sub-TLV 885 ERO Metric sub-TLV (Type: TBD, suggested value 10) is a sub-TLV of 886 the SID/Label Binding TLV. 888 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 889 to compare the cost of a given source/destination path. A router MAY 890 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 891 SHOULD be set to the cumulative IGP or TE path cost of the advertised 892 ERO. Since manipulation of the Metric field may attract or distract 893 traffic from and to the advertised segment it MAY be manually 894 overridden. 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Type | Length | Metric | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Metric (continued) | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 ERO Metric sub-TLV format 906 where: 908 Type: TBD, suggested value 10 910 Length: 4 912 Metric: 4 bytes 914 2.4.8. IPv4 ERO subTLV 916 The IPv4 ERO subTLV (Type: TBD, suggested value 11) describes a path 917 segment using IPv4 address style of encoding. Its semantics have 918 been borrowed from [RFC3209]. 920 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 921 set, then the value of the attribute is 'loose.' Otherwise, the 922 value of the attribute is 'strict.' 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Type | Length |L| Reserved | IPv4 address | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | IPv4 address (continued) | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Figure 2: IPv4 ERO subTLV format 934 2.4.9. IPv6 ERO subTLV 936 The IPv6 ERO subTLV (Type: TBD, suggested value 12) describes a path 937 segment using IPv6 Address style of encoding. Its semantics have 938 been borrowed from [RFC3209]. 940 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 941 set, then the value of the attribute is 'loose.' Otherwise, the 942 value of the attribute is 'strict.' 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length |L| Reserved | IPv6 address | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | IPv6 Address (continued) | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | IPv6 Address (continued) | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | IPv6 Address (continued) | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | IPv6 Address (continued) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Figure 3: IPv6 ERO subTLV format 959 2.4.10. Unnumbered Interface ID ERO subTLV 961 The appearance and semantics of the 'Unnumbered Interface ID' have 962 been borrowed from Section 4 [RFC3477]. 964 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 965 13) describes a path segment that spans over an unnumbered interface. 966 Unnumbered interfaces are referenced using the interface index. 967 Interface indices are assigned local to the router and therefore not 968 unique within a domain. All elements in an ERO path need to be 969 unique within a domain and hence need to be disambiguated using a 970 domain unique Router-ID. 972 The 'Router-ID' field contains the router ID of the router which has 973 assigned the 'Interface ID' field. Its purpose is to disambiguate 974 the 'Interface ID' field from other routers in the domain. 976 IS-IS supports two Router-ID formats: 978 o (TLV 134, 32-Bit format) [RFC5305] 980 o (TLV 140, 128-Bit format) [RFC6119] 982 The actual Router-ID format gets derived from the 'Length' field. 984 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 986 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 988 The 'Interface ID' is the identifier assigned to the link by the 989 router specified by the router ID. 991 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 992 set, then the value of the attribute is 'loose.' Otherwise, the 993 value of the attribute is 'strict.' 995 0 1 2 3 996 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 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Type | Length |L| Reserved | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 // Router ID (32 or 128 bits) // 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Interface ID (32 bits) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Figure 4: Unnumbered Interface ID ERO subTLV format 1007 2.4.11. IPv4 Backup ERO subTLV 1009 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 14) describes 1010 a Backup path segment using IPv4 Address style of encoding. Its 1011 appearance and semantics have been borrowed from [RFC3209]. 1013 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1014 set, then the value of the attribute is 'loose.' Otherwise, the 1015 value of the attribute is 'strict.' 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Type | Length |L| Reserved | IPv4 address | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | IPv4 address (continued) | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Figure 5: IPv4 Backup ERO subTLV format 1027 2.4.12. IPv6 Backup ERO subTLV 1029 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 15) describes 1030 a Backup path segment using IPv6 Address style of encoding. Its 1031 appearance and semantics have been borrowed from [RFC3209]. 1033 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1034 set, then the value of the attribute is 'loose.' Otherwise, the 1035 value of the attribute is 'strict.' 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type | Length |L| Reserved | IPv6 address | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | IPv6 Address (continued) | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | IPv6 Address (continued) | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | IPv6 Address (continued) | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | IPv6 Address (continued) | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 6: IPv6 Backup ERO subTLV format 1052 2.4.13. Unnumbered Interface ID Backup ERO subTLV 1054 The appearance and semantics of the 'Unnumbered Interface ID' have 1055 been borrowed from Section 4 [RFC3477]. 1057 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 1058 value 16) describes a Backup LSP path segment that spans over an 1059 unnumbered interface. Unnumbered interfaces are referenced using the 1060 interface index. Interface indices are assigned local to the router 1061 and therefore not unique within a domain. All elements in an ERO 1062 path need to be unique within a domain and hence need to be 1063 disambiguated using a domain unique Router-ID. 1065 The 'Router-ID' field contains the router ID of the router which has 1066 assigned the 'Interface ID' field. Its purpose is to disambiguate 1067 the 'Interface ID' field from other routers in the domain. 1069 IS-IS supports two Router-ID formats: 1071 o (TLV 134, 32-Bit format) [RFC5305] 1073 o (TLV 140, 128-Bit format) [RFC6119] 1075 The actual Router-ID format gets derived from the 'Length' field. 1077 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1079 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1081 The 'Interface ID' is the identifier assigned to the link by the 1082 router specified by the router ID. 1084 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1085 set, then the value of the attribute is 'loose.' Otherwise, the 1086 value of the attribute is 'strict.' 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Type | Length |L| Reserved | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 // Router ID (32 or 128 bits) // 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Interface ID (32 bits) | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 1100 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics 1102 All 'ERO' and 'Backup ERO' information represents an ordered set 1103 which describes the segments of a path. The last ERO subTLV 1104 describes the segment closest to the egress point of the path. 1105 Contrary the first ERO subTLV describes the first segment of a path. 1106 If a router extends or stitches a label switched path it MUST prepend 1107 the new segments path information to the ERO list. The same ordering 1108 applies for the Backup ERO labels. An implementation SHOULD first 1109 encode all primary path EROs followed by the bypass EROs. 1111 2.5. Multi-Topology SID/Label Binding TLV 1113 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 1114 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 1115 has the same format as the SID/Label Binding TLV defined in 1116 Section 2.4 with the difference consisting of a Multitopology 1117 Identifier (MTID) as defined here below: 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Type | Length | MTID | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Flags | Weight | Range | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Prefix Length | FEC Prefix | FEC Prefix (variable) | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | SubTLVs (variable) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 Figure 8: Multi-Topology SID/Label Binding TLV format 1133 where: 1135 Type: TBD, suggested value 150 1137 Length: variable 1139 MTID is the multitopology identifier defined as: 1141 0 1 1142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | RESVD | MTID | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 RESVD: reserved bits. MUST be reset on transmission and 1148 ignored on receive. 1150 MTID: a 12-bit field containing the non-zero ID of the topology 1151 being announced. The TLV MUST be ignored if the ID is zero. 1152 This is to ensure the consistent view of the standard unicast 1153 topology. 1155 The other fields and SubTLVs are defined in Section 2.4. 1157 3. Router Capabilities 1159 3.1. SR-Capabilities Sub-TLV 1161 Segment Routing requires each router to advertise its SR data-plane 1162 capability and the range of MPLS label values it uses for Segment 1163 Routing in the case where global SIDs are allocated (i.e.: global 1164 indexes). Data-plane capabilities and label ranges are advertised 1165 using the newly defined SR-Capabilities sub-TLV inserted into the IS- 1166 IS Router Capability TLV-242 that is defined in [RFC4971]. 1168 The Router Capability TLV specifies flags that control its 1169 advertisement. The SR Capabilities sub-TLV MUST be propagated 1170 throughout the level and SHOULD NOT be advertised across level 1171 boundaries. Therefore Router Capability TLV distribution flags 1172 SHOULD be set accordingly, i.e.: the S flag in the Router Capability 1173 TLV ([RFC4971]) MUST be unset. 1175 The SR Capabilities sub-TLV has following format: 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Type | Length | Flags | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Range | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 // SID/Label Sub-TLV (variable) // 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 Type: TBD, suggested value 2 1191 Length: variable. 1193 Flags: 1 octet of flags. The following are defined: 1195 0 1 2 3 4 5 6 7 1196 +-+-+-+-+-+-+-+-+ 1197 |I|V|H| | 1198 +-+-+-+-+-+-+-+-+ 1200 where: 1202 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 1203 processing SR MPLS encapsulated IPv4 packets on all interfaces. 1205 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 1206 processing SR MPLS encapsulated IPv6 packets on all interfaces. 1208 H-Flag: SR-IPv6 flag. If set, then the router is capable of 1209 processing the IPv6 Segment Routing Header on all interfaces as 1210 defined in [I-D.ietf-6man-segment-routing-header]. 1212 One or more SRGB Descriptor entries, each of which have the 1213 following format: 1215 Range: 3 octets. 1217 SID/Label sub-TLV (as defined in Section 2.3). 1219 SID/Label sub-TLV contains the first value of the SRGB while the 1220 range contains the number of SRGB elements. The range value MUST be 1221 higher than 0. 1223 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 1224 but a router MUST NOT advertise more than one SR-Capabilities sub- 1225 TLV. When multiple SR-Capabilities sub-TLVs are received from a 1226 given router the behavior of the receiving system is undefined. 1228 When multiple SRGB Descriptors are advertised the entries define an 1229 ordered set of ranges on which a SID index is to be applied. For 1230 this reason changing the order in which the descriptors are 1231 advertised will have a disruptive effect on forwarding. 1233 When a router adds a new SRGB Descriptor to an existing SR- 1234 Capabilities sub-TLV the new Descriptor SHOULD add the newly 1235 configured block at the end of the sub-TLV and SHOULD NOT change the 1236 order of previously advertised blocks. Changing the order of the 1237 advertised descriptors will create label churn in the FIB and 1238 blackhole / misdirect some traffic during the IGP convergence. In 1239 particular, if a range which is not the last is extended it's 1240 preferable to add a new range rather than extending the previously 1241 advertised range. 1243 The originating router MUST ensure the order is same after a graceful 1244 restart (using checkpointing, non-volatile storage or any other 1245 mechanism) in order to guarantee the same order before and after GR. 1247 The originating router MUST NOT advertise overlapping ranges. 1249 When a router receives multiple overlapping ranges, it MUST conform 1250 to the procedures defined in [I-D.ietf-spring-conflict-resolution]. 1252 Here follows an example of advertisement of multiple ranges: 1254 The originating router advertises following ranges: 1255 SR-Cap: range: 100, SID value: 100 1256 SR-Cap: range: 100, SID value: 1000 1257 SR-Cap: range: 100, SID value: 500 1259 The receiving routers concatenate the ranges in the received 1260 order and build the SRGB as follows: 1262 SRGB = [100, 199] 1263 [1000, 1099] 1264 [500, 599] 1266 The indexes span multiple ranges: 1268 index=0 means label 100 1269 ... 1270 index 99 means label 199 1271 index 100 means label 1000 1272 index 199 means label 1099 1273 ... 1274 index 200 means label 500 1275 ... 1277 3.2. SR-Algorithm Sub-TLV 1279 The router may use various algorithms when calculating reachability 1280 to other nodes or to prefixes attached to these nodes. Examples of 1281 these algorithms are metric based Shortest Path First (SPF), various 1282 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1283 suggested value 19) allows the router to advertise the algorithms 1284 that the router is currently using. The following value has been 1285 defined: 1287 0: Shortest Path First (SPF) algorithm based on link metric. This 1288 is the well-known shortest path algorithm as computed by the IS-IS 1289 Decision process. Consistent with the deployed practice for link- 1290 state protocols, algorithm 0 permits any node to overwrite the SPF 1291 path with a different path based on local policy. 1293 1: Strict Shortest Path First (SPF) algorithm based on link 1294 metric. The algorithm is identical to algorithm 0 but algorithm 1 1295 requires that all nodes along the path will honor the SPF routing 1296 decision. Local policy MUST NOT alter the forwarding decision 1297 computed by algorithm 1 at the node claiming to support algorithm 1298 1. 1300 The SR-Algorithm sub-TLV is inserted into the IS-IS Router Capability 1301 TLV-242 that is defined in [RFC4971]. 1303 The Router Capability TLV specifies flags that control its 1304 advertisement. The SR-Algorithm MUST be propagated throughout the 1305 level and need not to be advertised across level boundaries. 1306 Therefore Router Capability TLV distribution flags MUST be set 1307 accordingly, i.e.: the S flag MUST be unset. 1309 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1310 time inside the Router Capability TLV. 1312 When the originating router does not advertise the SR-Algorithm sub- 1313 TLV, then all the Prefix-SID advertised by the router MUST have 1314 algorithm field set to 0. Any receiving router MUST assume SPF 1315 algorithm (i.e.: Shortest Path First). 1317 When the originating router does advertise the SR-Algorithm sub-TLV, 1318 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1320 The SR-Algorithm sub-TLV has following format: 1322 0 1 2 3 1323 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 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Type | Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 where: 1332 Type: TBD, suggested value 19 1334 Length: variable. 1336 Algorithm: 1 octet of algorithm Section 2.1 1338 3.3. SR Local Block Sub-TLV 1340 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1341 node has reserved for local SIDs. Local SIDs are used, e.g., for 1342 Adjacency-SIDs, and may also be allocated by other components than 1343 IS-IS protocol. As an example, an application or a controller may 1344 instruct the router to allocate a specific local SID. Therefore, in 1345 order for such applications or controllers to know what are the local 1346 SIDs available in the router, it is required that the router 1347 advertises its SRLB. 1349 The SRLB Sub-TLV is used for that purpose and has following format: 1351 0 1 2 3 1352 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 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Type | Length | Flags | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Range | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 // SID/Label Sub-TLV (variable) // 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 Type: TBD, suggested value 22. 1365 Length: variable. 1367 Flags: 1 octet of flags. None are defined at this stage. 1369 One or more SRLB Descriptor entries, each of which have the 1370 following format: 1372 Range: 3 octets. 1374 SID/Label sub-TLV (as defined in Section 2.3). 1376 SID/Label sub-TLV contains the first value of the SRLB while the 1377 range contains the number of SRLB elements. The range value MUST be 1378 higher than 0. 1380 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1381 router MUST NOT advertise more than one SRLB sub-TLV. When multiple 1382 SRLB sub-TLVs are received from a given router the behavior of the 1383 receiving system is undefined. 1385 The originating router MUST NOT advertise overlapping ranges. 1387 It is important to note that each time a SID from the SRLB is 1388 allocated, it SHOULD also be reported to all components (e.g.: 1389 controller or applications) in order for these components to have an 1390 up-to-date view of the current SRLB allocation and in order to avoid 1391 collision between allocation instructions. 1393 Within the context of IS-IS, the reporting of local SIDs is done 1394 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1395 reporting of allocated local SIDs may also be done through other 1396 means and protocols which mechanisms are outside the scope of this 1397 document. 1399 A router advertising the SRLB TLV may also have other label ranges, 1400 outside the SRLB, for its local allocation purposes which are NOT 1401 advertised in the SRLB. For example, it is possible that an 1402 Adjacency-SID is allocated using a local label not part of the SRLB. 1404 4. Non backward compatible changes with prior versions of this document 1406 This section describes the changes that have been applied to this 1407 document that are not backward compatible with previous versions. 1409 4.1. Encoding of Multiple SRGBs 1411 Version -04 of this document introduced a change in Section 3.1 1412 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1413 and made the support of multiple SRGBs REQUIRED. 1415 The modified method consists of having a single SR-Cap Sub-TLV where 1416 all SRGBs are encoded. In previous versions (prior to version -04) 1417 of this document it was allowed to have multiple occurrences of the 1418 SR-Cap Sub-TLV. 1420 At the time of writing this document, no existing implementations are 1421 affected by the change since no implementations actually (i.e.: at 1422 the time of updating this document) encode multiple SRGBs anyway. 1424 5. IANA Considerations 1426 This documents request allocation for the following TLVs and subTLVs. 1428 5.1. Sub TLVs for Type 22,23,222 and 223 1430 This document makes the following registrations in the "sub-TLVs for 1431 TLV 22, 23, 222 and 223" registry. 1433 Type: TBD (suggested value 31) 1435 Description: Adjacency Segment Identifier 1437 TLV 22: yes 1439 TLV 23: yes 1441 TLV 222: yes 1443 TLV 223: yes 1444 Reference: This document (Section 2.2.1) 1446 Type: TBD (suggested value 32) 1448 Description: LAN Adjacency Segment Identifier 1450 TLV 22: yes 1452 TLV 23: yes 1454 TLV 222: yes 1456 TLV 223: yes 1458 Reference: This document (Section 2.2.2) 1460 5.2. Sub TLVs for Type 135,235,236 and 237 1462 This document makes the following registrations in the "sub-TLVs for 1463 TLV 135,235,236 and 237" registry. 1465 Type: TBD (suggested value 3) 1467 Description: Prefix Segment Identifier 1469 TLV 135: yes 1471 TLV 235: yes 1473 TLV 236: yes 1475 TLV 237: yes 1477 Reference: This document (Section 2.1) 1479 5.3. Sub TLVs for Type 242 1481 This document makes the following registrations in the "sub-TLVs for 1482 TLV 242" registry. 1484 Type: TBD (suggested value 2) 1486 Description: Segment Routing Capability 1487 Reference: This document (Section 3.1) 1489 Type: TBD (suggested value 19) 1491 Description: Segment Routing Algorithm 1493 Reference: This document (Section 3.2) 1495 5.4. New TLV Codepoint and Sub-TLV registry 1497 This document registers the following TLV: 1499 Type: TBD (suggested value 149) 1501 name: Segment Identifier / Label Binding 1503 IIH: no 1505 LSP: yes 1507 SNP: no 1509 Purge: no 1511 Reference: This document (Section 2.4) 1513 Type: TBD (suggested value 150) 1515 name: Multi-Topology Segment Identifier / Label Binding 1517 IIH: no 1519 LSP: yes 1521 SNP: no 1523 Purge: no 1525 Reference: This document (Section 2.5) 1527 This document creates the following sub-TLV Registry: 1529 Registry: sub-TLVs for TLV 149 and 150 1531 Registration Procedure: Expert review 1532 Reference: This document (Section 2.4) 1534 Type: TBD, suggested value 1 1536 Description: SID/Label 1538 Reference: This document (Section 2.3) 1540 Type: TBD, suggested value 3 1542 Description: Prefix-SID 1544 Reference: This document (Section 2.1) 1546 Type: TBD, suggested value 10 1548 Description: ERO Metric 1550 Reference: This document (Section 2.4.7) 1552 Type: TBD, suggested value 11 1554 Description: IPv4 ERO 1556 Reference: This document (Section 2.4.8) 1558 Type: TBD, suggested value 12 1560 Description: IPv6 ERO 1562 Reference: This document (Section 2.4.9) 1564 Type: TBD, suggested value 13 1566 Description: Unnumbered Interface-ID ERO 1568 Reference: This document (Section 2.4.10) 1569 Type: TBD, suggested value 14 1571 Description: IPv4 Backup ERO 1573 Reference: This document (Section 2.4.11) 1575 Type: TBD, suggested value 15 1577 Description: IPv6 Backup ERO 1579 Reference: This document (Section 2.4.12) 1581 Type: TBD, suggested value 16 1583 Description: Unnumbered Interface-ID Backup ERO 1585 Reference: This document (Section 2.4.13) 1587 6. Manageability Considerations 1589 TBD 1591 7. Security Considerations 1593 TBD 1595 8. Acknowledgements 1597 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1598 Francois and Jesper Skrivers for their contribution to the content of 1599 this document. 1601 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1602 earlier definition of the "Binding / MPLS Label TLV". 1604 9. Contributors 1606 The following people gave a substantial contribution to the content 1607 of this document and should be considered as co-authors: 1609 Les Ginsberg 1610 Cisco Systems Inc. 1611 US 1612 Email: ginsberg@cisco.com 1614 Martin Horneffer 1615 Deutsche Telekom 1616 DE 1618 Email: Martin.Horneffer@telekom.de 1620 Wim Henderickx 1621 Alcatel-Lucent 1622 BE 1624 Email: wim.henderickx@alcatel-lucent.com 1626 Edward Crabbe 1627 Individual 1628 US 1630 Email: edward.crabbe@gmail.com 1632 Rob Shakir 1633 Individual 1634 UK 1636 Email: rjs@rob.sh 1638 Igor Milojevic 1639 Individual 1640 RS 1642 Email: milojevicigor@gmail.com 1644 Saku Ytti 1645 TDC 1646 FI 1648 Email: saku@ytti.fi 1650 Steven Luong 1651 Cisco Systems Inc. 1652 US 1653 Email: sluong@cisco.com 1655 10. References 1657 10.1. Normative References 1659 [I-D.ietf-spring-conflict-resolution] 1660 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1661 "Segment Routing Conflict Resolution", draft-ietf-spring- 1662 conflict-resolution-01 (work in progress), June 2016. 1664 [I-D.ietf-spring-segment-routing] 1665 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1666 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1667 spring-segment-routing-09 (work in progress), July 2016. 1669 [ISO10589] 1670 International Organization for Standardization, 1671 "Intermediate system to Intermediate system intra-domain 1672 routeing information exchange protocol for use in 1673 conjunction with the protocol for providing the 1674 connectionless-mode Network Service (ISO 8473)", ISO/ 1675 IEC 10589:2002, Second Edition, Nov 2002. 1677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1678 Requirement Levels", BCP 14, RFC 2119, 1679 DOI 10.17487/RFC2119, March 1997, 1680 . 1682 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 1683 "Intermediate System to Intermediate System (IS-IS) 1684 Extensions for Advertising Router Information", RFC 4971, 1685 DOI 10.17487/RFC4971, July 2007, 1686 . 1688 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1689 Topology (MT) Routing in Intermediate System to 1690 Intermediate Systems (IS-ISs)", RFC 5120, 1691 DOI 10.17487/RFC5120, February 2008, 1692 . 1694 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1695 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1696 2008, . 1698 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1699 DOI 10.17487/RFC5308, October 2008, 1700 . 1702 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1703 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1704 February 2011, . 1706 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1707 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1708 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1709 March 2016, . 1711 10.2. Informative References 1713 [I-D.ietf-6man-segment-routing-header] 1714 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1715 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1716 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1717 segment-routing-header-02 (work in progress), September 1718 2016. 1720 [I-D.ietf-spring-resiliency-use-cases] 1721 Filsfils, C., Previdi, S., Francois, P., Decraene, B., and 1722 R. Shakir, "Resiliency use cases in SPRING networks", 1723 draft-ietf-spring-resiliency-use-cases-07 (work in 1724 progress), October 2016. 1726 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1727 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1728 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1729 . 1731 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1732 in Resource ReSerVation Protocol - Traffic Engineering 1733 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1734 . 1736 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1737 Shand, "Simplified Extension of Link State PDU (LSP) Space 1738 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1739 . 1741 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1742 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1743 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1744 December 2008, . 1746 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1747 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1748 Packet Routing in Networking (SPRING) Problem Statement 1749 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1750 2016, . 1752 Authors' Addresses 1754 Stefano Previdi (editor) 1755 Cisco Systems, Inc. 1756 Via Del Serafico, 200 1757 Rome 00142 1758 Italy 1760 Email: sprevidi@cisco.com 1762 Clarence Filsfils 1763 Cisco Systems, Inc. 1764 Brussels 1765 BE 1767 Email: cfilsfil@cisco.com 1769 Ahmed Bashandy 1770 Cisco Systems, Inc. 1771 170, West Tasman Drive 1772 San Jose, CA 95134 1773 US 1775 Email: bashandy@cisco.com 1777 Hannes Gredler 1778 RtBrick Inc. 1780 Email: hannes@rtbrick.com 1782 Stephane Litkowski 1783 Orange 1784 FR 1786 Email: stephane.litkowski@orange.com 1787 Bruno Decraene 1788 Orange 1789 FR 1791 Email: bruno.decraene@orange.com 1793 Jeff Tantsura 1794 Individual 1796 Email: jefftant@gmail.com