idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-25.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 == Line 1171 has weird spacing: '...ntifier y ...' == Line 1201 has weird spacing: '...Binding n ...' == Line 1202 has weird spacing: '...ntifier n y...' -- The document date (May 19, 2019) is 1804 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 985 -- Looks like a reference, but probably isn't: '199' on line 985 -- Looks like a reference, but probably isn't: '1000' on line 986 -- Looks like a reference, but probably isn't: '1099' on line 986 -- Looks like a reference, but probably isn't: '500' on line 987 -- Looks like a reference, but probably isn't: '599' on line 987 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 4 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 Huawei 4 Intended status: Standards Track L. Ginsberg, Ed. 5 Expires: November 20, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 A. Bashandy 8 Arrcus 9 H. Gredler 10 RtBrick Inc. 11 B. Decraene 12 Orange 13 May 19, 2019 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-25 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 operating on an MPLS data-plane. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 20, 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 72 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 73 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 75 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 76 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 77 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 78 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 79 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 80 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 81 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15 82 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 83 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15 84 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16 85 2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16 86 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18 87 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19 88 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19 89 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 90 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23 91 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 92 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 93 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 94 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26 95 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26 96 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 26 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 99 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 102 8.2. Informative References . . . . . . . . . . . . . . . . . 30 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 105 1. Introduction 107 Segment Routing (SR) allows for a flexible definition of end-to-end 108 paths within IGP topologies by encoding paths as sequences of 109 topological sub-paths, called "segments". These segments are 110 advertised by the link-state routing protocols (IS-IS and OSPF). 111 Prefix segments represent an ECMP-aware shortest-path to a prefix (or 112 a node), as per the state of the IGP topology. Adjacency segments 113 represent a hop over a specific adjacency between two nodes in the 114 IGP. A prefix segment is typically a multi-hop path while an 115 adjacency segment, in most of the cases, is a one-hop path. SR's 116 control-plane can be applied to both IPv6 and MPLS data-planes, and 117 does not require any additional signaling (other than the regular 118 IGP). For example, when used in MPLS networks, SR paths do not 119 require any LDP or RSVP-TE signaling. Still, SR can interoperate in 120 the presence of LSPs established with RSVP or LDP. 122 There are additional segment types, e.g., Binding SID defined in 123 [RFC8402]. This document also defines an advertisement for one type 124 of Binding SID: the Mirror Context segment. 126 This draft describes the necessary IS-IS extensions that need to be 127 introduced for Segment Routing operating on an MPLS data-plane. 129 The Segment Routing architecture is described in [RFC8402]. 131 Segment Routing use cases are described in [RFC7855]. 133 2. Segment Routing Identifiers 135 The Segment Routing architecture [RFC8402] defines different types of 136 Segment Identifiers (SID). This document defines the IS-IS encodings 137 for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN- 138 Adjacency Segment and the Binding Segment. 140 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 142 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 143 (Prefix-SID sub-TLV). 145 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 146 defined in [RFC8402]. The 'Prefix SID' MUST be unique within a given 147 IGP domain (when the L-flag is not set). 149 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 150 and MAY be present in any of the following TLVs: 152 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 154 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 156 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 158 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 160 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 161 and Section 2.5 respectively. 163 The Prefix-SID sub-TLV has the following format: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | Flags | Algorithm | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | SID/Index/Label (variable) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 where: 175 Type: 3 177 Length: 5 or 6 depending on the size of the SID (described below) 179 Flags: 1 octet field of following flags: 181 0 1 2 3 4 5 6 7 182 +-+-+-+-+-+-+-+-+ 183 |R|N|P|E|V|L| | 184 +-+-+-+-+-+-+-+-+ 186 where: 188 R-Flag: Re-advertisement flag. If set, then the prefix to 189 which this Prefix-SID is attached, has been propagated by the 190 router either from another level (i.e., from level-1 to level-2 191 or the opposite) or from redistribution (e.g.: from another 192 protocol). 194 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 195 the router identified by the prefix. Typically, the N-Flag is 196 set on Prefix-SIDs attached to a router loopback address. The 197 N-Flag is set when the Prefix-SID is a Node-SID as described in 198 [RFC8402]. 200 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 201 pop the Prefix-SID before delivering the packet to the node 202 that advertised the Prefix-SID. 204 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 205 the Prefix-SID originator MUST replace the Prefix-SID with a 206 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 207 IPv6) before forwarding the packet. 209 V-Flag: Value flag. If set, then the Prefix-SID carries a 210 value (instead of an index). By default the flag is UNSET. 212 L-Flag: Local Flag. If set, then the value/index carried by 213 the Prefix-SID has local significance. By default the flag is 214 UNSET. 216 Other bits: MUST be zero when originated and ignored when 217 received. 219 Algorithm: the router may use various algorithms when calculating 220 reachability to other nodes or to prefixes attached to these 221 nodes. Algorithm identifiers are defined in Section 3.2. 222 Examples of these algorithms are metric based Shortest Path First 223 (SPF), various sorts of Constrained SPF, etc. The algorithm field 224 of the Prefix-SID contains the identifier of the algorithm the 225 router uses to compute the reachability of the prefix to which the 226 Prefix-SID is associated. 228 At origination, the Prefix-SID algorithm field MUST be set to 0 or 229 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 231 A router receiving a Prefix-SID from a remote node and with an 232 algorithm value that such remote node has not advertised in the 233 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 234 TLV. 236 SID/Index/Label as defined in Section 2.1.1.1. 238 When the Prefix SID is an index (the V-flag is not set) the value is 239 used to determine the actual label value inside the set of all 240 advertised label ranges of a given router. This allows a receiving 241 router to construct forwarding state to a particular destination 242 router. 244 In many use-cases a 'stable transport' address is overloaded as an 245 identifier of a given node. Because Prefixes may be re-advertised 246 into other levels there may be some ambiguity (e.g. Originating 247 router vs. L1L2 router) for which node a particular IP prefix serves 248 as identifier. The Prefix-SID sub-TLV contains the necessary flags 249 to disambiguate Prefix to node mappings. Furthermore if a given node 250 has several 'stable transport' addresses there are flags to 251 differentiate those among other Prefixes advertised from a given 252 node. 254 2.1.1. Flags 256 2.1.1.1. V and L Flags 258 The V-flag indicates whether the SID/Index/Label field is a value or 259 an index. 261 The L-Flag indicates whether the value/index in the SID/Index/Label 262 field has local or global significance. 264 The following settings for V and L flags are valid: 266 V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field 267 is a 4 octet index defining the offset in the SID/Label space 268 advertised by this router using the encodings defined in Section 3.1. 270 V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field 271 is a 3 octet local label where the 20 rightmost bits are used for 272 encoding the label value. 274 All other combinations of V-flag and L-flag are invalid and any SID 275 advertisement received with an invalid setting for V and L flags MUST 276 be ignored. 278 2.1.1.2. R and N Flags 280 The R-Flag MUST be set for prefixes that are not local to the router 281 and either: 283 advertised because of propagation (Level-1 into Level-2); 284 advertised because of leaking (Level-2 into Level-1); 286 advertised because of redistribution (e.g.: from another 287 protocol). 289 In the case where a Level-1-2 router has local interface addresses 290 configured in one level, it may also propagate these addresses into 291 the other level. In such case, the Level-1-2 router MUST NOT set the 292 R bit. 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., a 'stable transport' loopback). 301 The prefix to which the Prefix-SID is attached has a Prefix length 302 of either /32 (IPv4) or /128 (IPv6). 304 The router MUST ignore the N-Flag on a received Prefix-SID if the 305 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 307 The Prefix Attributes Flags sub-TLV [RFC7794] also defines the N and 308 R flags and with the same semantics of the equivalent flags defined 309 in this document. Whenever the Prefix Attributes Flags sub-TLV is 310 present for a given prefix the values of the N and R flags advertised 311 in that sub-TLV MUST be used and the values in a corresponding Prefix 312 SID sub-TLV (if present) MUST be ignored. 314 2.1.1.3. E and P Flags 316 The following behavior is associated with the settings of the E and P 317 flags: 319 o If the P-flag is not set then any upstream neighbor of the Prefix- 320 SID originator MUST pop the Prefix-SID. This is equivalent to the 321 penultimate hop popping mechanism used in the MPLS dataplane which 322 improves performance of the ultimate hop. MPLS EXP bits of the 323 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 324 being removed). If the P-flag is unset the received E-flag is 325 ignored. 327 o If the P-flag is set then: 329 * If the E-flag is not set then any upstream neighbor of the 330 Prefix-SID originator MUST keep the Prefix-SID on top of the 331 stack. This is useful when, e.g., the originator of the 332 Prefix-SID must stitch the incoming packet into a continuing 333 MPLS LSP to the final destination. This could occur at an 334 inter-area border router (prefix propagation from one area to 335 another) or at an inter-domain border router (prefix 336 propagation from one domain to another). 338 * If the E-flag is set then any upstream neighbor of the Prefix- 339 SID originator MUST replace the PrefixSID with a Prefix-SID 340 having an Explicit-NULL value. This is useful, e.g., when the 341 originator of the Prefix-SID is the final destination for the 342 related prefix and the originator wishes to receive the packet 343 with the original EXP bits. 345 When propagating (either from Level-1 to Level-2 or vice versa) a 346 reachability advertisement originated by another IS-IS speaker, the 347 router MUST set the P-flag and MUST clear the E-flag of the related 348 Prefix-SIDs. 350 2.1.2. Prefix-SID Propagation 352 The Prefix-SID sub-TLV MUST be included when the associated Prefix 353 Reachability TLV is propagated across level boundaries. 355 The level-1-2 router that propagates the Prefix-SID sub-TLV between 356 levels maintains the content (flags and SID) except as noted in 357 Section 2.1.1.2 and Section 2.1.1.3. 359 2.2. Adjacency Segment Identifier 361 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 362 TLV (Adj-SID sub-TLV). 364 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 365 Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and 366 fields that may be used, in future extensions of Segment Routing, for 367 carrying other types of SIDs. 369 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 370 below: 372 TLV-22 (Extended IS reachability)[RFC5305] 374 TLV-222 (Multitopology IS)[RFC5120] 376 TLV-23 (IS Neighbor Attribute)[RFC5311] 378 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 379 TLV-141 (inter-AS reachability information)[RFC5316] 381 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 382 neighbor. 384 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 386 The following format is defined for the Adj-SID sub-TLV: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | Flags | Weight | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | SID/Label/Index (variable) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 where: 398 Type: 31 400 Length: 5 or 6 depending on size of the SID 402 Flags: 1 octet field of following flags: 404 0 1 2 3 4 5 6 7 405 +-+-+-+-+-+-+-+-+ 406 |F|B|V|L|S|P| | 407 +-+-+-+-+-+-+-+-+ 409 where: 411 F-Flag: Address-Family flag. If unset, then the Adj-SID is 412 used when forwarding IPv4 encapsulated traffic to the neighbor. 413 If set then the Adj-SID is used when forwarding IPv6 414 encapsulated traffic to the neighbor. 416 B-Flag: Backup flag. If set, the Adj-SID is eligible for 417 protection (e.g.: using IPFRR or MPLS-FRR) as described in 418 [RFC8402]. 420 V-Flag: Value flag. If set, then the Adj-SID carries a value. 421 By default the flag is SET. 423 L-Flag: Local Flag. If set, then the value/index carried by 424 the Adj-SID has local significance. By default the flag is 425 SET. 427 S-Flag. Set flag. When set, the S-Flag indicates that the 428 Adj-SID refers to a set of adjacencies (and therefore MAY be 429 assigned to other adjacencies as well). 431 P-Flag. Persistent flag. When set, the P-Flag indicates that 432 the Adj-SID is persistently allocated, i.e., the Adj-SID value 433 remains consistent across router restart and/or interface flap. 435 Other bits: MUST be zero when originated and ignored when 436 received. 438 Weight: 1 octet. The value represents the weight of the Adj-SID 439 for the purpose of load balancing. The use of the weight is 440 defined in [RFC8402]. 442 SID/Index/Label as defined in Section 2.1.1.1. 444 An SR capable router MAY allocate an Adj-SID for each of its 445 adjacencies 447 An SR capable router MAY allocate more than one Adj-SID to an 448 adjacency. 450 An SR capable router MAY allocate the same Adj-SID to different 451 adjacencies. 453 When the P-flag is not set, the Adj-SID MAY be persistent. When 454 the P-flag is set, the Adj-SID MUST be persistent. 456 Examples of use of the Adj-SID sub-TLV are described in [RFC8402]. 458 The F-flag is used in order for the router to advertise the 459 outgoing encapsulation of the adjacency the Adj-SID is attached 460 to. 462 2.2.2. Adjacency Segment Identifiers in LANs 464 In LAN subnetworks, the Designated Intermediate System (DIS) is 465 elected and originates the Pseudonode-LSP (PN-LSP) including all 466 neighbors of the DIS. 468 When Segment Routing is used, each router in the LAN MAY advertise 469 the Adj-SID of each of its neighbors. Since, on LANs, each router 470 only advertises one adjacency to the DIS (and doesn't advertise any 471 other adjacency), each router advertises the set of Adj-SIDs (for 472 each of its neighbors) inside a newly defined sub-TLV part of the TLV 473 advertising the adjacency to the DIS (e.g.: TLV-22). 475 The following new sub-TLV is defined: LAN-Adj-SID containing the set 476 of Adj-SIDs the router assigned to each of its LAN neighbors. 478 The format of the LAN-Adj-SID sub-TLV is as follows: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | Flags | Weight | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Neighbor System-ID (ID length octets) | 488 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | SID/Label/Index (variable) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 where: 498 Type: 32 500 Length: variable. 502 Flags: 1 octet field of following flags: 504 0 1 2 3 4 5 6 7 505 +-+-+-+-+-+-+-+-+ 506 |F|B|V|L|S|P| | 507 +-+-+-+-+-+-+-+-+ 509 where F, B, V, L, S and P flags are defined in Section 2.2.1. 510 Other bits: MUST be zero when originated and ignored when 511 received. 513 Weight: 1 octet. The value represents the weight of the Adj-SID 514 for the purpose of load balancing. The use of the weight is 515 defined in [RFC8402]. 517 Neighbor System-ID: IS-IS System-ID of length "ID Length" as 518 defined in [ISO10589]. 520 SID/Index/Label as defined in Section 2.1.1.1. 522 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 524 Note that this sub-TLV MUST NOT appear in TLV 141. 526 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 527 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 528 advertisements of the adjacency to the DIS MUST be used and all 529 advertisements MUST have the same metric. 531 Each router within the level, by receiving the DIS PN LSP as well as 532 the non-PN LSP of each router in the LAN, is capable of 533 reconstructing the LAN topology as well as the set of Adj-SIDs each 534 router uses for each of its neighbors. 536 2.3. SID/Label Sub-TLV 538 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 539 defined in this document: 541 SR-Capabilities Sub-TLV (Section 3.1) 543 SR Local Block Sub-TLV (Section 3.3) 545 SID/Label Binding TLV (Section 2.4) 547 Multi-Topology SID/Label Binding TLV (Section 2.5) 549 Note that the code point used in all of the above cases is the SID/ 550 Label Sub-TLV code point specified in the new "sub-TLVs for TLV 149 551 and 150" registry created by this document. 553 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 554 sub-TLV has the following format: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | SID/Label (variable) | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 where: 566 Type: 1 568 Length: 3 or 4 569 SID/Label: if length is set to 3 then the 20 rightmost bits 570 represent a MPLS label. If length is set to 4 then the value is a 571 32 bit index 573 2.4. SID/Label Binding TLV 575 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 576 domain. There are multiple uses of the SID/Label Binding TLV. 578 The SID/Label Binding TLV may be used to advertise prefixes to SID/ 579 Label mappings. This functionality is called the Segment Routing 580 Mapping Server (SRMS). The behavior of the SRMS is defined in 581 [I-D.ietf-spring-segment-routing-ldp-interop]. 583 The SID/Label Binding TLV may also be used to advertise a Mirror SID 584 to advertise the ability to process traffic originally destined to 585 another IGP node. This behavior is defined in [RFC8402]. 587 The SID/Label Binding TLV has the following format: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | Flags | RESERVED | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Range | Prefix Length | Prefix | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 // Prefix (continued, variable) // 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Sub-TLVs (variable) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 1: SID/Label Binding TLV format 603 o Type: 149 605 o Length: variable. 607 o 1 octet of flags 609 o 1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be 610 ignored on receipt) 612 o 2 octets of Range 614 o 1 octet of Prefix Length 616 o 0-16 octets of Prefix 617 o sub-TLVs, where each sub-TLV consists of a sequence of: 619 * 1 octet of sub-TLV type 621 * 1 octet of length of the value field of the sub-TLV 623 * 0-243 octets of value 625 2.4.1. Flags 627 Flags: 1 octet field of following flags: 629 0 1 2 3 4 5 6 7 630 +-+-+-+-+-+-+-+-+ 631 |F|M|S|D|A| | 632 +-+-+-+-+-+-+-+-+ 634 where: 636 F-Flag: Address Family flag. If unset, then the Prefix carries an 637 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 639 M-Flag: Mirror Context flag. Set if the advertised SID 640 corresponds to a mirrored context. The use of a mirrored context 641 is described in [RFC8402]. 643 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 644 the entire routing domain. If the S flag is not set, the SID/ 645 Label Binding TLV MUST NOT be leaked between levels. This bit 646 MUST NOT be altered during the TLV leaking. 648 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 649 level-1, the D-Flag MUST be set. Otherwise, this flag MUST be 650 clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be 651 leaked from level-1 to level-2. This is to prevent TLV looping 652 across levels. 654 A-Flag: Attached flag. The originator of the SID/Label Binding 655 TLV MAY set the A bit in order to signal that the prefixes and 656 SIDs advertised in the SID/Label Binding TLV are directly 657 connected to their originators. The mechanisms through which the 658 originator of the SID/Label Binding TLV can figure out if a prefix 659 is attached or not are outside the scope of this document (e.g.: 660 through explicit configuration). If the Binding TLV is leaked to 661 other areas/levels the A-flag MUST be cleared. 663 An implementation may decide not to honor the S-flag in order not 664 to leak Binding TLV's between levels (for policy reasons). 666 Other bits: MUST be zero when originated and ignored when 667 received. 669 2.4.2. Range 671 The 'Range' field provides the ability to specify a range of 672 addresses and their associated Prefix SIDs. This advertisement 673 supports the SRMS functionality. It is essentially a compression 674 scheme to distribute a continuous Prefix and their continuous, 675 corresponding SID/Label Block. If a single SID is advertised then 676 the range field MUST be set to one. For range advertisements > 1, 677 the range field MUST be set to the number of addresses that need to 678 be mapped into a Prefix-SID. In either case the prefix is the first 679 address to which a SID is to be assigned. 681 2.4.3. Prefix Length, Prefix 683 The 'Prefix' represents the Forwarding equivalence class at the tail- 684 end of the advertised path. The 'Prefix' does not need to correspond 685 to a routable prefix of the originating node. 687 The 'Prefix Length' field contains the length of the prefix in bits. 688 Only the most significant octets of the Prefix are encoded (i.e., 1 689 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 690 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 691 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 693 2.4.4. Mapping Server Prefix-SID 695 The Prefix-SID sub-TLV is defined in Section 2.1 and contains the 696 SID/index/label value associated with the prefix and range. The 697 Prefix-SID Sub-TLV MUST be present in the SID/Label Binding TLV when 698 the M-flag is clear. The Prefix-SID Sub-TLV MUST NOT be present when 699 the M-flag is set. 701 2.4.4.1. Prefix-SID Flags 703 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 704 MAY advertise a mapping with the N flag set when the prefix being 705 mapped is known in the link-state topology with a mask length of 32 706 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 707 mechanisms through which the operator defines that a prefix 708 represents a node are outside the scope of this document (typically 709 it will be through configuration). 711 The other flags defined in Section 2.1 are not used by the Mapping 712 Server and MUST be ignored at reception. 714 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 716 As the mapping server does not specify the originator of a prefix 717 advertisement it is not possible to determine PHP behavior solely 718 based on the Mapping Server Advertisement. However, if additional 719 information is available PHP behavior may safely be done. The 720 required information consists of: 722 o A prefix reachability advertisement for the prefix has been 723 received which includes the Prefix Attribute Flags sub-TLV 724 [RFC7794]. 726 o X and R flags are both set to 0 in the Prefix Attribute Flags sub- 727 TLV. 729 In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A 730 flag in the binding TLV indicates that the originator of a prefix 731 reachability advertisement is directly connected to the prefix and 732 thus PHP MUST be done by the neighbors of the router originating the 733 prefix reachability advertisement. Note that A-flag is only valid in 734 the original area in which the Binding TLV is advertised. 736 2.4.4.3. Prefix-SID Algorithm 738 The algorithm field contains the identifier of the algorithm 739 associated with the SIDs for the prefix(es) in the range. Use of the 740 algorithm field is described in Section 2.1. 742 2.4.5. SID/Label Sub-TLV 744 The SID/Label sub-TLV (Type: 1) contains the SID/Label value as 745 defined in Section 2.3. It MUST be present in the SID/Label Binding 746 TLV when the M-flag is set in the Flags field of the parent TLV. 748 2.4.6. Example Encodings 750 Example 1: if the following IPv4 router addresses (loopback 751 addresses) need to be mapped into the corresponding Prefix SID 752 indexes. 754 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 755 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 756 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 757 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Length |0|0|0|0|0| | RESERVED | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Range = 4 | 32 | 192 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | 0 | 2 | 1 |Prefix-SID Type| 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | sub-TLV Length| Flags | Algorithm | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | 1 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Example-2: If the following IPv4 prefixes need to be mapped into the 773 corresponding Prefix-SID indexes: 775 10.1.1/24, Prefix-SID: Index 51 776 10.1.2/24, Prefix-SID: Index 52 777 10.1.3/24, Prefix-SID: Index 53 778 10.1.4/24, Prefix-SID: Index 54 779 10.1.5/24, Prefix-SID: Index 55 780 10.1.6/24, Prefix-SID: Index 56 781 10.1.7/24, Prefix-SID: Index 57 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type | Length |0|0|0|0|0| | RESERVED | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Range = 7 | 24 | 10 | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | 1 | 1 |Prefix-SID Type| sub-TLV Length| 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Flags | Algorithm | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | 51 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Example-3: If the following IPv6 prefixes need to be mapped into the 798 corresponding Prefix-SID indexes: 800 2001:db8:1/48, Prefix-SID: Index 151 801 2001:db8:2/48, Prefix-SID: Index 152 802 2001:db8:3/48, Prefix-SID: Index 153 803 2001:db8:4/48, Prefix-SID: Index 154 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length |1|0|0|0|0| | RESERVED | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Range = 4 | 48 | 0x20 | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | 0x01 | 0x0d | 0xb8 | 0x00 | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | 0x01 |Prefix-SID Type| sub-TLV Length| Flags | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Algorithm | 0 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | 151 | 818 +-+-+-+-+-+-+-+-+ 820 It is not expected that a network operator will be able to keep fully 821 continuous Prefix / SID/Index mappings. In order to support 822 noncontinuous mapping ranges an implementation MAY generate several 823 instances of Binding TLVs. 825 For example if a router wants to advertise the following ranges: 827 Range 16: { 192.0.2.1-15, Index 1-15 } 829 Range 6: { 192.0.2.22-27, Index 22-27 } 831 Range 41: { 192.0.2.44-84, Index 80-120 } 833 A router would need to advertise three instances of the Binding TLV. 835 2.5. Multi-Topology SID/Label Binding TLV 837 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 838 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 839 has the same format as the SID/Label Binding TLV defined in 840 Section 2.4 with the difference consisting of a Multitopology 841 Identifier (MTID) as defined here below: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Type | Length | MTID | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Flags | RESERVED | Range | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Prefix Length | Prefix (variable) // 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Sub-TLVs (variable) | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure 2: Multi-Topology SID/Label Binding TLV format 857 where: 859 Type: 150 861 Length: variable 863 MTID is the multitopology identifier defined as: 865 0 1 866 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | RESVD | MTID | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 RESVD: reserved bits. MUST be reset on transmission and 872 ignored on receive. 874 MTID: a 12-bit field containing the non-zero ID of the topology 875 being announced. The TLV MUST be ignored if the ID is zero. 876 This is to ensure the consistent view of the standard unicast 877 topology. 879 The other fields and Sub-TLVs are defined in Section 2.4. 881 3. Router Capabilities 883 This section defines sub-TLVs which are inserted into the IS-IS 884 Router Capability TLV-242 that is defined in [RFC7981]. 886 3.1. SR-Capabilities Sub-TLV 888 Segment Routing requires each router to advertise its SR data-plane 889 capability and the range of MPLS label values it uses for Segment 890 Routing in the case where global SIDs are allocated (i.e., global 891 indexes). Data-plane capabilities and label ranges are advertised 892 using the newly defined SR-Capabilities sub-TLV. 894 The Router Capability TLV specifies flags that control its 895 advertisement. The SR Capabilities sub-TLV MUST be propagated 896 throughout the level and MUST NOT be advertised across level 897 boundaries. Therefore Router Capability TLV distribution flags are 898 set accordingly, i.e., the S flag in the Router Capability TLV 899 [RFC7981] MUST be unset. 901 The SR Capabilities sub-TLV has following format: 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Length | Flags | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Range | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 // SID/Label Sub-TLV (variable) // 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Type: 2 917 Length: variable. 919 Flags: 1 octet of flags. The following are defined: 921 0 1 2 3 4 5 6 7 922 +-+-+-+-+-+-+-+-+ 923 |I|V| | 924 +-+-+-+-+-+-+-+-+ 926 where: 928 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 929 processing SR MPLS encapsulated IPv4 packets on all interfaces. 931 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 932 processing SR MPLS encapsulated IPv6 packets on all interfaces. 934 One or more SRGB Descriptor entries, each of which have the 935 following format: 937 Range: 3 octets. 939 SID/Label sub-TLV (as defined in Section 2.3). 941 SID/Label sub-TLV contains the first value of the SRGB while the 942 range contains the number of SRGB elements. The range value MUST be 943 higher than 0. 945 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 946 but a router MUST NOT advertise more than one SR-Capabilities sub- 947 TLV. A router receiving multiple SR-Capabilities sub-TLVs from the 948 same originator SHOULD select the first advertisement in the lowest 949 numbered LSP. 951 When multiple SRGB Descriptors are advertised the entries define an 952 ordered set of ranges on which a SID index is to be applied. For 953 this reason changing the order in which the descriptors are 954 advertised will have a disruptive effect on forwarding. 956 When a router adds a new SRGB Descriptor to an existing SR- 957 Capabilities sub-TLV the new Descriptor SHOULD add the newly 958 configured block at the end of the sub-TLV and SHOULD NOT change the 959 order of previously advertised blocks. Changing the order of the 960 advertised descriptors will create label churn in the FIB and 961 blackhole / misdirect some traffic during the IGP convergence. In 962 particular, if a range which is not the last is extended it's 963 preferable to add a new range rather than extending the previously 964 advertised range. 966 The originating router MUST ensure the order is unchanged after a 967 graceful restart (using checkpointing, non-volatile storage or any 968 other mechanism). 970 The originating router MUST NOT advertise overlapping ranges. 972 When a router receives multiple overlapping ranges, it MUST conform 973 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 975 Here follows an example of advertisement of multiple ranges: 977 The originating router advertises following ranges: 978 SR-Cap: range: 100, SID value: 100 979 SR-Cap: range: 100, SID value: 1000 980 SR-Cap: range: 100, SID value: 500 982 The receiving routers concatenate the ranges in the received 983 order and build the SRGB as follows: 985 SRGB = [100, 199] 986 [1000, 1099] 987 [500, 599] 989 The indexes span multiple ranges: 991 index=0 means label 100 992 ... 993 index 99 means label 199 994 index 100 means label 1000 995 index 199 means label 1099 996 ... 997 index 200 means label 500 998 ... 1000 3.2. SR-Algorithm Sub-TLV 1002 The router may use various algorithms when calculating reachability 1003 to other nodes or to prefixes attached to these nodes. Examples of 1004 these algorithms are metric based Shortest Path First (SPF), various 1005 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the 1006 router to advertise the algorithms that the router is currently 1007 using. Algorithm values are defined in the "IGP Algorithm Type" 1008 registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The 1009 following values have been defined: 1011 0: Shortest Path First (SPF) algorithm based on link metric. This 1012 is the well-known shortest path algorithm as computed by the IS-IS 1013 Decision process. Consistent with the deployed practice for link- 1014 state protocols, algorithm 0 permits any node to overwrite the SPF 1015 path with a different path based on local policy. 1017 1: Strict Shortest Path First (SPF) algorithm based on link 1018 metric. The algorithm is identical to algorithm 0 but algorithm 1 1019 requires that all nodes along the path will honor the SPF routing 1020 decision. Local policy MUST NOT alter the forwarding decision 1021 computed by algorithm 1 at the node claiming to support algorithm 1022 1. 1024 The Router Capability TLV specifies flags that control its 1025 advertisement. The SR-Algorithm MUST be propagated throughout the 1026 level and MUST NOT be advertised across level boundaries. Therefore 1027 Router Capability TLV distribution flags are set accordingly, i.e., 1028 the S flag MUST be unset. 1030 The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more 1031 than once at a given level. A router receiving multiple SR-Algorithm 1032 sub-TLVs from the same originator SHOULD select the first 1033 advertisement in the lowest numbered LSP. 1035 When the originating router does not advertise the SR-Algorithm sub- 1036 TLV, this implies that the only algorithm supported by routers 1037 supporting the extensions defined in this document is Algorithm 0. 1039 When the originating router does advertise the SR-Algorithm sub-TLV, 1040 then algorithm 0 MUST be present while non-zero algorithms MAY be 1041 present. 1043 The SR-Algorithm sub-TLV has the following format: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Type | Length | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 where: 1055 Type: 19 1057 Length: variable. 1059 Algorithm: 1 octet of algorithm 1061 3.3. SR Local Block Sub-TLV 1063 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1064 node has reserved for local SIDs. Local SIDs are used, e.g., for 1065 Adjacency-SIDs, and may also be allocated by components other than 1066 the IS-IS protocol. As an example, an application or a controller 1067 may instruct the router to allocate a specific local SID. Therefore, 1068 in order for such applications or controllers to know what are the 1069 local SIDs available in the router, it is required that the router 1070 advertises its SRLB. 1072 The SRLB Sub-TLV is used for this purpose and has following format: 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type | Length | Flags | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Range | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 // SID/Label Sub-TLV (variable) // 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Type: 22 1088 Length: variable. 1090 Flags: 1 octet of flags. None are defined at this stage. 1092 One or more SRLB Descriptor entries, each of which have the 1093 following format: 1095 Range: 3 octets. 1097 SID/Label sub-TLV (as defined in Section 2.3). 1099 SID/Label sub-TLV contains the first value of the SRLB while the 1100 range contains the number of SRLB elements. The range value MUST be 1101 higher than 0. 1103 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1104 router MUST NOT advertise more than one SRLB sub-TLV. A router 1105 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1106 select the first advertisement in the lowest numbered LSP. 1108 The originating router MUST NOT advertise overlapping ranges. 1110 When a router receives multiple overlapping ranges, it MUST conform 1111 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 1113 It is important to note that each time a SID from the SRLB is 1114 allocated, it should also be reported to all components (e.g.: 1115 controller or applications) in order for these components to have an 1116 up-to-date view of the current SRLB allocation and in order to avoid 1117 collision between allocation instructions. 1119 Within the context of IS-IS, the reporting of local SIDs is done 1120 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1121 reporting of allocated local SIDs may also be done through other 1122 means and protocols which are outside the scope of this document. 1124 A router advertising the SRLB sub-TLV may also have other label 1125 ranges, outside the SRLB, for its local allocation purposes which are 1126 NOT advertised in the SRLB. For example, it is possible that an 1127 Adjacency-SID is allocated using a local label not part of the SRLB. 1129 3.4. SRMS Preference Sub-TLV 1131 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1132 in order to associate a preference with SRMS advertisements from a 1133 particular source. 1135 The SRMS Preference sub-TLV has following format: 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 | Preference | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Type: 24 1145 Length: 1. 1147 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1149 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1150 but a router MUST NOT advertise more than one SRMS Preference sub- 1151 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1152 same originator, SHOULD select the first advertisement in the lowest 1153 numbered LSP. 1155 The use of the SRMS Preference during the SID selection process is 1156 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1158 4. IANA Considerations 1160 This document requests allocation for the following TLVs and Sub- 1161 TLVs. 1163 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 1165 This document makes the following registrations in the "sub-TLVs for 1166 TLV 22, 23, 25, 141, 222 and 223" registry. 1168 Type Description 22 23 25 141 222 223 1169 ---- -------------------------------- --- --- --- --- --- --- 1170 31 Adjacency Segment Identifier y y n y y y 1171 32 LAN Adjacency Segment Identifier y y n y y y 1173 4.2. Sub TLVs for Type 135,235,236 and 237 1175 This document makes the following registrations in the "sub-TLVs for 1176 TLV 135,235,236 and 237" registry. 1178 Type Description 135 235 236 237 1179 ---- ------------------------- --- --- --- --- 1180 3 Prefix Segment Identifier y y y y 1182 4.3. Sub TLVs for Type 242 1184 This document makes the following registrations in the "sub-TLVs for 1185 TLV 242" registry. 1187 Type Description 1188 ---- ----------- 1189 2 Segment Routing Capability 1190 19 Segment Routing Algorithm 1191 22 Segment Routing Local Block (SRLB) 1192 24 Segment Routing Mapping Server Preference 1193 (SRMS Preference) 1195 4.4. New TLV Codepoint and Sub-TLV registry 1197 This document registers the following TLV: 1199 Value Name IIH LSP SNP Purge 1200 ----- --------------------------------- --- --- --- ----- 1201 149 Segment Identifier/Label Binding n y n n 1202 150 Multi-Topology Segment Identifier n y n n 1203 /Label Binding 1205 This document creates the following sub-TLV Registry: 1207 Name: sub-TLVs for TLVs 149 and 150 1208 Registration Procedure: Expert Review 1210 Type Description 1211 ---- ----------- 1212 0 Reserved 1213 1 SID/Label 1214 2 Unassigned 1215 3 Prefix SID 1216 4-255 Unassigned 1218 5. Security Considerations 1220 With the use of the extensions defined in this document, IS-IS 1221 carries information which will be used to program the MPLS data plane 1222 [RFC3031]. In general, the same types of attacks that can be carried 1223 out on the IP/IPv6 control plane can be carried out on the MPLS 1224 control plane resulting in traffic being misrouted in the respective 1225 data planes. However, the latter may be more difficult to detect and 1226 isolate. 1228 Existing security extensions as described in [RFC5304] and [RFC5310] 1229 apply to these segment routing extensions. 1231 6. Acknowledgements 1233 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1234 Francois and Jesper Skrivers for their contribution to the content of 1235 this document. 1237 7. Contributors 1239 The following people gave a substantial contribution to the content 1240 of this document and should be considered as co-authors: 1242 Stephane Litkowski 1243 Orange 1244 FR 1246 Email: stephane.litkowski@orange.com 1248 Jeff Tantsura 1249 Apstra, Inc. 1251 Email: jefftant@gmail.com 1253 Peter Psenak 1254 Cisco Systems Inc. 1255 US 1257 Email: ppsenak@cisco.com 1259 Martin Horneffer 1260 Deutsche Telekom 1261 DE 1263 Email: Martin.Horneffer@telekom.de 1265 Wim Henderickx 1266 Nokia 1267 BE 1269 Email: wim.henderickx@nokia.com 1271 Edward Crabbe 1272 Oracle 1273 US 1275 Email: edward.crabbe@oracle.com 1277 Rob Shakir 1278 Google 1279 UK 1281 Email: robjs@google.com 1283 Igor Milojevic 1284 Individual 1285 RS 1287 Email: milojevicigor@gmail.com 1289 Saku Ytti 1290 TDC 1291 FI 1293 Email: saku@ytti.fi 1295 Steven Luong 1296 Cisco Systems Inc. 1298 US 1300 Email: sluong@cisco.com 1302 8. References 1304 8.1. Normative References 1306 [I-D.ietf-ospf-segment-routing-extensions] 1307 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1308 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1309 Extensions for Segment Routing", draft-ietf-ospf-segment- 1310 routing-extensions-27 (work in progress), December 2018. 1312 [I-D.ietf-spring-segment-routing-ldp-interop] 1313 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1314 S. Litkowski, "Segment Routing interworking with LDP", 1315 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1316 progress), September 2018. 1318 [I-D.ietf-spring-segment-routing-mpls] 1319 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1320 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1321 data plane", draft-ietf-spring-segment-routing-mpls-22 1322 (work in progress), May 2019. 1324 [ISO10589] 1325 International Organization for Standardization, 1326 "Intermediate system to Intermediate system intra-domain 1327 routeing information exchange protocol for use in 1328 conjunction with the protocol for providing the 1329 connectionless-mode Network Service (ISO 8473)", ISO/ 1330 IEC 10589:2002, Second Edition, Nov 2002. 1332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1333 Requirement Levels", BCP 14, RFC 2119, 1334 DOI 10.17487/RFC2119, March 1997, 1335 . 1337 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1338 Label Switching Architecture", RFC 3031, 1339 DOI 10.17487/RFC3031, January 2001, 1340 . 1342 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1343 Topology (MT) Routing in Intermediate System to 1344 Intermediate Systems (IS-ISs)", RFC 5120, 1345 DOI 10.17487/RFC5120, February 2008, 1346 . 1348 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1349 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1350 2008, . 1352 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1353 and M. Fanto, "IS-IS Generic Cryptographic 1354 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1355 2009, . 1357 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1358 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1359 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1360 March 2016, . 1362 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1363 for Advertising Router Information", RFC 7981, 1364 DOI 10.17487/RFC7981, October 2016, 1365 . 1367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1368 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1369 May 2017, . 1371 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1372 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1373 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1374 July 2018, . 1376 8.2. Informative References 1378 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1379 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1380 2008, . 1382 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1383 DOI 10.17487/RFC5308, October 2008, 1384 . 1386 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1387 Shand, "Simplified Extension of Link State PDU (LSP) Space 1388 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1389 . 1391 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1392 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1393 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1394 December 2008, . 1396 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1397 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1398 Packet Routing in Networking (SPRING) Problem Statement 1399 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1400 2016, . 1402 Authors' Addresses 1404 Stefano Previdi (editor) 1405 Huawei 1406 IT 1408 Email: stefano@previdi.net 1410 Les Ginsberg (editor) 1411 Cisco Systems, Inc. 1412 USA 1414 Email: ginsberg@cisco.com 1416 Clarence Filsfils 1417 Cisco Systems, Inc. 1418 Brussels 1419 BE 1421 Email: cfilsfil@cisco.com 1423 Ahmed Bashandy 1424 Arrcus 1426 Email: abashandy.ietf@gmail.com 1428 Hannes Gredler 1429 RtBrick Inc. 1431 Email: hannes@rtbrick.com 1432 Bruno Decraene 1433 Orange 1434 FR 1436 Email: bruno.decraene@orange.com