idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-10.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 (February 27, 2017) is 2608 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 1280 -- Looks like a reference, but probably isn't: '199' on line 1280 -- Looks like a reference, but probably isn't: '1000' on line 1281 -- Looks like a reference, but probably isn't: '1099' on line 1281 -- Looks like a reference, but probably isn't: '500' on line 1282 -- Looks like a reference, but probably isn't: '599' on line 1282 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-05 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-08 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 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: August 31, 2017 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 S. Litkowski 9 B. Decraene 10 Orange 11 J. Tantsura 12 Individual 13 February 27, 2017 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-10 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 August 31, 2017. 50 Copyright Notice 52 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 14 77 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 78 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 17 79 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 17 80 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 18 81 2.4.5. Mapping Server Prefix-SID . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 21 85 2.4.9. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 21 86 2.4.10. Unnumbered Interface ID ERO subTLV . . . . . . . . . 22 87 2.4.11. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 23 88 2.4.12. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 23 89 2.4.13. Unnumbered Interface ID Backup ERO subTLV . . . . . . 24 90 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path 91 semantics . . . . . . . . . . . . . . . . . . . . . . 25 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 96 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 30 97 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 31 98 4. Non backward compatible changes with prior versions of this 99 document . . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 32 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 102 5.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 32 103 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 33 104 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 33 105 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 34 106 6. Manageability Considerations . . . . . . . . . . . . . . . . 36 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 109 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 112 10.2. Informative References . . . . . . . . . . . . . . . . . 39 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 115 1. Introduction 117 Segment Routing (SR) allows for a flexible definition of end-to-end 118 paths within IGP topologies by encoding paths as sequences of 119 topological sub-paths, called "segments". These segments are 120 advertised by the link-state routing protocols (IS-IS and OSPF). Two 121 types of segments are defined, Prefix segments and Adjacency 122 segments. Prefix segments represent an ecmp-aware shortest-path to a 123 prefix, as per the state of the IGP topology. Adjacency segments 124 represent a hop over a specific adjacency between two nodes in the 125 IGP. A prefix segment is typically a multi-hop path while an 126 adjacency segment, in most of the cases, is a one-hop path. SR's 127 control-plane can be applied to both IPv6 and MPLS data-planes, and 128 do not require any additional signaling (other than the regular IGP). 129 For example, when used in MPLS networks, SR paths do not require any 130 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 131 of LSPs established with RSVP or LDP. 133 This draft describes the necessary IS-IS extensions that need to be 134 introduced for Segment Routing. 136 Segment Routing architecture is described in 137 [I-D.ietf-spring-segment-routing]. 139 Segment Routing use cases are described in [RFC7855]. 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 (Extended IPv4 reachability) defined in [RFC5305]. 177 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 179 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 181 TLV-237 (Multitopology IPv6 IP Reachability) 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., a '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 [RFC7794] also defines the N and R flags and with the same semantics 309 of the equivalent flags defined in this document. There will be a 310 transition period where both sets of flags will be used and 311 eventually only the flags of the Prefix Attributes will remain. 312 During the transition period implementations supporting the N and R 313 flags defined in this document and the N and R flags defined in 314 [RFC7794] MUST advertise and parse all flags. In case the received 315 flags have different values, the value of the flags defined in 316 [RFC7794] prevails. 318 2.1.1.2. E and P Flags 320 When calculating the outgoing label for the prefix, the router MUST 321 take into account E and P flags advertised by the next-hop router, if 322 next-hop router advertised the SID for the prefix. This MUST be done 323 regardless of next-hop router contributing to the best path to the 324 prefix or not. 326 When propagating (either from Level-1 to Level-2 or vice versa) a 327 reachability advertisement originated by another IS-IS speaker, the 328 router MUST set the P-flag and MUST clear the E-flag of the related 329 Prefix-SIDs. 331 The following behavior is associated with the settings of the E and P 332 flags: 334 o If the P-flag is not set then any upstream neighbor of the Prefix- 335 SID originator MUST pop the Prefix-SID. This is equivalent to the 336 penultimate hop popping mechanism used in the MPLS dataplane which 337 improves performance of the ultimate hop. MPLS EXP bits of the 338 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 339 being removed). If the P-flag is unset the received E-flag is 340 ignored. 342 o If the P-flag is set then: 344 * If the E-flag is not set then any upstream neighbor of the 345 Prefix-SID originator MUST keep the Prefix-SID on top of the 346 stack. This is useful when, e.g., the originator of the 347 Prefix-SID must stitch the incoming packet into a continuing 348 MPLS LSP to the final destination. This could occur at an 349 inter-area border router (prefix propagation from one area to 350 another) or at an inter-domain border router (prefix 351 propagation from one domain to another). 353 * If the E-flag is set then any upstream neighbor of the Prefix- 354 SID originator MUST replace the PrefixSID with a Prefix-SID 355 having an Explicit-NULL value. This is useful, e.g., when the 356 originator of the Prefix-SID is the final destination for the 357 related prefix and the originator wishes to receive the packet 358 with the original EXP bits. 360 2.1.2. Prefix-SID Propagation 362 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 363 gets propagated across level boundaries. 365 The level-1-2 router that propagates the Prefix-SID sub-TLV between 366 levels MUST set the R-flag. 368 If the Prefix-SID contains a global index (L and V flags unset) and 369 it is propagated as such (with L and V flags unset), the value of the 370 index MUST be preserved when propagated between levels. 372 The level-1-2 router that propagates the Prefix-SID sub-TLV between 373 levels MAY change the setting of the L and V flags in case a local 374 label value is encoded in the Prefix-SID instead of the received 375 value. 377 2.2. Adjacency Segment Identifier 379 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 380 TLV (Adj-SID sub-TLV). 382 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 383 Routing IGP-Adjacency-SID as defined in 384 [I-D.ietf-spring-segment-routing] with flags and fields that may be 385 used, in future extensions of Segment Routing, for carrying other 386 types of SIDs. 388 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 389 below: 391 TLV-22 (Extended IS reachability)[RFC5305] 393 TLV-222 (Multitopology IS)[RFC5120] 395 TLV-23 (IS Neighbor Attribute)[RFC5311] 397 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 399 TLV-141 (inter-AS reachability information)[RFC5316] 401 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 402 neighbor. 404 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 406 The following format is defined for the Adj-SID sub-TLV: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | Flags | Weight | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | SID/Label/Index (variable) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 where: 418 Type: TBD, suggested value 31 420 Length: variable. 422 Flags: 1 octet field of following flags: 424 0 1 2 3 4 5 6 7 425 +-+-+-+-+-+-+-+-+ 426 |F|B|V|L|S|P| | 427 +-+-+-+-+-+-+-+-+ 429 where: 431 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 432 to an adjacency with outgoing IPv4 encapsulation. If set then 433 the Adj-SID refers to an adjacency with outgoing IPv6 434 encapsulation. 436 B-Flag: Backup flag. If set, the Adj-SID is eligible for 437 protection (e.g.: using IPFRR or MPLS-FRR) as described in 438 [I-D.ietf-spring-resiliency-use-cases]. 440 V-Flag: Value flag. If set, then the Adj-SID carries a value. 441 By default the flag is SET. 443 L-Flag: Local Flag. If set, then the value/index carried by 444 the Adj-SID has local significance. By default the flag is 445 SET. 447 S-Flag. Set flag. When set, the S-Flag indicates that the 448 Adj-SID refers to a set of adjacencies (and therefore MAY be 449 assigned to other adjacencies as well). 451 P-Flag. Persistent flag. When set, the P-Flag indicates that 452 the Adj-SID is persistently allocated, i.e., the Adj-SID value 453 remains consistent across router restart and/or interface flap. 455 Other bits: MUST be zero when originated and ignored when 456 received. 458 Weight: 1 octet. The value represents the weight of the Adj-SID 459 for the purpose of load balancing. The use of the weight is 460 defined in [I-D.ietf-spring-segment-routing]. 462 SID/Index/Label: according to the V and L flags, it contains 463 either: 465 * A 3 octet local label where the 20 rightmost bits are used for 466 encoding the label value. In this case the V and L flags MUST 467 be set. 469 * A 4 octet index defining the offset in the SID/Label space 470 advertised by this router using the encodings defined in 471 Section 3.1. In this case V and L flags MUST be unset. 473 * A 16 octet IPv6 address. In this case the V flag MUST be set. 474 The L flag MUST be unset if the IPv6 address is globally 475 unique. 477 An SR capable router MAY allocate an Adj-SID for each of its 478 adjacencies and SHOULD set the B-Flag when the adjacency is 479 eligible for protection (IP or MPLS). 481 An SR capable router MAY allocate more than one Adj-SID to an 482 adjacency. 484 An SR capable router MAY allocate the same Adj-SID to different 485 adjacencies. 487 When the P-flag is not set, the Adj-SID MAY be persistent. When 488 the P-flag is set, the Adj-SID MUST be persistent. 490 Examples of use of the Adj-SID sub-TLV are described in 491 [I-D.ietf-spring-segment-routing]. and 492 [I-D.ietf-6man-segment-routing-header]. 494 The F-flag is used in order for the router to advertise the 495 outgoing encapsulation of the adjacency the Adj-SID is attached 496 to. 498 2.2.2. Adjacency Segment Identifiers in LANs 500 In LAN subnetworks, the Designated Intermediate System (DIS) is 501 elected and originates the Pseudonode-LSP (PN-LSP) including all 502 neighbors of the DIS. 504 When Segment Routing is used, each router in the LAN MAY advertise 505 the Adj-SID of each of its neighbors. Since, on LANs, each router 506 only advertises one adjacency to the DIS (and doesn't advertise any 507 other adjacency), each router advertises the set of Adj-SIDs (for 508 each of its neighbors) inside a newly defined sub-TLV part of the TLV 509 advertising the adjacency to the DIS (e.g.: TLV-22). 511 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 512 suggested value 32) containing the set of Adj-SIDs the router 513 assigned to each of its LAN neighbors. 515 The format of the LAN-Adj-SID sub-TLV is as follows: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length | Flags | Weight | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | System-ID (6 octets) | 525 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | SID/Label/Index (variable) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 where: 535 Type: TBD, suggested value 32 537 Length: variable. 539 Flags: 1 octet field of following flags: 541 0 1 2 3 4 5 6 7 542 +-+-+-+-+-+-+-+-+ 543 |F|B|V|L|S|P| | 544 +-+-+-+-+-+-+-+-+ 546 where F, B, V, L, S and P flags are defined in Section 2.2.1. 547 Other bits: MUST be zero when originated and ignored when 548 received. 550 Weight: 1 octet. The value represents the weight of the Adj-SID 551 for the purpose of load balancing. The use of the weight is 552 defined in [I-D.ietf-spring-segment-routing]. 554 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 555 defined in [ISO10589]. 557 SID/Index/Label: according to the V and L flags, it contains 558 either: 560 * A 3 octet local label where the 20 rightmost bits are used for 561 encoding the label value. In this case the V and L flags MUST 562 be set. 564 * A 4 octet index defining the offset in the SID/Label space 565 advertised by this router using the encodings defined in 566 Section 3.1. In this case V and L flags MUST be unset. 568 * A 16 octet IPv6 address. In this case the V flag MUST be set. 569 The L flag MUST be unset if the IPv6 address is globally 570 unique. 572 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 574 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 575 the P-flag is set, the LAN-Adj-SID MUST be persistent. 577 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 578 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 579 advertisements of the adjacency to the DIS MUST be used and all 580 advertisements MUST have the same metric. 582 Each router within the level, by receiving the DIS PN LSP as well as 583 the non-PN LSP of each router in the LAN, is capable of 584 reconstructing the LAN topology as well as the set of Adj-SID each 585 router uses for each of its neighbors. 587 A label is encoded in 3 octets (in the 20 rightmost bits). 589 An index is encoded in 4 octets. 591 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined 592 in [I-D.ietf-6man-segment-routing-header]). 594 2.3. SID/Label Sub-TLV 596 The SID/Label sub-TLV is present in the following sub-TLVs defined in 597 this document: 599 Binding TLV Section 2.4. 601 SR Capability sub-TLV Section 3.1. 603 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 604 sub-TLV has the following format: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | SID/Label (variable) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 where: 616 Type: TBD, suggested value 1 618 Length: variable 620 SID/Label: if length is set to 3 then the 20 rightmost bits 621 represent a MPLS label. 623 2.4. SID/Label Binding TLV 625 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 626 domain. There are multiple uses of the SID/Label Binding TLV: 628 o The router may advertise a SID/Label binding to a FEC along with 629 at least a single 'nexthop style' anchor. The protocol supports 630 more than one 'nexthop style' anchor to be attached to a SID/Label 631 binding, which results into a simple path description language. 632 In analogy to RSVP the terminology for this is called an 'Explicit 633 Route Object' (ERO). Since ERO style path notation allows to 634 anchor SID/label bindings to both link and node IP addresses any 635 label switched path, can be described. Furthermore also SID/Label 636 Bindings from external protocols can get easily re-advertised. 638 o The SID/Label Binding TLV may be used for advertising SID/Label 639 Bindings and their associated Primary and Backup paths. In one 640 single TLV either a primary ERO Path, a backup ERO Path or both 641 are advertised. If a router wants to advertise multiple parallel 642 paths then it can generate several TLVs for the same Prefix/FEC. 643 Each occurrence of a Binding TLV with respect with a given FEC 644 Prefix has accumulating and not canceling semantics. Due the 645 space constraints in the 8-Bit IS-IS TLVs an originating router 646 MAY encode a primary ERO path in one SID/Label Binding TLV and the 647 backup ERO path in a second SID/Label Binding TLV. Note that the 648 FEC Prefix and SID/Label sub-TLV MUST be identical in both TLVs. 650 o The SID/Label Binding TLV may also be used in order to advertise 651 prefixes to SID/Label mappings. This functionality is called the 652 'Mapping Server' and it's used when, in a heterogeneous network, 653 not all nodes are capable of advertising their own SIDs/Labels. 655 When the SID/Label Binding TLV is used by the Mapping Server in 656 order to advertise prefix to SID/label mappings, the index/label 657 MUST include the Prefix-SID SubTLV (Section 2.1). 659 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 660 the following format: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length | Flags | Weight | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Range | Prefix Length | FEC Prefix | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 // FEC Prefix (continued, variable) // 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | SubTLVs (variable) | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 1: SID/Label Binding TLV format 676 o Type: TBD, suggested value 149 678 o Length: variable. 680 o 1 octet of flags 682 o 1 octet of Weight 684 o 2 octets of Range 686 o 1 octet of Prefix Length 688 o 0-16 octets of FEC Prefix 690 o sub-TLVs, where each sub-TLV consists of a sequence of: 692 * 1 octet of sub-TLV type 694 * 1 octet of length of the value field of the sub-TLV 696 * 0-243 octets of value 698 2.4.1. Flags 700 Flags: 1 octet field of following flags: 702 0 1 2 3 4 5 6 7 703 +-+-+-+-+-+-+-+-+ 704 |F|M|S|D|A| | 705 +-+-+-+-+-+-+-+-+ 707 where: 709 F-Flag: Address Family flag. If unset, then the Prefix FEC 710 carries an IPv4 Prefix. If set then the Prefix FEC carries an 711 IPv6 Prefix. 713 M-Flag: Mirror Context flag. Set if the advertised SID/path 714 corresponds to a mirrored context. The use of the M flag is 715 described in [I-D.ietf-spring-segment-routing]. 717 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 718 the entire routing domain. If the S flag is not set, the SID/ 719 Label Binding TLV MUST NOT be leaked between levels. This bit 720 MUST NOT be altered during the TLV leaking. 722 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 723 level-1, the D bit MUST be set. Otherwise, this bit MUST be 724 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 725 leaked from level-1 to level-2. This is to prevent TLV looping 726 across levels. 728 A-Flag: Attached flag. The originator of the SID/Label Binding 729 TLV MAY set the A bit in order to signal that the prefixes and 730 SIDs advertised in the SID/Label Binding TLV are directly 731 connected to their originators. The mechanisms through which the 732 originator of the SID/Label Binding TLV can figure out if a prefix 733 is attached or not are outside the scope of this document (e.g.: 734 through explicit configuration). If the Binding TLV is leaked to 735 other areas/levels the A-flag MUST be cleared. 737 An implementation MAY decide not to honor the S-flag in order not 738 to leak Binding TLV's between levels (for policy reasons). In all 739 cases, the D flag MUST always be set by any router leaking the 740 Binding TLV from level-2 into level-1 and MUST be checked when 741 propagating the Binding TLV from level-1 into level-2. If the D 742 flag is set, the Binding TLV MUST NOT be propagated into level-2. 744 Other bits: MUST be zero when originated and ignored when 745 received. 747 2.4.2. Weight 749 Weight: 1 octet: The value represents the weight of the path for the 750 purpose of load balancing. The use of the weight is defined in 751 [I-D.ietf-spring-segment-routing]. 753 2.4.3. Range 755 The 'Range' field provides the ability to specify a range of 756 addresses and their associated Prefix SIDs. This functionality is 757 called "Mapping Server". It is essentially a compression scheme to 758 distribute a continuous Prefix and their continuous, corresponding 759 SID/Label Block. If a single SID is advertised then the range field 760 MUST be set to one. For range advertisements > 1, the number of 761 addresses that need to be mapped into a Prefix-SID and the starting 762 value of the Prefix-SID range. 764 Example 1: if the following router addresses (loopback addresses) 765 need to be mapped into the corresponding Prefix SID indexes. 767 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 768 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 769 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 770 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type | Length |0|0| | Weight | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Range = 4 | /32 | 192 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | .0 | .2 | .1 |Prefix-SID Type| 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | sub-TLV Length| Flags | Algorithm | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | 1 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Example-2: If the following prefixes need to be mapped into the 787 corresponding Prefix-SID indexes: 789 10.1.1/24, Prefix-SID: Index 51 790 10.1.2/24, Prefix-SID: Index 52 791 10.1.3/24, Prefix-SID: Index 53 792 10.1.4/24, Prefix-SID: Index 54 793 10.1.5/24, Prefix-SID: Index 55 794 10.1.6/24, Prefix-SID: Index 56 795 10.1.7/24, Prefix-SID: Index 57 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length |0|0| | Weight | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Range = 7 | /24 | 10 | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Flags | Algorithm | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | 51 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 It is not expected that a network operator will be able to keep fully 812 continuous FEC Prefix / SID/Index mappings. In order to support 813 noncontinuous mapping ranges an implementation MAY generate several 814 instances of Binding TLVs. 816 For example if a router wants to advertise the following ranges: 818 Range 16: { 192.0.2.1-15, Index 1-15 } 820 Range 6: { 192.0.2.22-27, Index 22-27 } 822 Range 41: { 192.0.2.44-84, Index 80-120 } 824 A router would need to advertise three instances of the Binding TLV. 826 2.4.4. Prefix Length, Prefix 828 The 'FEC Prefix' represents the Forwarding equivalence class at the 829 tail-end of the advertised path. The 'FEC Prefix' does not need to 830 correspond to a routable prefix of the originating node. 832 The 'Prefix Length' field contains the length of the prefix in bits. 833 Only the most significant octets of the Prefix FEC are encoded. 834 (i.e., 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC 835 prefix length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 836 4 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 837 prefix length 113 up to 128). 839 2.4.5. Mapping Server Prefix-SID 841 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 842 and contains the SID/index/label value associated with the prefix and 843 range. The Prefix-SID SubTLV MUST be used when the SID/Label Binding 844 TLV is used by the Mapping Server (i.e., advertising one or a range 845 of prefixes and their associated SIDs/Labels). 847 A node receiving a MS entry for a prefix MUST check the existence of 848 such prefix in its link-state database prior to consider and use the 849 associated SID. 851 2.4.5.1. Prefix-SID Flags 853 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 854 MAY advertise a mapping with the N flag set when the prefix being 855 mapped is known in the link-state topology with a mask length of 32 856 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 857 mechanisms through which the operator defines that a prefix 858 represents a node are outside the scope of this document (typically 859 it will be through configuration). 861 The other flags defined in Section 2.1 are not used by the Mapping 862 Server and MUST be ignored at reception. 864 2.4.5.2. PHP Behavior when using Mapping Server Advertisements 866 As the mapping server does not specify the originator of a prefix 867 advertisement it is not possible to determine PHP behavior solely 868 based on the Mapping Server Advertisement. However, if additional 869 information is available PHP behavior may safely be done. The 870 required information consists of: 872 o A prefix reachability advertisement for the prefix has been 873 received which includes the Extended Reachability Attribute Flags 874 sub-TLV ([RFC7794]). 876 o X and R flags are both set to 0 in the Extended Reachability 877 Attribute Flags sub-TLV. 879 In the absence of an Extended Reachability Attribute Flags sub-TLV 880 ([RFC7794]) the A flag in the binding TLV indicates that the 881 originator of a prefix reachability advertisement is directly 882 connected to the prefix and thus PHP MUST be done by the neighbors of 883 the router originating the prefix reachability advertisement. Note 884 that A-flag is only valid in the original area in which the Binding 885 TLV is advertised. 887 2.4.5.3. Prefix-SID Algorithm 889 The algorithm field contains the identifier of the algorithm the 890 router MUST use in order to compute reachability to the range of 891 prefixes. Use of the algorithm field is described in Section 2.1. 893 2.4.6. SID/Label Sub-TLV 895 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 896 SID/Label value as defined in Section 2.3. It MAY be present in the 897 SID/Label Binding TLV. 899 2.4.7. ERO Metric sub-TLV 901 ERO Metric sub-TLV (Type: TBD, suggested value 10) is a sub-TLV of 902 the SID/Label Binding TLV. 904 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 905 to compare the cost of a given source/destination path. A router MAY 906 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 907 SHOULD be set to the cumulative IGP or TE path cost of the advertised 908 ERO. Since manipulation of the Metric field may attract or distract 909 traffic from and to the advertised segment it MAY be manually 910 overridden. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Type | Length | Metric | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Metric (continued) | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 ERO Metric sub-TLV format 922 where: 924 Type: TBD, suggested value 10 926 Length: 4 928 Metric: 4 bytes 930 2.4.8. IPv4 ERO subTLV 932 The IPv4 ERO subTLV (Type: TBD, suggested value 11) describes a path 933 segment using IPv4 address style of encoding. Its semantics have 934 been borrowed from [RFC3209]. 936 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 937 set, then the value of the attribute is 'loose.' Otherwise, the 938 value of the attribute is 'strict.' 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Type | Length |L| Reserved | IPv4 address | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | IPv4 address (continued) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure 2: IPv4 ERO subTLV format 950 2.4.9. IPv6 ERO subTLV 952 The IPv6 ERO subTLV (Type: TBD, suggested value 12) describes a path 953 segment using IPv6 Address style of encoding. Its semantics have 954 been borrowed from [RFC3209]. 956 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 957 set, then the value of the attribute is 'loose.' Otherwise, the 958 value of the attribute is 'strict.' 960 0 1 2 3 961 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 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Type | Length |L| Reserved | IPv6 address | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | IPv6 Address (continued) | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | IPv6 Address (continued) | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | IPv6 Address (continued) | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | IPv6 Address (continued) | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 Figure 3: IPv6 ERO subTLV format 976 2.4.10. Unnumbered Interface ID ERO subTLV 978 The appearance and semantics of the 'Unnumbered Interface ID' have 979 been borrowed from Section 4 [RFC3477]. 981 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 982 13) describes a path segment that spans over an unnumbered interface. 983 Unnumbered interfaces are referenced using the interface index. 984 Interface indices are assigned local to the router and therefore not 985 unique within a domain. All elements in an ERO path need to be 986 unique within a domain and hence need to be disambiguated using a 987 domain unique Router-ID. 989 The 'Router-ID' field contains the router ID of the router which has 990 assigned the 'Interface ID' field. Its purpose is to disambiguate 991 the 'Interface ID' field from other routers in the domain. 993 IS-IS supports two Router-ID formats: 995 o (TLV 134, 32-Bit format) [RFC5305] 997 o (TLV 140, 128-Bit format) [RFC6119] 999 The actual Router-ID format gets derived from the 'Length' field. 1001 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1003 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1005 The 'Interface ID' is the identifier assigned to the link by the 1006 router specified by the router ID. 1008 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1009 set, then the value of the attribute is 'loose.' Otherwise, the 1010 value of the attribute is 'strict.' 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type | Length |L| Reserved | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 // Router ID (32 or 128 bits) // 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Interface ID (32 bits) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 Figure 4: Unnumbered Interface ID ERO subTLV format 1024 2.4.11. IPv4 Backup ERO subTLV 1026 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 14) describes 1027 a Backup path segment using IPv4 Address style of encoding. Its 1028 appearance and semantics have been borrowed from [RFC3209]. 1030 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1031 set, then the value of the attribute is 'loose.' Otherwise, the 1032 value of the attribute is 'strict.' 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Type | Length |L| Reserved | IPv4 address | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | IPv4 address (continued) | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 5: IPv4 Backup ERO subTLV format 1044 2.4.12. IPv6 Backup ERO subTLV 1046 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 15) describes 1047 a Backup path segment using IPv6 Address style of encoding. Its 1048 appearance and semantics have been borrowed from [RFC3209]. 1050 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1051 set, then the value of the attribute is 'loose.' Otherwise, the 1052 value of the attribute is 'strict.' 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Type | Length |L| Reserved | IPv6 address | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | IPv6 Address (continued) | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | IPv6 Address (continued) | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | IPv6 Address (continued) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | IPv6 Address (continued) | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 6: IPv6 Backup ERO subTLV format 1070 2.4.13. Unnumbered Interface ID Backup ERO subTLV 1072 The appearance and semantics of the 'Unnumbered Interface ID' have 1073 been borrowed from Section 4 [RFC3477]. 1075 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 1076 value 16) describes a Backup LSP path segment that spans over an 1077 unnumbered interface. Unnumbered interfaces are referenced using the 1078 interface index. Interface indices are assigned local to the router 1079 and therefore not unique within a domain. All elements in an ERO 1080 path need to be unique within a domain and hence need to be 1081 disambiguated using a domain unique Router-ID. 1083 The 'Router-ID' field contains the router ID of the router which has 1084 assigned the 'Interface ID' field. Its purpose is to disambiguate 1085 the 'Interface ID' field from other routers in the domain. 1087 IS-IS supports two Router-ID formats: 1089 o (TLV 134, 32-Bit format) [RFC5305] 1091 o (TLV 140, 128-Bit format) [RFC6119] 1093 The actual Router-ID format gets derived from the 'Length' field. 1095 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1097 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1099 The 'Interface ID' is the identifier assigned to the link by the 1100 router specified by the router ID. 1102 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1103 set, then the value of the attribute is 'loose.' Otherwise, the 1104 value of the attribute is 'strict.' 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Length |L| Reserved | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 // Router ID (32 or 128 bits) // 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Interface ID (32 bits) | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 1118 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics 1120 All 'ERO' and 'Backup ERO' information represents an ordered set 1121 which describes the segments of a path. The last ERO subTLV 1122 describes the segment closest to the egress point of the path. 1123 Contrary the first ERO subTLV describes the first segment of a path. 1124 If a router extends or stitches a label switched path it MUST prepend 1125 the new segments path information to the ERO list. The same ordering 1126 applies for the Backup ERO labels. An implementation SHOULD first 1127 encode all primary path EROs followed by the bypass EROs. 1129 2.5. Multi-Topology SID/Label Binding TLV 1131 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 1132 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 1133 has the same format as the SID/Label Binding TLV defined in 1134 Section 2.4 with the difference consisting of a Multitopology 1135 Identifier (MTID) as defined here below: 1137 0 1 2 3 1138 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 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Type | Length | MTID | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Flags | Weight | Range | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Prefix Length | FEC Prefix | FEC Prefix (variable) | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | SubTLVs (variable) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Figure 8: Multi-Topology SID/Label Binding TLV format 1151 where: 1153 Type: TBD, suggested value 150 1155 Length: variable 1157 MTID is the multitopology identifier defined as: 1159 0 1 1160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | RESVD | MTID | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 RESVD: reserved bits. MUST be reset on transmission and 1165 ignored on receive. 1167 MTID: a 12-bit field containing the non-zero ID of the topology 1168 being announced. The TLV MUST be ignored if the ID is zero. 1169 This is to ensure the consistent view of the standard unicast 1170 topology. 1172 The other fields and SubTLVs are defined in Section 2.4. 1174 3. Router Capabilities 1176 3.1. SR-Capabilities Sub-TLV 1178 Segment Routing requires each router to advertise its SR data-plane 1179 capability and the range of MPLS label values it uses for Segment 1180 Routing in the case where global SIDs are allocated (i.e., global 1181 indexes). Data-plane capabilities and label ranges are advertised 1182 using the newly defined SR-Capabilities sub-TLV inserted into the IS- 1183 IS Router Capability TLV-242 that is defined in [RFC7981]. 1185 The Router Capability TLV specifies flags that control its 1186 advertisement. The SR Capabilities sub-TLV MUST be propagated 1187 throughout the level and SHOULD NOT be advertised across level 1188 boundaries. Therefore Router Capability TLV distribution flags 1189 SHOULD be set accordingly, i.e., the S flag in the Router Capability 1190 TLV ([RFC7981]) MUST be unset. 1192 The SR Capabilities sub-TLV has following format: 1194 0 1 2 3 1195 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 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Type | Length | Flags | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Range | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 // SID/Label Sub-TLV (variable) // 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 Type: TBD, suggested value 2 1208 Length: variable. 1210 Flags: 1 octet of flags. The following are defined: 1212 0 1 2 3 4 5 6 7 1213 +-+-+-+-+-+-+-+-+ 1214 |I|V|H| | 1215 +-+-+-+-+-+-+-+-+ 1217 where: 1219 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 1220 processing SR MPLS encapsulated IPv4 packets on all interfaces. 1222 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 1223 processing SR MPLS encapsulated IPv6 packets on all interfaces. 1225 H-Flag: SR-IPv6 flag. If set, then the router is capable of 1226 processing the IPv6 Segment Routing Header on all interfaces as 1227 defined in [I-D.ietf-6man-segment-routing-header]. 1229 One or more SRGB Descriptor entries, each of which have the 1230 following format: 1232 Range: 3 octets. 1234 SID/Label sub-TLV (as defined in Section 2.3). 1236 SID/Label sub-TLV contains the first value of the SRGB while the 1237 range contains the number of SRGB elements. The range value MUST be 1238 higher than 0. 1240 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 1241 but a router MUST NOT advertise more than one SR-Capabilities sub- 1242 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 1243 same originator, SHOULD select the first advertisement in the lowest 1244 numbered LSP. 1246 When multiple SRGB Descriptors are advertised the entries define an 1247 ordered set of ranges on which a SID index is to be applied. For 1248 this reason changing the order in which the descriptors are 1249 advertised will have a disruptive effect on forwarding. 1251 When a router adds a new SRGB Descriptor to an existing SR- 1252 Capabilities sub-TLV the new Descriptor SHOULD add the newly 1253 configured block at the end of the sub-TLV and SHOULD NOT change the 1254 order of previously advertised blocks. Changing the order of the 1255 advertised descriptors will create label churn in the FIB and 1256 blackhole / misdirect some traffic during the IGP convergence. In 1257 particular, if a range which is not the last is extended it's 1258 preferable to add a new range rather than extending the previously 1259 advertised range. 1261 The originating router MUST ensure the order is same after a graceful 1262 restart (using checkpointing, non-volatile storage or any other 1263 mechanism) in order to guarantee the same order before and after GR. 1265 The originating router MUST NOT advertise overlapping ranges. 1267 When a router receives multiple overlapping ranges, it MUST conform 1268 to the procedures defined in [I-D.ietf-spring-conflict-resolution]. 1270 Here follows an example of advertisement of multiple ranges: 1272 The originating router advertises following ranges: 1273 SR-Cap: range: 100, SID value: 100 1274 SR-Cap: range: 100, SID value: 1000 1275 SR-Cap: range: 100, SID value: 500 1277 The receiving routers concatenate the ranges in the received 1278 order and build the SRGB as follows: 1280 SRGB = [100, 199] 1281 [1000, 1099] 1282 [500, 599] 1284 The indexes span multiple ranges: 1286 index=0 means label 100 1287 ... 1288 index 99 means label 199 1289 index 100 means label 1000 1290 index 199 means label 1099 1291 ... 1292 index 200 means label 500 1293 ... 1295 3.2. SR-Algorithm Sub-TLV 1297 The router may use various algorithms when calculating reachability 1298 to other nodes or to prefixes attached to these nodes. Examples of 1299 these algorithms are metric based Shortest Path First (SPF), various 1300 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1301 suggested value 19) allows the router to advertise the algorithms 1302 that the router is currently using. The following value has been 1303 defined: 1305 0: Shortest Path First (SPF) algorithm based on link metric. This 1306 is the well-known shortest path algorithm as computed by the IS-IS 1307 Decision process. Consistent with the deployed practice for link- 1308 state protocols, algorithm 0 permits any node to overwrite the SPF 1309 path with a different path based on local policy. 1311 1: Strict Shortest Path First (SPF) algorithm based on link 1312 metric. The algorithm is identical to algorithm 0 but algorithm 1 1313 requires that all nodes along the path will honor the SPF routing 1314 decision. Local policy MUST NOT alter the forwarding decision 1315 computed by algorithm 1 at the node claiming to support algorithm 1316 1. 1318 The SR-Algorithm sub-TLV is inserted into the IS-IS Router Capability 1319 TLV-242 that is defined in [RFC7981]. 1321 The Router Capability TLV specifies flags that control its 1322 advertisement. The SR-Algorithm MUST be propagated throughout the 1323 level and need not to be advertised across level boundaries. 1324 Therefore Router Capability TLV distribution flags MUST be set 1325 accordingly, i.e., the S flag MUST be unset. 1327 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1328 time inside the Router Capability TLV. 1330 When the originating router does not advertise the SR-Algorithm sub- 1331 TLV, then all the Prefix-SID advertised by the router MUST have 1332 algorithm field set to 0. Any receiving router MUST assume SPF 1333 algorithm (i.e., Shortest Path First). 1335 When the originating router does advertise the SR-Algorithm sub-TLV, 1336 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1338 The SR-Algorithm sub-TLV has following format: 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Type | Length | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 where: 1350 Type: TBD, suggested value 19 1352 Length: variable. 1354 Algorithm: 1 octet of algorithm Section 2.1 1356 3.3. SR Local Block Sub-TLV 1358 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1359 node has reserved for local SIDs. Local SIDs are used, e.g., for 1360 Adjacency-SIDs, and may also be allocated by other components than 1361 IS-IS protocol. As an example, an application or a controller may 1362 instruct the router to allocate a specific local SID. Therefore, in 1363 order for such applications or controllers to know what are the local 1364 SIDs available in the router, it is required that the router 1365 advertises its SRLB. 1367 The SRLB Sub-TLV is used for that purpose and has following format: 1369 0 1 2 3 1370 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 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Type | Length | Flags | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Range | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 // SID/Label Sub-TLV (variable) // 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 Type: TBD, suggested value 22. 1383 Length: variable. 1385 Flags: 1 octet of flags. None are defined at this stage. 1387 One or more SRLB Descriptor entries, each of which have the 1388 following format: 1390 Range: 3 octets. 1392 SID/Label sub-TLV (as defined in Section 2.3). 1394 SID/Label sub-TLV contains the first value of the SRLB while the 1395 range contains the number of SRLB elements. The range value MUST be 1396 higher than 0. 1398 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1399 router MUST NOT advertise more than one SRLB sub-TLV. A router 1400 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1401 select the first advertisement in the lowest numbered LSP. 1403 The originating router MUST NOT advertise overlapping ranges. 1405 It is important to note that each time a SID from the SRLB is 1406 allocated, it SHOULD also be reported to all components (e.g.: 1407 controller or applications) in order for these components to have an 1408 up-to-date view of the current SRLB allocation and in order to avoid 1409 collision between allocation instructions. 1411 Within the context of IS-IS, the reporting of local SIDs is done 1412 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1413 reporting of allocated local SIDs may also be done through other 1414 means and protocols which mechanisms are outside the scope of this 1415 document. 1417 A router advertising the SRLB TLV may also have other label ranges, 1418 outside the SRLB, for its local allocation purposes which are NOT 1419 advertised in the SRLB. For example, it is possible that an 1420 Adjacency-SID is allocated using a local label not part of the SRLB. 1422 3.4. SRMS Preference Sub-TLV 1424 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1425 in order to associate a preference with SRMS advertisements from a 1426 particular source. 1428 The SRMS Preference sub-TLV has following format: 1430 0 1 2 3 1431 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 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Type | Length | Preference | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 Type: TBD, suggested value 23. 1438 Length: 1. 1440 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1442 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1443 but a router MUST NOT advertise more than one SRMS Preference sub- 1444 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1445 same originator, SHOULD select the first advertisement in the lowest 1446 numbered LSP. 1448 The use of the SRMS Preference during the SID selection process is 1449 described in [I-D.ietf-spring-conflict-resolution]. 1451 4. Non backward compatible changes with prior versions of this document 1453 This section describes the changes that have been applied to this 1454 document that are not backward compatible with previous versions. 1456 4.1. Encoding of Multiple SRGBs 1458 Version -04 of this document introduced a change in Section 3.1 1459 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1460 and made the support of multiple SRGBs REQUIRED. 1462 The modified method consists of having a single SR-Cap Sub-TLV where 1463 all SRGBs are encoded. In previous versions (prior to version -04) 1464 of this document it was allowed to have multiple occurrences of the 1465 SR-Cap Sub-TLV. 1467 At the time of writing this document, no existing implementations are 1468 affected by the change since no implementations actually (i.e., at 1469 the time of updating this document) encode multiple SRGBs anyway. 1471 5. IANA Considerations 1473 This documents request allocation for the following TLVs and subTLVs. 1475 5.1. Sub TLVs for Type 22,23,222 and 223 1477 This document makes the following registrations in the "sub-TLVs for 1478 TLV 22, 23, 222 and 223" registry. 1480 Type: TBD (suggested value 31) 1482 Description: Adjacency Segment Identifier 1484 TLV 22: yes 1486 TLV 23: yes 1488 TLV 222: yes 1490 TLV 223: yes 1492 Reference: This document (Section 2.2.1) 1494 Type: TBD (suggested value 32) 1495 Description: LAN Adjacency Segment Identifier 1497 TLV 22: yes 1499 TLV 23: yes 1501 TLV 222: yes 1503 TLV 223: yes 1505 Reference: This document (Section 2.2.2) 1507 5.2. Sub TLVs for Type 135,235,236 and 237 1509 This document makes the following registrations in the "sub-TLVs for 1510 TLV 135,235,236 and 237" registry. 1512 Type: TBD (suggested value 3) 1514 Description: Prefix Segment Identifier 1516 TLV 135: yes 1518 TLV 235: yes 1520 TLV 236: yes 1522 TLV 237: yes 1524 Reference: This document (Section 2.1) 1526 5.3. Sub TLVs for Type 242 1528 This document makes the following registrations in the "sub-TLVs for 1529 TLV 242" registry. 1531 Type: TBD (suggested value 2) 1533 Description: Segment Routing Capability 1535 Reference: This document (Section 3.1) 1537 Type: TBD (suggested value 19) 1538 Description: Segment Routing Algorithm 1540 Reference: This document (Section 3.2) 1542 Type: TBD (suggested value 22) 1544 Description: Segment Routing Local Base (SRLB) 1546 Reference: This document (Section 3.3) 1548 Type: TBD (suggested value 23) 1550 Description: Segment Routing Mapping Server Preference (SRMS 1551 Preference) 1553 Reference: This document (Section 3.4) 1555 5.4. New TLV Codepoint and Sub-TLV registry 1557 This document registers the following TLV: 1559 Type: TBD (suggested value 149) 1561 name: Segment Identifier / Label Binding 1563 IIH: no 1565 LSP: yes 1567 SNP: no 1569 Purge: no 1571 Reference: This document (Section 2.4) 1573 Type: TBD (suggested value 150) 1575 name: Multi-Topology Segment Identifier / Label Binding 1577 IIH: no 1579 LSP: yes 1581 SNP: no 1582 Purge: no 1584 Reference: This document (Section 2.5) 1586 This document creates the following sub-TLV Registry: 1588 Registry: sub-TLVs for TLV 149 and 150 1590 Registration Procedure: Expert review 1592 Reference: This document (Section 2.4) 1594 Type: TBD, suggested value 1 1596 Description: SID/Label 1598 Reference: This document (Section 2.3) 1600 Type: TBD, suggested value 3 1602 Description: Prefix-SID 1604 Reference: This document (Section 2.1) 1606 Type: TBD, suggested value 10 1608 Description: ERO Metric 1610 Reference: This document (Section 2.4.7) 1612 Type: TBD, suggested value 11 1614 Description: IPv4 ERO 1616 Reference: This document (Section 2.4.8) 1618 Type: TBD, suggested value 12 1620 Description: IPv6 ERO 1621 Reference: This document (Section 2.4.9) 1623 Type: TBD, suggested value 13 1625 Description: Unnumbered Interface-ID ERO 1627 Reference: This document (Section 2.4.10) 1629 Type: TBD, suggested value 14 1631 Description: IPv4 Backup ERO 1633 Reference: This document (Section 2.4.11) 1635 Type: TBD, suggested value 15 1637 Description: IPv6 Backup ERO 1639 Reference: This document (Section 2.4.12) 1641 Type: TBD, suggested value 16 1643 Description: Unnumbered Interface-ID Backup ERO 1645 Reference: This document (Section 2.4.13) 1647 6. Manageability Considerations 1649 TBD 1651 7. Security Considerations 1653 TBD 1655 8. Acknowledgements 1657 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1658 Francois and Jesper Skrivers for their contribution to the content of 1659 this document. 1661 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1662 earlier definition of the "Binding / MPLS Label TLV". 1664 9. Contributors 1666 The following people gave a substantial contribution to the content 1667 of this document and should be considered as co-authors: 1669 Les Ginsberg 1670 Cisco Systems Inc. 1671 US 1673 Email: ginsberg@cisco.com 1675 Martin Horneffer 1676 Deutsche Telekom 1677 DE 1679 Email: Martin.Horneffer@telekom.de 1681 Wim Henderickx 1682 Alcatel-Lucent 1683 BE 1685 Email: wim.henderickx@alcatel-lucent.com 1687 Edward Crabbe 1688 Individual 1689 US 1691 Email: edward.crabbe@gmail.com 1693 Rob Shakir 1694 Individual 1695 UK 1697 Email: rjs@rob.sh 1699 Igor Milojevic 1700 Individual 1701 RS 1703 Email: milojevicigor@gmail.com 1704 Saku Ytti 1705 TDC 1706 FI 1708 Email: saku@ytti.fi 1710 Steven Luong 1711 Cisco Systems Inc. 1712 US 1714 Email: sluong@cisco.com 1716 10. References 1718 10.1. Normative References 1720 [I-D.ietf-spring-conflict-resolution] 1721 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1722 "Segment Routing Conflict Resolution", draft-ietf-spring- 1723 conflict-resolution-02 (work in progress), October 2016. 1725 [I-D.ietf-spring-segment-routing] 1726 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1727 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1728 spring-segment-routing-11 (work in progress), February 1729 2017. 1731 [ISO10589] 1732 International Organization for Standardization, 1733 "Intermediate system to Intermediate system intra-domain 1734 routeing information exchange protocol for use in 1735 conjunction with the protocol for providing the 1736 connectionless-mode Network Service (ISO 8473)", ISO/ 1737 IEC 10589:2002, Second Edition, Nov 2002. 1739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1740 Requirement Levels", BCP 14, RFC 2119, 1741 DOI 10.17487/RFC2119, March 1997, 1742 . 1744 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1745 Topology (MT) Routing in Intermediate System to 1746 Intermediate Systems (IS-ISs)", RFC 5120, 1747 DOI 10.17487/RFC5120, February 2008, 1748 . 1750 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1751 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1752 2008, . 1754 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1755 DOI 10.17487/RFC5308, October 2008, 1756 . 1758 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1759 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1760 February 2011, . 1762 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1763 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1764 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1765 March 2016, . 1767 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1768 for Advertising Router Information", RFC 7981, 1769 DOI 10.17487/RFC7981, October 2016, 1770 . 1772 10.2. Informative References 1774 [I-D.ietf-6man-segment-routing-header] 1775 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1776 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1777 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1778 segment-routing-header-05 (work in progress), February 1779 2017. 1781 [I-D.ietf-spring-resiliency-use-cases] 1782 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1783 "Resiliency use cases in SPRING networks", draft-ietf- 1784 spring-resiliency-use-cases-08 (work in progress), October 1785 2016. 1787 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1788 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1789 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1790 . 1792 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1793 in Resource ReSerVation Protocol - Traffic Engineering 1794 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1795 . 1797 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1798 Shand, "Simplified Extension of Link State PDU (LSP) Space 1799 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1800 . 1802 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1803 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1804 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1805 December 2008, . 1807 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1808 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1809 Packet Routing in Networking (SPRING) Problem Statement 1810 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1811 2016, . 1813 Authors' Addresses 1815 Stefano Previdi (editor) 1816 Cisco Systems, Inc. 1817 Via Del Serafico, 200 1818 Rome 00142 1819 Italy 1821 Email: sprevidi@cisco.com 1823 Clarence Filsfils 1824 Cisco Systems, Inc. 1825 Brussels 1826 BE 1828 Email: cfilsfil@cisco.com 1830 Ahmed Bashandy 1831 Cisco Systems, Inc. 1832 170, West Tasman Drive 1833 San Jose, CA 95134 1834 US 1836 Email: bashandy@cisco.com 1838 Hannes Gredler 1839 RtBrick Inc. 1841 Email: hannes@rtbrick.com 1842 Stephane Litkowski 1843 Orange 1844 FR 1846 Email: stephane.litkowski@orange.com 1848 Bruno Decraene 1849 Orange 1850 FR 1852 Email: bruno.decraene@orange.com 1854 Jeff Tantsura 1855 Individual 1857 Email: jefftant@gmail.com