idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-24.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 1170 has weird spacing: '...ntifier y ...' == Line 1200 has weird spacing: '...Binding n ...' == Line 1201 has weird spacing: '...ntifier n y...' -- The document date (April 17, 2019) is 1833 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 984 -- Looks like a reference, but probably isn't: '199' on line 984 -- Looks like a reference, but probably isn't: '1000' on line 985 -- Looks like a reference, but probably isn't: '1099' on line 985 -- Looks like a reference, but probably isn't: '500' on line 986 -- Looks like a reference, but probably isn't: '599' on line 986 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-21 -- 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 (~~), 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 Huawei 4 Intended status: Standards Track L. Ginsberg, Ed. 5 Expires: October 19, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 A. Bashandy 8 Arrcus 9 H. Gredler 10 RtBrick Inc. 11 B. Decraene 12 Orange 13 April 17, 2019 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-24 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 October 19, 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 611 o 2 octets of Range 613 o 1 octet of Prefix Length 615 o 0-16 octets of Prefix 616 o sub-TLVs, where each sub-TLV consists of a sequence of: 618 * 1 octet of sub-TLV type 620 * 1 octet of length of the value field of the sub-TLV 622 * 0-243 octets of value 624 2.4.1. Flags 626 Flags: 1 octet field of following flags: 628 0 1 2 3 4 5 6 7 629 +-+-+-+-+-+-+-+-+ 630 |F|M|S|D|A| | 631 +-+-+-+-+-+-+-+-+ 633 where: 635 F-Flag: Address Family flag. If unset, then the Prefix carries an 636 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 638 M-Flag: Mirror Context flag. Set if the advertised SID 639 corresponds to a mirrored context. The use of a mirrored context 640 is described in [RFC8402]. 642 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 643 the entire routing domain. If the S flag is not set, the SID/ 644 Label Binding TLV MUST NOT be leaked between levels. This bit 645 MUST NOT be altered during the TLV leaking. 647 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 648 level-1, the D-Flag MUST be set. Otherwise, this flag MUST be 649 clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be 650 leaked from level-1 to level-2. This is to prevent TLV looping 651 across levels. 653 A-Flag: Attached flag. The originator of the SID/Label Binding 654 TLV MAY set the A bit in order to signal that the prefixes and 655 SIDs advertised in the SID/Label Binding TLV are directly 656 connected to their originators. The mechanisms through which the 657 originator of the SID/Label Binding TLV can figure out if a prefix 658 is attached or not are outside the scope of this document (e.g.: 659 through explicit configuration). If the Binding TLV is leaked to 660 other areas/levels the A-flag MUST be cleared. 662 An implementation may decide not to honor the S-flag in order not 663 to leak Binding TLV's between levels (for policy reasons). 665 Other bits: MUST be zero when originated and ignored when 666 received. 668 2.4.2. Range 670 The 'Range' field provides the ability to specify a range of 671 addresses and their associated Prefix SIDs. This advertisement 672 supports the SRMS functionality. It is essentially a compression 673 scheme to distribute a continuous Prefix and their continuous, 674 corresponding SID/Label Block. If a single SID is advertised then 675 the range field MUST be set to one. For range advertisements > 1, 676 the range field MUST be set to the number of addresses that need to 677 be mapped into a Prefix-SID. In either case the prefix is the first 678 address to which a SID is to be assigned. 680 2.4.3. Prefix Length, Prefix 682 The 'Prefix' represents the Forwarding equivalence class at the tail- 683 end of the advertised path. The 'Prefix' does not need to correspond 684 to a routable prefix of the originating node. 686 The 'Prefix Length' field contains the length of the prefix in bits. 687 Only the most significant octets of the Prefix are encoded (i.e., 1 688 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 689 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 690 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 692 2.4.4. Mapping Server Prefix-SID 694 The Prefix-SID sub-TLV is defined in Section 2.1 and contains the 695 SID/index/label value associated with the prefix and range. The 696 Prefix-SID Sub-TLV MUST be present in the SID/Label Binding TLV when 697 the M-flag is clear. The Prefix-SID Sub-TLV MUST NOT be present when 698 the M-flag is set. 700 2.4.4.1. Prefix-SID Flags 702 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 703 MAY advertise a mapping with the N flag set when the prefix being 704 mapped is known in the link-state topology with a mask length of 32 705 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 706 mechanisms through which the operator defines that a prefix 707 represents a node are outside the scope of this document (typically 708 it will be through configuration). 710 The other flags defined in Section 2.1 are not used by the Mapping 711 Server and MUST be ignored at reception. 713 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 715 As the mapping server does not specify the originator of a prefix 716 advertisement it is not possible to determine PHP behavior solely 717 based on the Mapping Server Advertisement. However, if additional 718 information is available PHP behavior may safely be done. The 719 required information consists of: 721 o A prefix reachability advertisement for the prefix has been 722 received which includes the Prefix Attribute Flags sub-TLV 723 [RFC7794]. 725 o X and R flags are both set to 0 in the Prefix Attribute Flags sub- 726 TLV. 728 In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A 729 flag in the binding TLV indicates that the originator of a prefix 730 reachability advertisement is directly connected to the prefix and 731 thus PHP MUST be done by the neighbors of the router originating the 732 prefix reachability advertisement. Note that A-flag is only valid in 733 the original area in which the Binding TLV is advertised. 735 2.4.4.3. Prefix-SID Algorithm 737 The algorithm field contains the identifier of the algorithm 738 associated with the SIDs for the prefix(es) in the range. Use of the 739 algorithm field is described in Section 2.1. 741 2.4.5. SID/Label Sub-TLV 743 The SID/Label sub-TLV (Type: 1) contains the SID/Label value as 744 defined in Section 2.3. It MUST be present in the SID/Label Binding 745 TLV when the M-flag is set in the Flags field of the parent TLV. 747 2.4.6. Example Encodings 749 Example 1: if the following IPv4 router addresses (loopback 750 addresses) need to be mapped into the corresponding Prefix SID 751 indexes. 753 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 754 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 755 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 756 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 757 0 1 2 3 758 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length |0|0|0|0|0| | RESERVED | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Range = 4 | 32 | 192 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 0 | 2 | 1 |Prefix-SID Type| 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | sub-TLV Length| Flags | Algorithm | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | 1 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Example-2: If the following IPv4 prefixes need to be mapped into the 772 corresponding Prefix-SID indexes: 774 10.1.1/24, Prefix-SID: Index 51 775 10.1.2/24, Prefix-SID: Index 52 776 10.1.3/24, Prefix-SID: Index 53 777 10.1.4/24, Prefix-SID: Index 54 778 10.1.5/24, Prefix-SID: Index 55 779 10.1.6/24, Prefix-SID: Index 56 780 10.1.7/24, Prefix-SID: Index 57 782 0 1 2 3 783 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Type | Length |0|0|0|0|0| | RESERVED | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Range = 7 | 24 | 10 | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | 1 | 1 |Prefix-SID Type| sub-TLV Length| 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Flags | Algorithm | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 51 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Example-3: If the following IPv6 prefixes need to be mapped into the 797 corresponding Prefix-SID indexes: 799 2001:DB8:1/48, Prefix-SID: Index 151 800 2001:DB8:2/48, Prefix-SID: Index 152 801 2001:DB8:3/48, Prefix-SID: Index 153 802 2001:DB8:4/48, Prefix-SID: Index 154 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type | Length |1|0|0|0|0| | RESERVED | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Range = 4 | 48 | 0x20 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | 0x01 | 0x0D | 0xB8 | 0x00 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | 0x01 |Prefix-SID Type| sub-TLV Length| Flags | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Algorithm | 0 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 151 | 817 +-+-+-+-+-+-+-+-+ 819 It is not expected that a network operator will be able to keep fully 820 continuous Prefix / SID/Index mappings. In order to support 821 noncontinuous mapping ranges an implementation MAY generate several 822 instances of Binding TLVs. 824 For example if a router wants to advertise the following ranges: 826 Range 16: { 192.0.2.1-15, Index 1-15 } 828 Range 6: { 192.0.2.22-27, Index 22-27 } 830 Range 41: { 192.0.2.44-84, Index 80-120 } 832 A router would need to advertise three instances of the Binding TLV. 834 2.5. Multi-Topology SID/Label Binding TLV 836 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 837 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 838 has the same format as the SID/Label Binding TLV defined in 839 Section 2.4 with the difference consisting of a Multitopology 840 Identifier (MTID) as defined here below: 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Type | Length | MTID | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Flags | RESERVED | Range | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Prefix Length | Prefix (variable) // 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Sub-TLVs (variable) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Figure 2: Multi-Topology SID/Label Binding TLV format 856 where: 858 Type: 150 860 Length: variable 862 MTID is the multitopology identifier defined as: 864 0 1 865 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | RESVD | MTID | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 RESVD: reserved bits. MUST be reset on transmission and 871 ignored on receive. 873 MTID: a 12-bit field containing the non-zero ID of the topology 874 being announced. The TLV MUST be ignored if the ID is zero. 875 This is to ensure the consistent view of the standard unicast 876 topology. 878 The other fields and Sub-TLVs are defined in Section 2.4. 880 3. Router Capabilities 882 This section defines sub-TLVs which are inserted into the IS-IS 883 Router Capability TLV-242 that is defined in [RFC7981]. 885 3.1. SR-Capabilities Sub-TLV 887 Segment Routing requires each router to advertise its SR data-plane 888 capability and the range of MPLS label values it uses for Segment 889 Routing in the case where global SIDs are allocated (i.e., global 890 indexes). Data-plane capabilities and label ranges are advertised 891 using the newly defined SR-Capabilities sub-TLV. 893 The Router Capability TLV specifies flags that control its 894 advertisement. The SR Capabilities sub-TLV MUST be propagated 895 throughout the level and MUST NOT be advertised across level 896 boundaries. Therefore Router Capability TLV distribution flags are 897 set accordingly, i.e., the S flag in the Router Capability TLV 898 [RFC7981] MUST be unset. 900 The SR Capabilities sub-TLV has following format: 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type | Length | Flags | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Range | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 // SID/Label Sub-TLV (variable) // 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Type: 2 916 Length: variable. 918 Flags: 1 octet of flags. The following are defined: 920 0 1 2 3 4 5 6 7 921 +-+-+-+-+-+-+-+-+ 922 |I|V| | 923 +-+-+-+-+-+-+-+-+ 925 where: 927 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 928 processing SR MPLS encapsulated IPv4 packets on all interfaces. 930 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 931 processing SR MPLS encapsulated IPv6 packets on all interfaces. 933 One or more SRGB Descriptor entries, each of which have the 934 following format: 936 Range: 3 octets. 938 SID/Label sub-TLV (as defined in Section 2.3). 940 SID/Label sub-TLV contains the first value of the SRGB while the 941 range contains the number of SRGB elements. The range value MUST be 942 higher than 0. 944 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 945 but a router MUST NOT advertise more than one SR-Capabilities sub- 946 TLV. A router receiving multiple SR-Capabilities sub-TLVs from the 947 same originator SHOULD select the first advertisement in the lowest 948 numbered LSP. 950 When multiple SRGB Descriptors are advertised the entries define an 951 ordered set of ranges on which a SID index is to be applied. For 952 this reason changing the order in which the descriptors are 953 advertised will have a disruptive effect on forwarding. 955 When a router adds a new SRGB Descriptor to an existing SR- 956 Capabilities sub-TLV the new Descriptor SHOULD add the newly 957 configured block at the end of the sub-TLV and SHOULD NOT change the 958 order of previously advertised blocks. Changing the order of the 959 advertised descriptors will create label churn in the FIB and 960 blackhole / misdirect some traffic during the IGP convergence. In 961 particular, if a range which is not the last is extended it's 962 preferable to add a new range rather than extending the previously 963 advertised range. 965 The originating router MUST ensure the order is unchanged after a 966 graceful restart (using checkpointing, non-volatile storage or any 967 other mechanism). 969 The originating router MUST NOT advertise overlapping ranges. 971 When a router receives multiple overlapping ranges, it MUST conform 972 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 974 Here follows an example of advertisement of multiple ranges: 976 The originating router advertises following ranges: 977 SR-Cap: range: 100, SID value: 100 978 SR-Cap: range: 100, SID value: 1000 979 SR-Cap: range: 100, SID value: 500 981 The receiving routers concatenate the ranges in the received 982 order and build the SRGB as follows: 984 SRGB = [100, 199] 985 [1000, 1099] 986 [500, 599] 988 The indexes span multiple ranges: 990 index=0 means label 100 991 ... 992 index 99 means label 199 993 index 100 means label 1000 994 index 199 means label 1099 995 ... 996 index 200 means label 500 997 ... 999 3.2. SR-Algorithm Sub-TLV 1001 The router may use various algorithms when calculating reachability 1002 to other nodes or to prefixes attached to these nodes. Examples of 1003 these algorithms are metric based Shortest Path First (SPF), various 1004 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the 1005 router to advertise the algorithms that the router is currently 1006 using. Algorithm values are defined in the "IGP Algorithm Type" 1007 registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The 1008 following values have been defined: 1010 0: Shortest Path First (SPF) algorithm based on link metric. This 1011 is the well-known shortest path algorithm as computed by the IS-IS 1012 Decision process. Consistent with the deployed practice for link- 1013 state protocols, algorithm 0 permits any node to overwrite the SPF 1014 path with a different path based on local policy. 1016 1: Strict Shortest Path First (SPF) algorithm based on link 1017 metric. The algorithm is identical to algorithm 0 but algorithm 1 1018 requires that all nodes along the path will honor the SPF routing 1019 decision. Local policy MUST NOT alter the forwarding decision 1020 computed by algorithm 1 at the node claiming to support algorithm 1021 1. 1023 The Router Capability TLV specifies flags that control its 1024 advertisement. The SR-Algorithm MUST be propagated throughout the 1025 level and MUST NOT be advertised across level boundaries. Therefore 1026 Router Capability TLV distribution flags are set accordingly, i.e., 1027 the S flag MUST be unset. 1029 The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more 1030 than once at a given level. A router receiving multiple SR-Algorithm 1031 sub-TLVs from the same originator SHOULD select the first 1032 advertisement in the lowest numbered LSP. 1034 When the originating router does not advertise the SR-Algorithm sub- 1035 TLV, this implies that the only algorithm supported by routers 1036 supporting the extensions defined in this document is Algorithm 0. 1038 When the originating router does advertise the SR-Algorithm sub-TLV, 1039 then algorithm 0 MUST be present while non-zero algorithms MAY be 1040 present. 1042 The SR-Algorithm sub-TLV has the following format: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Type | Length | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 where: 1054 Type: 19 1056 Length: variable. 1058 Algorithm: 1 octet of algorithm 1060 3.3. SR Local Block Sub-TLV 1062 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1063 node has reserved for local SIDs. Local SIDs are used, e.g., for 1064 Adjacency-SIDs, and may also be allocated by components other than 1065 the IS-IS protocol. As an example, an application or a controller 1066 may instruct the router to allocate a specific local SID. Therefore, 1067 in order for such applications or controllers to know what are the 1068 local SIDs available in the router, it is required that the router 1069 advertises its SRLB. 1071 The SRLB Sub-TLV is used for this purpose and has following format: 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Type | Length | Flags | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Range | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 // SID/Label Sub-TLV (variable) // 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 Type: 22 1087 Length: variable. 1089 Flags: 1 octet of flags. None are defined at this stage. 1091 One or more SRLB Descriptor entries, each of which have the 1092 following format: 1094 Range: 3 octets. 1096 SID/Label sub-TLV (as defined in Section 2.3). 1098 SID/Label sub-TLV contains the first value of the SRLB while the 1099 range contains the number of SRLB elements. The range value MUST be 1100 higher than 0. 1102 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1103 router MUST NOT advertise more than one SRLB sub-TLV. A router 1104 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1105 select the first advertisement in the lowest numbered LSP. 1107 The originating router MUST NOT advertise overlapping ranges. 1109 When a router receives multiple overlapping ranges, it MUST conform 1110 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 1112 It is important to note that each time a SID from the SRLB is 1113 allocated, it should also be reported to all components (e.g.: 1114 controller or applications) in order for these components to have an 1115 up-to-date view of the current SRLB allocation and in order to avoid 1116 collision between allocation instructions. 1118 Within the context of IS-IS, the reporting of local SIDs is done 1119 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1120 reporting of allocated local SIDs may also be done through other 1121 means and protocols which are outside the scope of this document. 1123 A router advertising the SRLB sub-TLV may also have other label 1124 ranges, outside the SRLB, for its local allocation purposes which are 1125 NOT advertised in the SRLB. For example, it is possible that an 1126 Adjacency-SID is allocated using a local label not part of the SRLB. 1128 3.4. SRMS Preference Sub-TLV 1130 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1131 in order to associate a preference with SRMS advertisements from a 1132 particular source. 1134 The SRMS Preference sub-TLV has following format: 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Type | Length | Preference | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Type: 24 1144 Length: 1. 1146 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1148 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1149 but a router MUST NOT advertise more than one SRMS Preference sub- 1150 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1151 same originator, SHOULD select the first advertisement in the lowest 1152 numbered LSP. 1154 The use of the SRMS Preference during the SID selection process is 1155 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1157 4. IANA Considerations 1159 This document requests allocation for the following TLVs and Sub- 1160 TLVs. 1162 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 1164 This document makes the following registrations in the "sub-TLVs for 1165 TLV 22, 23, 25, 141, 222 and 223" registry. 1167 Type Description 22 23 25 141 222 223 1168 ---- -------------------------------- --- --- --- --- --- --- 1169 31 Adjacency Segment Identifier y y n y y y 1170 32 LAN Adjacency Segment Identifier y y n y y y 1172 4.2. Sub TLVs for Type 135,235,236 and 237 1174 This document makes the following registrations in the "sub-TLVs for 1175 TLV 135,235,236 and 237" registry. 1177 Type Description 135 235 236 237 1178 ---- ------------------------- --- --- --- --- 1179 3 Prefix Segment Identifier y y y y 1181 4.3. Sub TLVs for Type 242 1183 This document makes the following registrations in the "sub-TLVs for 1184 TLV 242" registry. 1186 Type Description 1187 ---- ----------- 1188 2 Segment Routing Capability 1189 19 Segment Routing Algorithm 1190 22 Segment Routing Local Block (SRLB) 1191 24 Segment Routing Mapping Server Preference 1192 (SRMS Preference) 1194 4.4. New TLV Codepoint and Sub-TLV registry 1196 This document registers the following TLV: 1198 Value Name IIH LSP SNP Purge 1199 ----- --------------------------------- --- --- --- ----- 1200 149 Segment Identifier/Label Binding n y n n 1201 150 Multi-Topology Segment Identifier n y n n 1202 /Label Binding 1204 This document creates the following sub-TLV Registry: 1206 Name: sub-TLVs for TLVs 149 and 150 1207 Registration Procedure: Expert Review 1209 Type Description 1210 ---- ----------- 1211 0 Reserved 1212 1 SID/Label 1213 2 Unassigned 1214 3 Prefix SID 1215 4-255 Unassigned 1217 5. Security Considerations 1219 With the use of the extensions defined in this document, IS-IS 1220 carries information which will be used to program the MPLS data plane 1221 [RFC3031]. In general, the same types of attacks that can be carried 1222 out on the IP/IPv6 control plane can be carried out on the MPLS 1223 control plane resulting in traffic being misrouted in the respective 1224 data planes. However, the latter may be more difficult to detect and 1225 isolate. 1227 Existing security extensions as described in [RFC5304] and [RFC5310] 1228 apply to these segment routing extensions. 1230 6. Acknowledgements 1232 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1233 Francois and Jesper Skrivers for their contribution to the content of 1234 this document. 1236 7. Contributors 1238 The following people gave a substantial contribution to the content 1239 of this document and should be considered as co-authors: 1241 Stephane Litkowski 1242 Orange 1243 FR 1245 Email: stephane.litkowski@orange.com 1247 Jeff Tantsura 1248 Apstra, Inc. 1250 Email: jefftant@gmail.com 1252 Peter Psenak 1253 Cisco Systems Inc. 1254 US 1256 Email: ppsenak@cisco.com 1258 Martin Horneffer 1259 Deutsche Telekom 1260 DE 1262 Email: Martin.Horneffer@telekom.de 1264 Wim Henderickx 1265 Nokia 1266 BE 1268 Email: wim.henderickx@nokia.com 1270 Edward Crabbe 1271 Oracle 1272 US 1274 Email: edward.crabbe@oracle.com 1276 Rob Shakir 1277 Google 1278 UK 1280 Email: robjs@google.com 1282 Igor Milojevic 1283 Individual 1284 RS 1286 Email: milojevicigor@gmail.com 1288 Saku Ytti 1289 TDC 1290 FI 1292 Email: saku@ytti.fi 1294 Steven Luong 1295 Cisco Systems Inc. 1297 US 1299 Email: sluong@cisco.com 1301 8. References 1303 8.1. Normative References 1305 [I-D.ietf-ospf-segment-routing-extensions] 1306 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1307 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1308 Extensions for Segment Routing", draft-ietf-ospf-segment- 1309 routing-extensions-27 (work in progress), December 2018. 1311 [I-D.ietf-spring-segment-routing-ldp-interop] 1312 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1313 S. Litkowski, "Segment Routing interworking with LDP", 1314 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1315 progress), September 2018. 1317 [I-D.ietf-spring-segment-routing-mpls] 1318 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1319 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1320 data plane", draft-ietf-spring-segment-routing-mpls-21 1321 (work in progress), April 2019. 1323 [ISO10589] 1324 International Organization for Standardization, 1325 "Intermediate system to Intermediate system intra-domain 1326 routeing information exchange protocol for use in 1327 conjunction with the protocol for providing the 1328 connectionless-mode Network Service (ISO 8473)", ISO/ 1329 IEC 10589:2002, Second Edition, Nov 2002. 1331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1332 Requirement Levels", BCP 14, RFC 2119, 1333 DOI 10.17487/RFC2119, March 1997, 1334 . 1336 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1337 Label Switching Architecture", RFC 3031, 1338 DOI 10.17487/RFC3031, January 2001, 1339 . 1341 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1342 Topology (MT) Routing in Intermediate System to 1343 Intermediate Systems (IS-ISs)", RFC 5120, 1344 DOI 10.17487/RFC5120, February 2008, 1345 . 1347 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1348 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1349 2008, . 1351 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1352 and M. Fanto, "IS-IS Generic Cryptographic 1353 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1354 2009, . 1356 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1357 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1358 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1359 March 2016, . 1361 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1362 for Advertising Router Information", RFC 7981, 1363 DOI 10.17487/RFC7981, October 2016, 1364 . 1366 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1367 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1368 May 2017, . 1370 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1371 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1372 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1373 July 2018, . 1375 8.2. Informative References 1377 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1378 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1379 2008, . 1381 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1382 DOI 10.17487/RFC5308, October 2008, 1383 . 1385 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1386 Shand, "Simplified Extension of Link State PDU (LSP) Space 1387 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1388 . 1390 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1391 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1392 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1393 December 2008, . 1395 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1396 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1397 Packet Routing in Networking (SPRING) Problem Statement 1398 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1399 2016, . 1401 Authors' Addresses 1403 Stefano Previdi (editor) 1404 Huawei 1405 IT 1407 Email: stefano@previdi.net 1409 Les Ginsberg (editor) 1410 Cisco Systems, Inc. 1411 USA 1413 Email: ginsberg@cisco.com 1415 Clarence Filsfils 1416 Cisco Systems, Inc. 1417 Brussels 1418 BE 1420 Email: cfilsfil@cisco.com 1422 Ahmed Bashandy 1423 Arrcus 1425 Email: abashandy.ietf@gmail.com 1427 Hannes Gredler 1428 RtBrick Inc. 1430 Email: hannes@rtbrick.com 1431 Bruno Decraene 1432 Orange 1433 FR 1435 Email: bruno.decraene@orange.com