idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2018) is 1955 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 1000 -- Looks like a reference, but probably isn't: '199' on line 1000 -- Looks like a reference, but probably isn't: '1000' on line 1001 -- Looks like a reference, but probably isn't: '1099' on line 1001 -- Looks like a reference, but probably isn't: '500' on line 1002 -- Looks like a reference, but probably isn't: '599' on line 1002 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 -- 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 (~~), 2 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: June 16, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 A. Bashandy 8 Individual 9 H. Gredler 10 RtBrick Inc. 11 B. Decraene 12 Orange 13 December 13, 2018 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-22 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 June 16, 2019. 53 Copyright Notice 55 Copyright (c) 2018 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 . . . . . . . . . . . . . . 9 76 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 77 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 78 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 79 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 80 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 81 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 82 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 83 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 84 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 85 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 86 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 87 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 88 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 89 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 90 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 91 4. Non backward compatible changes with prior versions of this 92 document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 96 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 97 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27 98 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 101 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 104 9.2. Informative References . . . . . . . . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 107 1. Introduction 109 Segment Routing (SR) allows for a flexible definition of end-to-end 110 paths within IGP topologies by encoding paths as sequences of 111 topological sub-paths, called "segments". These segments are 112 advertised by the link-state routing protocols (IS-IS and OSPF). 113 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 114 a node), as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 do not require any additional signaling (other than the regular IGP). 120 For example, when used in MPLS networks, SR paths do not require any 121 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 122 of LSPs established with RSVP or LDP. 124 There are additional segment types, e.g., Binding SID defined in 125 [RFC8402]. This draft also defines an advertisement for one type of 126 BindingSID: the Mirror Context segment. 128 This draft describes the necessary IS-IS extensions that need to be 129 introduced for Segment Routing operating on an MPLS data-plane. 131 Segment Routing architecture is described in [RFC8402]. 133 Segment Routing use cases are described in [RFC7855]. 135 2. Segment Routing Identifiers 137 Segment Routing architecture ([RFC8402]) defines different types of 138 Segment Identifiers (SID). This document defines the IS-IS encodings 139 for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency- 140 SID and the Binding-SID. 142 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 144 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 145 (Prefix-SID sub-TLV). 147 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 148 defined in [RFC8402]. The 'Prefix SID' MUST be unique within a given 149 IGP domain (when the L-flag is not set). The 'Prefix SID' MUST carry 150 an index (when the V-flag is not set) that determines the actual SID/ 151 label value inside the set of all advertised SID/label ranges of a 152 given router. A receiving router uses the index to determine the 153 actual SID/label value in order to construct forwarding state to a 154 particular destination router. 156 In many use-cases a 'stable transport' IP Address is overloaded as an 157 identifier of a given node. Because the IP Prefixes may be re- 158 advertised into other levels there may be some ambiguity (e.g. 159 Originating router vs. L1L2 router) for which node a particular IP 160 prefix serves as identifier. The Prefix-SID sub-TLV contains the 161 necessary flags to disambiguate IP Prefix to node mappings. 162 Furthermore if a given node has several 'stable transport' IP 163 addresses there are flags to differentiate those among other IP 164 Prefixes advertised from a given node. 166 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 167 and MAY be present in any of the following TLVs: 169 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 171 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 173 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 175 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 177 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 178 and Section 2.5 respectively. 180 When the IP Reachability TLV is propagated across level boundaries, 181 the Prefix-SID sub-TLV SHOULD be kept. 183 The Prefix-SID sub-TLV has the following format: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Flags | Algorithm | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SID/Index/Label (variable) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 where: 195 Type: TBD, suggested value 3 197 Length: variable. 199 Flags: 1 octet field of following flags: 201 0 1 2 3 4 5 6 7 202 +-+-+-+-+-+-+-+-+ 203 |R|N|P|E|V|L| | 204 +-+-+-+-+-+-+-+-+ 206 where: 208 R-Flag: Re-advertisement flag. If set, then the prefix to 209 which this Prefix-SID is attached, has been propagated by the 210 router either from another level (i.e., from level-1 to level-2 211 or the opposite) or from redistribution (e.g.: from another 212 protocol). 214 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 215 the router identified by the prefix. Typically, the N-Flag is 216 set on Prefix-SIDs attached to a router loopback address. The 217 N-Flag is set when the Prefix-SID is a Node-SID as described in 218 [RFC8402]. 220 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 221 pop the Prefix-SID before delivering the packet to the node 222 that advertised the Prefix-SID. 224 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 225 the Prefix-SID originator MUST replace the Prefix-SID with a 226 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 227 IPv6) before forwarding the packet. 229 V-Flag: Value flag. If set, then the Prefix-SID carries a 230 value (instead of an index). By default the flag is UNSET. 232 L-Flag: Local Flag. If set, then the value/index carried by 233 the Prefix-SID has local significance. By default the flag is 234 UNSET. 236 Other bits: MUST be zero when originated and ignored when 237 received. 239 Algorithm: the router may use various algorithms when calculating 240 reachability to other nodes or to prefixes attached to these 241 nodes. Algorithms identifiers are defined in Section 3.2. 242 Examples of these algorithms are metric based Shortest Path First 243 (SPF), various sorts of Constrained SPF, etc. The algorithm field 244 of the Prefix-SID contains the identifier of the algorithm the 245 router has used in order to compute the reachability of the prefix 246 to which the Prefix-SID is associated. 248 At origination, the Prefix-SID algorithm field MUST be set to 0 or 249 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 251 A router receiving a Prefix-SID from a remote node and with an 252 algorithm value that such remote node has not advertised in the 253 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 254 TLV. 256 SID/Index/Label as defined in Section 2.1.1.1. 258 2.1.1. Flags 260 2.1.1.1. V and L Flags 262 The V-flag indicates whether the SID/Index/Label field is a value or 263 an index. 265 The L-Flag indicates whether the value/index in the SID/Index/Label 266 field has local or global significance. 268 The following settings for V and L flags are valid: 270 V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field 271 is a 4 octet index defining the offset in the SID/Label space 272 advertised by this router using the encodings defined in Section 3.1. 274 V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field 275 is a 3 octet local label where the 20 rightmost bits are used for 276 encoding the label value. 278 All other combinations of V-flag and L-flag are invalid and any SID 279 advertisement received with an invalid setting for V and L flags MUST 280 be ignored. 282 2.1.1.2. R and N Flags 284 The R-Flag MUST be set for prefixes that are not local to the router 285 and either: 287 advertised because of propagation (Level-1 into Level-2); 289 advertised because of leaking (Level-2 into Level-1); 291 advertised because of redistribution (e.g.: from another 292 protocol). 294 In the case where a Level-1-2 router has local interface addresses 295 configured in one level, it may also propagate these addresses into 296 the other level. In such case, the Level-1-2 router MUST NOT set the 297 R bit. The R-bit MUST be set only for prefixes that are not local to 298 the router and advertised by the router because of propagation and/or 299 leaking. 301 The N-Flag is used in order to define a Node-SID. A router MAY set 302 the N-Flag only if all of the following conditions are met: 304 The prefix to which the Prefix-SID is attached is local to the 305 router (i.e., the prefix is configured on one of the local 306 interfaces, e.g., a 'stable transport' loopback). 308 The prefix to which the Prefix-SID is attached MUST have a Prefix 309 length of either /32 (IPv4) or /128 (IPv6). 311 The router MUST ignore the N-Flag on a received Prefix-SID if the 312 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 314 [RFC7794] also defines the N and R flags and with the same semantics 315 of the equivalent flags defined in this document. There will be a 316 transition period where both sets of flags will be used and 317 eventually only the flags of the Prefix Attributes will remain. 318 During the transition period implementations supporting the N and R 319 flags defined in this document and the N and R flags defined in 320 [RFC7794] MUST advertise and parse all flags. In case the received 321 flags have different values, the value of the flags defined in 322 [RFC7794] prevails. 324 2.1.1.3. E and P Flags 326 When calculating the outgoing label for the prefix, the router MUST 327 take into account E and P flags advertised by the next-hop router, if 328 next-hop router advertised the SID for the prefix. This MUST be done 329 regardless of next-hop router contributing to the best path to the 330 prefix or not. 332 When propagating (either from Level-1 to Level-2 or vice versa) a 333 reachability advertisement originated by another IS-IS speaker, the 334 router MUST set the P-flag and MUST clear the E-flag of the related 335 Prefix-SIDs. 337 The following behavior is associated with the settings of the E and P 338 flags: 340 o If the P-flag is not set then any upstream neighbor of the Prefix- 341 SID originator MUST pop the Prefix-SID. This is equivalent to the 342 penultimate hop popping mechanism used in the MPLS dataplane which 343 improves performance of the ultimate hop. MPLS EXP bits of the 344 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 345 being removed). If the P-flag is unset the received E-flag is 346 ignored. 348 o If the P-flag is set then: 350 * If the E-flag is not set then any upstream neighbor of the 351 Prefix-SID originator MUST keep the Prefix-SID on top of the 352 stack. This is useful when, e.g., the originator of the 353 Prefix-SID must stitch the incoming packet into a continuing 354 MPLS LSP to the final destination. This could occur at an 355 inter-area border router (prefix propagation from one area to 356 another) or at an inter-domain border router (prefix 357 propagation from one domain to another). 359 * If the E-flag is set then any upstream neighbor of the Prefix- 360 SID originator MUST replace the PrefixSID with a Prefix-SID 361 having an Explicit-NULL value. This is useful, e.g., when the 362 originator of the Prefix-SID is the final destination for the 363 related prefix and the originator wishes to receive the packet 364 with the original EXP bits. 366 2.1.2. Prefix-SID Propagation 368 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 369 gets propagated across level boundaries. 371 The level-1-2 router that propagates the Prefix-SID sub-TLV between 372 levels MUST set the R-flag. 374 If the Prefix-SID contains a global index (L and V flags unset) and 375 it is propagated as such (with L and V flags unset), the value of the 376 index MUST be preserved when propagated between levels. 378 The level-1-2 router that propagates the Prefix-SID sub-TLV between 379 levels MAY change the setting of the L and V flags in case a local 380 label value is encoded in the Prefix-SID instead of the received 381 value. 383 2.2. Adjacency Segment Identifier 385 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 386 TLV (Adj-SID sub-TLV). 388 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 389 Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and 390 fields that may be used, in future extensions of Segment Routing, for 391 carrying other types of SIDs. 393 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 394 below: 396 TLV-22 (Extended IS reachability)[RFC5305] 398 TLV-222 (Multitopology IS)[RFC5120] 400 TLV-23 (IS Neighbor Attribute)[RFC5311] 402 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 404 TLV-141 (inter-AS reachability information)[RFC5316] 406 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 407 neighbor. 409 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 411 The following format is defined for the Adj-SID sub-TLV: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Flags | Weight | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | SID/Label/Index (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 423 Type: TBD, suggested value 31 425 Length: variable. 427 Flags: 1 octet field of following flags: 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+-+ 431 |F|B|V|L|S|P| | 432 +-+-+-+-+-+-+-+-+ 434 where: 436 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 437 to an adjacency with outgoing IPv4 encapsulation. If set then 438 the Adj-SID refers to an adjacency with outgoing IPv6 439 encapsulation. 441 B-Flag: Backup flag. If set, the Adj-SID is eligible for 442 protection (e.g.: using IPFRR or MPLS-FRR) as described in 443 [RFC8355]. 445 V-Flag: Value flag. If set, then the Adj-SID carries a value. 446 By default the flag is SET. 448 L-Flag: Local Flag. If set, then the value/index carried by 449 the Adj-SID has local significance. By default the flag is 450 SET. 452 S-Flag. Set flag. When set, the S-Flag indicates that the 453 Adj-SID refers to a set of adjacencies (and therefore MAY be 454 assigned to other adjacencies as well). 456 P-Flag. Persistent flag. When set, the P-Flag indicates that 457 the Adj-SID is persistently allocated, i.e., the Adj-SID value 458 remains consistent across router restart and/or interface flap. 460 Other bits: MUST be zero when originated and ignored when 461 received. 463 Weight: 1 octet. The value represents the weight of the Adj-SID 464 for the purpose of load balancing. The use of the weight is 465 defined in [RFC8402]. 467 SID/Index/Label as defined in Section 2.1.1.1. 469 An SR capable router MAY allocate an Adj-SID for each of its 470 adjacencies and SHOULD set the B-Flag when the adjacency is 471 eligible for protection (IP or MPLS). 473 An SR capable router MAY allocate more than one Adj-SID to an 474 adjacency. 476 An SR capable router MAY allocate the same Adj-SID to different 477 adjacencies. 479 When the P-flag is not set, the Adj-SID MAY be persistent. When 480 the P-flag is set, the Adj-SID MUST be persistent. 482 Examples of use of the Adj-SID sub-TLV are described in [RFC8402]. 484 The F-flag is used in order for the router to advertise the 485 outgoing encapsulation of the adjacency the Adj-SID is attached 486 to. 488 2.2.2. Adjacency Segment Identifiers in LANs 490 In LAN subnetworks, the Designated Intermediate System (DIS) is 491 elected and originates the Pseudonode-LSP (PN-LSP) including all 492 neighbors of the DIS. 494 When Segment Routing is used, each router in the LAN MAY advertise 495 the Adj-SID of each of its neighbors. Since, on LANs, each router 496 only advertises one adjacency to the DIS (and doesn't advertise any 497 other adjacency), each router advertises the set of Adj-SIDs (for 498 each of its neighbors) inside a newly defined sub-TLV part of the TLV 499 advertising the adjacency to the DIS (e.g.: TLV-22). 501 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 502 suggested value 32) containing the set of Adj-SIDs the router 503 assigned to each of its LAN neighbors. 505 The format of the LAN-Adj-SID sub-TLV is as follows: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type | Length | Flags | Weight | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | System-ID (6 octets) | 515 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | SID/Label/Index (variable) | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 where: 525 Type: TBD, suggested value 32 527 Length: variable. 529 Flags: 1 octet field of following flags: 531 0 1 2 3 4 5 6 7 532 +-+-+-+-+-+-+-+-+ 533 |F|B|V|L|S|P| | 534 +-+-+-+-+-+-+-+-+ 536 where F, B, V, L, S and P flags are defined in Section 2.2.1. 537 Other bits: MUST be zero when originated and ignored when 538 received. 540 Weight: 1 octet. The value represents the weight of the Adj-SID 541 for the purpose of load balancing. The use of the weight is 542 defined in [RFC8402]. 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 545 defined in [ISO10589]. 547 SID/Index/Label as defined in Section 2.1.1.1. 549 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 550 MUST NOT appear in TLV 141. 552 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 553 the P-flag is set, the LAN-Adj-SID MUST be persistent. 555 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 556 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 557 advertisements of the adjacency to the DIS MUST be used and all 558 advertisements MUST have the same metric. 560 Each router within the level, by receiving the DIS PN LSP as well as 561 the non-PN LSP of each router in the LAN, is capable of 562 reconstructing the LAN topology as well as the set of Adj-SID each 563 router uses for each of its neighbors. 565 A label is encoded in 3 octets (in the 20 rightmost bits). 567 An index is encoded in 4 octets. 569 2.3. SID/Label Sub-TLV 571 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 572 defined in this document: 574 SR-Capabilities Sub-TLV (Section 3.1) 576 SR Local Block Sub-TLV (Section 3.3) 578 SID/Label Binding TLV (Section 2.4) 580 Multi-Topology SID/Label Binding TLV (Section 2.5) 582 Note that the code point used in all of the above cases is the SID/ 583 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 584 149 and 150" registry. 586 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 587 sub-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 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | SID/Label (variable) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 where: 599 Type: TBD, suggested value 1 601 Length: variable 602 SID/Label: if length is set to 3 then the 20 rightmost bits 603 represent a MPLS label. 605 2.4. SID/Label Binding TLV 607 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 608 domain. There are multiple uses of the SID/Label Binding TLV. 610 The SID/Label Binding TLV may be used to advertise prefixes to SID/ 611 Label mappings. This functionality is called the Segment Routing 612 Mapping Server (SRMS). The behavior of the SRMS is defined in 613 [I-D.ietf-spring-segment-routing-ldp-interop]. 615 The SID/Label Binding TLV may also be used to advertise a Mirror SID 616 to advertise the ability to process traffic originally destined to 617 another IGP node. This behavior is defined in [RFC8402]. 619 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 620 the following format: 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length | Flags | RESERVED | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Range | Prefix Length | Prefix | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 // Prefix (continued, variable) // 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | SubTLVs (variable) | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 1: SID/Label Binding TLV format 636 o Type: TBD, suggested value 149 638 o Length: variable. 640 o 1 octet of flags 642 o 1 octet of RESERVED 644 o 2 octets of Range 646 o 1 octet of Prefix Length 648 o 0-16 octets of Prefix 649 o sub-TLVs, where each sub-TLV consists of a sequence of: 651 * 1 octet of sub-TLV type 653 * 1 octet of length of the value field of the sub-TLV 655 * 0-243 octets of value 657 2.4.1. Flags 659 Flags: 1 octet field of following flags: 661 0 1 2 3 4 5 6 7 662 +-+-+-+-+-+-+-+-+ 663 |F|M|S|D|A| | 664 +-+-+-+-+-+-+-+-+ 666 where: 668 F-Flag: Address Family flag. If unset, then the Prefix carries an 669 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 671 M-Flag: Mirror Context flag. Set if the advertised SID 672 corresponds to a mirrored context. The use of the M flag is 673 described in [RFC8402]. 675 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 676 the entire routing domain. If the S flag is not set, the SID/ 677 Label Binding TLV MUST NOT be leaked between levels. This bit 678 MUST NOT be altered during the TLV leaking. 680 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 681 level-1, the D bit MUST be set. Otherwise, this bit MUST be 682 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 683 leaked from level-1 to level-2. This is to prevent TLV looping 684 across levels. 686 A-Flag: Attached flag. The originator of the SID/Label Binding 687 TLV MAY set the A bit in order to signal that the prefixes and 688 SIDs advertised in the SID/Label Binding TLV are directly 689 connected to their originators. The mechanisms through which the 690 originator of the SID/Label Binding TLV can figure out if a prefix 691 is attached or not are outside the scope of this document (e.g.: 692 through explicit configuration). If the Binding TLV is leaked to 693 other areas/levels the A-flag MUST be cleared. 695 An implementation MAY decide not to honor the S-flag in order not 696 to leak Binding TLV's between levels (for policy reasons). In all 697 cases, the D flag MUST always be set by any router leaking the 698 Binding TLV from level-2 into level-1 and MUST be checked when 699 propagating the Binding TLV from level-1 into level-2. If the D 700 flag is set, the Binding TLV MUST NOT be propagated into level-2. 702 Other bits: MUST be zero when originated and ignored when 703 received. 705 2.4.2. Range 707 The 'Range' field provides the ability to specify a range of 708 addresses and their associated Prefix SIDs. This advertisement 709 supports the SRMS functionality. It is essentially a compression 710 scheme to distribute a continuous Prefix and their continuous, 711 corresponding SID/Label Block. If a single SID is advertised then 712 the range field MUST be set to one. For range advertisements > 1, 713 the number of addresses that need to be mapped into a Prefix-SID and 714 the starting value of the Prefix-SID range. 716 Example 1: if the following router addresses (loopback addresses) 717 need to be mapped into the corresponding Prefix SID indexes. 719 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 720 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 721 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 722 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length |0|0| | RESERVED | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Range = 4 | /32 | 192 | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | .0 | .2 | .1 |Prefix-SID Type| 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | sub-TLV Length| Flags | Algorithm | | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | 1 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Example-2: If the following prefixes need to be mapped into the 739 corresponding Prefix-SID indexes: 741 10.1.1/24, Prefix-SID: Index 51 742 10.1.2/24, Prefix-SID: Index 52 743 10.1.3/24, Prefix-SID: Index 53 744 10.1.4/24, Prefix-SID: Index 54 745 10.1.5/24, Prefix-SID: Index 55 746 10.1.6/24, Prefix-SID: Index 56 747 10.1.7/24, Prefix-SID: Index 57 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length |0|0| | RESERVED | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Range = 7 | /24 | 10 | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Flags | Algorithm | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | 51 | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 It is not expected that a network operator will be able to keep fully 764 continuous Prefix / SID/Index mappings. In order to support 765 noncontinuous mapping ranges an implementation MAY generate several 766 instances of Binding TLVs. 768 For example if a router wants to advertise the following ranges: 770 Range 16: { 192.0.2.1-15, Index 1-15 } 772 Range 6: { 192.0.2.22-27, Index 22-27 } 774 Range 41: { 192.0.2.44-84, Index 80-120 } 776 A router would need to advertise three instances of the Binding TLV. 778 2.4.3. Prefix Length, Prefix 780 The 'Prefix' represents the Forwarding equivalence class at the tail- 781 end of the advertised path. The 'Prefix' does not need to correspond 782 to a routable prefix of the originating node. 784 The 'Prefix Length' field contains the length of the prefix in bits. 785 Only the most significant octets of the Prefix are encoded. (i.e., 1 786 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 787 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 788 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 790 2.4.4. Mapping Server Prefix-SID 792 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 793 and contains the SID/index/label value associated with the prefix and 794 range. The Prefix-SID SubTLV MUST be present in the SID/Label 795 Binding TLV unless the M-flag is set in the Flags field of the parent 796 TLV. 798 A node receiving an SRMS entry for a prefix MUST check the existence 799 of such prefix in its link-state database prior to consider and use 800 the associated SID. 802 2.4.4.1. Prefix-SID Flags 804 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 805 MAY advertise a mapping with the N flag set when the prefix being 806 mapped is known in the link-state topology with a mask length of 32 807 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 808 mechanisms through which the operator defines that a prefix 809 represents a node are outside the scope of this document (typically 810 it will be through configuration). 812 The other flags defined in Section 2.1 are not used by the Mapping 813 Server and MUST be ignored at reception. 815 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 817 As the mapping server does not specify the originator of a prefix 818 advertisement it is not possible to determine PHP behavior solely 819 based on the Mapping Server Advertisement. However, if additional 820 information is available PHP behavior may safely be done. The 821 required information consists of: 823 o A prefix reachability advertisement for the prefix has been 824 received which includes the Extended Reachability Attribute Flags 825 sub-TLV ([RFC7794]). 827 o X and R flags are both set to 0 in the Extended Reachability 828 Attribute Flags sub-TLV. 830 In the absence of an Extended Reachability Attribute Flags sub-TLV 831 ([RFC7794]) the A flag in the binding TLV indicates that the 832 originator of a prefix reachability advertisement is directly 833 connected to the prefix and thus PHP MUST be done by the neighbors of 834 the router originating the prefix reachability advertisement. Note 835 that A-flag is only valid in the original area in which the Binding 836 TLV is advertised. 838 2.4.4.3. Prefix-SID Algorithm 840 The algorithm field contains the identifier of the algorithm the 841 router MUST use in order to compute reachability to the range of 842 prefixes. Use of the algorithm field is described in Section 2.1. 844 2.4.5. SID/Label Sub-TLV 846 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 847 SID/Label value as defined in Section 2.3. It MUST be present in the 848 SID/Label Binding TLV when the M-flag is set in the Flags field of 849 the parent TLV. 851 2.5. Multi-Topology SID/Label Binding TLV 853 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 854 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 855 has the same format as the SID/Label Binding TLV defined in 856 Section 2.4 with the difference consisting of a Multitopology 857 Identifier (MTID) as defined here below: 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Type | Length | MTID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Flags | RESERVED | Range | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Prefix Length | Prefix (variable) // 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | SubTLVs (variable) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 2: Multi-Topology SID/Label Binding TLV format 873 where: 875 Type: TBD, suggested value 150 877 Length: variable 879 MTID is the multitopology identifier defined as: 881 0 1 882 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | RESVD | MTID | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 RESVD: reserved bits. MUST be reset on transmission and 887 ignored on receive. 889 MTID: a 12-bit field containing the non-zero ID of the topology 890 being announced. The TLV MUST be ignored if the ID is zero. 891 This is to ensure the consistent view of the standard unicast 892 topology. 894 The other fields and SubTLVs are defined in Section 2.4. 896 3. Router Capabilities 898 This section defines sub-TLVs which are inserted into the IS-IS 899 Router Capability TLV-242 that is defined in [RFC7981]. 901 3.1. SR-Capabilities Sub-TLV 903 Segment Routing requires each router to advertise its SR data-plane 904 capability and the range of MPLS label values it uses for Segment 905 Routing in the case where global SIDs are allocated (i.e., global 906 indexes). Data-plane capabilities and label ranges are advertised 907 using the newly defined SR-Capabilities sub-TLV. 909 The Router Capability TLV specifies flags that control its 910 advertisement. The SR Capabilities sub-TLV MUST be propagated 911 throughout the level and MUST NOT be advertised across level 912 boundaries. Therefore Router Capability TLV distribution flags are 913 set accordingly, i.e., the S flag in the Router Capability TLV 914 ([RFC7981]) MUST be unset. 916 The SR Capabilities sub-TLV has following format: 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Type | Length | Flags | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Range | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 // SID/Label Sub-TLV (variable) // 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Type: TBD, suggested value 2 932 Length: variable. 934 Flags: 1 octet of flags. The following are defined: 936 0 1 2 3 4 5 6 7 937 +-+-+-+-+-+-+-+-+ 938 |I|V| | 939 +-+-+-+-+-+-+-+-+ 941 where: 943 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 944 processing SR MPLS encapsulated IPv4 packets on all interfaces. 946 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 947 processing SR MPLS encapsulated IPv6 packets on all interfaces. 949 One or more SRGB Descriptor entries, each of which have the 950 following format: 952 Range: 3 octets. 954 SID/Label sub-TLV (as defined in Section 2.3). 956 SID/Label sub-TLV contains the first value of the SRGB while the 957 range contains the number of SRGB elements. The range value MUST be 958 higher than 0. 960 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 961 but a router MUST NOT advertise more than one SR-Capabilities sub- 962 TLV. A router receiving multiple SR-Capabilities sub-TLVs from the 963 same originator SHOULD select the first advertisement in the lowest 964 numbered LSP. 966 When multiple SRGB Descriptors are advertised the entries define an 967 ordered set of ranges on which a SID index is to be applied. For 968 this reason changing the order in which the descriptors are 969 advertised will have a disruptive effect on forwarding. 971 When a router adds a new SRGB Descriptor to an existing SR- 972 Capabilities sub-TLV the new Descriptor SHOULD add the newly 973 configured block at the end of the sub-TLV and SHOULD NOT change the 974 order of previously advertised blocks. Changing the order of the 975 advertised descriptors will create label churn in the FIB and 976 blackhole / misdirect some traffic during the IGP convergence. In 977 particular, if a range which is not the last is extended it's 978 preferable to add a new range rather than extending the previously 979 advertised range. 981 The originating router MUST ensure the order is same after a graceful 982 restart (using checkpointing, non-volatile storage or any other 983 mechanism) in order to guarantee the same order before and after GR. 985 The originating router MUST NOT advertise overlapping ranges. 987 When a router receives multiple overlapping ranges, it MUST conform 988 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 990 Here follows an example of advertisement of multiple ranges: 992 The originating router advertises following ranges: 993 SR-Cap: range: 100, SID value: 100 994 SR-Cap: range: 100, SID value: 1000 995 SR-Cap: range: 100, SID value: 500 997 The receiving routers concatenate the ranges in the received 998 order and build the SRGB as follows: 1000 SRGB = [100, 199] 1001 [1000, 1099] 1002 [500, 599] 1004 The indexes span multiple ranges: 1006 index=0 means label 100 1007 ... 1008 index 99 means label 199 1009 index 100 means label 1000 1010 index 199 means label 1099 1011 ... 1012 index 200 means label 500 1013 ... 1015 3.2. SR-Algorithm Sub-TLV 1017 The router may use various algorithms when calculating reachability 1018 to other nodes or to prefixes attached to these nodes. Examples of 1019 these algorithms are metric based Shortest Path First (SPF), various 1020 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1021 suggested value 19) allows the router to advertise the algorithms 1022 that the router is currently using. Algorithm values are defined in 1023 the "IGP Algorithm Type" registry defined in 1024 [I-D.ietf-ospf-segment-routing-extensions]. The following values 1025 have been defined: 1027 0: Shortest Path First (SPF) algorithm based on link metric. This 1028 is the well-known shortest path algorithm as computed by the IS-IS 1029 Decision process. Consistent with the deployed practice for link- 1030 state protocols, algorithm 0 permits any node to overwrite the SPF 1031 path with a different path based on local policy. 1033 1: Strict Shortest Path First (SPF) algorithm based on link 1034 metric. The algorithm is identical to algorithm 0 but algorithm 1 1035 requires that all nodes along the path will honor the SPF routing 1036 decision. Local policy MUST NOT alter the forwarding decision 1037 computed by algorithm 1 at the node claiming to support algorithm 1038 1. 1040 The Router Capability TLV specifies flags that control its 1041 advertisement. The SR-Algorithm MUST be propagated throughout the 1042 level and MUST NOT be advertised across level boundaries. Therefore 1043 Router Capability TLV distribution flags are set accordingly, i.e., 1044 the S flag MUST be unset. 1046 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1047 time inside the Router Capability TLV. 1049 When the originating router does not advertise the SR-Algorithm sub- 1050 TLV, then all the Prefix-SIDs advertised by the router MUST have 1051 algorithm field set to 0. Any receiving router MUST assume SPF 1052 algorithm (i.e., Shortest Path First). 1054 When the originating router does advertise the SR-Algorithm sub-TLV, 1055 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1057 The SR-Algorithm sub-TLV has following format: 1059 0 1 2 3 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Type | Length | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 where: 1069 Type: TBD, suggested value 19 1071 Length: variable. 1073 Algorithm: 1 octet of algorithm Section 2.1 1075 3.3. SR Local Block Sub-TLV 1077 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1078 node has reserved for local SIDs. Local SIDs are used, e.g., for 1079 Adjacency-SIDs, and may also be allocated by other components than 1080 IS-IS protocol. As an example, an application or a controller may 1081 instruct the router to allocate a specific local SID. Therefore, in 1082 order for such applications or controllers to know what are the local 1083 SIDs available in the router, it is required that the router 1084 advertises its SRLB. 1086 The SRLB Sub-TLV is used for that purpose and has following format: 1088 0 1 2 3 1089 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Type | Length | Flags | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Range | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 // SID/Label Sub-TLV (variable) // 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Type: TBD, suggested value 22. 1102 Length: variable. 1104 Flags: 1 octet of flags. None are defined at this stage. 1106 One or more SRLB Descriptor entries, each of which have the 1107 following format: 1109 Range: 3 octets. 1111 SID/Label sub-TLV (as defined in Section 2.3). 1113 SID/Label sub-TLV contains the first value of the SRLB while the 1114 range contains the number of SRLB elements. The range value MUST be 1115 higher than 0. 1117 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1118 router MUST NOT advertise more than one SRLB sub-TLV. A router 1119 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1120 select the first advertisement in the lowest numbered LSP. 1122 The originating router MUST NOT advertise overlapping ranges. 1124 It is important to note that each time a SID from the SRLB is 1125 allocated, it SHOULD also be reported to all components (e.g.: 1126 controller or applications) in order for these components to have an 1127 up-to-date view of the current SRLB allocation and in order to avoid 1128 collision between allocation instructions. 1130 Within the context of IS-IS, the reporting of local SIDs is done 1131 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1132 reporting of allocated local SIDs may also be done through other 1133 means and protocols which mechanisms are outside the scope of this 1134 document. 1136 A router advertising the SRLB TLV may also have other label ranges, 1137 outside the SRLB, for its local allocation purposes which are NOT 1138 advertised in the SRLB. For example, it is possible that an 1139 Adjacency-SID is allocated using a local label not part of the SRLB. 1141 3.4. SRMS Preference Sub-TLV 1143 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1144 in order to associate a preference with SRMS advertisements from a 1145 particular source. 1147 The SRMS Preference sub-TLV has following format: 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Type | Length | Preference | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 Type: TBD, suggested value 24. 1157 Length: 1. 1159 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1161 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1162 but a router MUST NOT advertise more than one SRMS Preference sub- 1163 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1164 same originator, SHOULD select the first advertisement in the lowest 1165 numbered LSP. 1167 The use of the SRMS Preference during the SID selection process is 1168 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1170 4. Non backward compatible changes with prior versions of this document 1172 This section describes the changes that have been applied to this 1173 document that are not backward compatible with previous versions. 1175 4.1. Encoding of Multiple SRGBs 1177 Version -04 of this document introduced a change in Section 3.1 1178 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1179 and made the support of multiple SRGBs REQUIRED. 1181 The modified method consists of having a single SR-Cap Sub-TLV where 1182 all SRGBs are encoded. In previous versions (prior to version -04) 1183 of this document it was allowed to have multiple occurrences of the 1184 SR-Cap Sub-TLV. 1186 At the time of writing this document, no existing implementations are 1187 affected by the change since no implementations actually (i.e., at 1188 the time of updating this document) encode multiple SRGBs anyway. 1190 5. IANA Considerations 1192 This documents request allocation for the following TLVs and subTLVs. 1194 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1196 This document makes the following registrations in the "sub-TLVs for 1197 TLV 22, 23, 25, 141, 222 and 223" registry. 1199 Type: TBD (suggested value 31) 1201 Description: Adjacency Segment Identifier 1203 TLV 22: yes 1205 TLV 23: yes 1207 TLV 25: no 1209 TLV 141: yes 1211 TLV 222: yes 1213 TLV 223: yes 1215 Reference: This document (Section 2.2.1) 1216 Type: TBD (suggested value 32) 1218 Description: LAN Adjacency Segment Identifier 1220 TLV 22: yes 1222 TLV 23: yes 1224 TLV 25: no 1226 TLV 141: yes 1228 TLV 222: yes 1230 TLV 223: yes 1232 Reference: This document (Section 2.2.2) 1234 5.2. Sub TLVs for Type 135,235,236 and 237 1236 This document makes the following registrations in the "sub-TLVs for 1237 TLV 135,235,236 and 237" registry. 1239 Type: TBD (suggested value 3) 1241 Description: Prefix Segment Identifier 1243 TLV 135: yes 1245 TLV 235: yes 1247 TLV 236: yes 1249 TLV 237: yes 1251 Reference: This document (Section 2.1) 1253 5.3. Sub TLVs for Type 242 1255 This document makes the following registrations in the "sub-TLVs for 1256 TLV 242" registry. 1258 Type: TBD (suggested value 2) 1260 Description: Segment Routing Capability 1261 Reference: This document (Section 3.1) 1263 Type: TBD (suggested value 19) 1265 Description: Segment Routing Algorithm 1267 Reference: This document (Section 3.2) 1269 Type: TBD (suggested value 22) 1271 Description: Segment Routing Local Block (SRLB) 1273 Reference: This document (Section 3.3) 1275 Type: TBD (suggested value 24) 1277 Description: Segment Routing Mapping Server Preference (SRMS 1278 Preference) 1280 Reference: This document (Section 3.4) 1282 5.4. New TLV Codepoint and Sub-TLV registry 1284 This document registers the following TLV: 1286 Type: TBD (suggested value 149) 1288 name: Segment Identifier / Label Binding 1290 IIH: no 1292 LSP: yes 1294 SNP: no 1296 Purge: no 1298 Reference: This document (Section 2.4) 1300 Type: TBD (suggested value 150) 1302 name: Multi-Topology Segment Identifier / Label Binding 1303 IIH: no 1305 LSP: yes 1307 SNP: no 1309 Purge: no 1311 Reference: This document (Section 2.5) 1313 This document creates the following sub-TLV Registry: 1315 Registry: sub-TLVs for TLV 149 and 150 1317 Registration Procedure: Expert review 1319 Reference: This document (Section 2.4) 1321 Type: TBD, suggested value 1 1323 Description: SID/Label 1325 Reference: This document (Section 2.4.5) 1327 Type: TBD, suggested value 3 1329 Description: Prefix-SID 1331 Reference: This document (Section 2.1) 1333 6. Security Considerations 1335 With the use of the extensions defined in this document, IS-IS 1336 carries information which will be used to program the MPLS data plane 1337 [RFC3031]. In general, the same types of attacks that can be carried 1338 out on the IP/IPv6 control plane can be carried out on the MPLS 1339 control plane resulting in traffic being misrouted in the respective 1340 data planes. However, the latter may be more difficult to detect and 1341 isolate. Existing security extensions as described in [RFC5304] and 1342 [RFC5310] apply to these segment routing extensions. 1344 7. Acknowledgements 1346 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1347 Francois and Jesper Skrivers for their contribution to the content of 1348 this document. 1350 8. Contributors 1352 The following people gave a substantial contribution to the content 1353 of this document and should be considered as co-authors: 1355 Stephane Litkowski 1356 Orange 1357 FR 1359 Email: stephane.litkowski@orange.com 1361 Jeff Tantsura 1362 Apstra, Inc. 1364 Email: jefftant@gmail.com 1366 Peter Psenak 1367 Cisco Systems Inc. 1368 US 1370 Email: ppsenak@cisco.com 1372 Martin Horneffer 1373 Deutsche Telekom 1374 DE 1376 Email: Martin.Horneffer@telekom.de 1378 Wim Henderickx 1379 Nokia 1380 BE 1382 Email: wim.henderickx@nokia.com 1384 Edward Crabbe 1385 Oracle 1386 US 1388 Email: edward.crabbe@oracle.com 1390 Rob Shakir 1391 Google 1392 UK 1394 Email: robjs@google.com 1395 Igor Milojevic 1396 Individual 1397 RS 1399 Email: milojevicigor@gmail.com 1401 Saku Ytti 1402 TDC 1403 FI 1405 Email: saku@ytti.fi 1407 Steven Luong 1408 Cisco Systems Inc. 1409 US 1411 Email: sluong@cisco.com 1413 9. References 1415 9.1. Normative References 1417 [I-D.ietf-ospf-segment-routing-extensions] 1418 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1419 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1420 Extensions for Segment Routing", draft-ietf-ospf-segment- 1421 routing-extensions-27 (work in progress), December 2018. 1423 [I-D.ietf-spring-segment-routing-ldp-interop] 1424 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1425 S. Litkowski, "Segment Routing interworking with LDP", 1426 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1427 progress), September 2018. 1429 [I-D.ietf-spring-segment-routing-mpls] 1430 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1431 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1432 data plane", draft-ietf-spring-segment-routing-mpls-18 1433 (work in progress), December 2018. 1435 [ISO10589] 1436 International Organization for Standardization, 1437 "Intermediate system to Intermediate system intra-domain 1438 routeing information exchange protocol for use in 1439 conjunction with the protocol for providing the 1440 connectionless-mode Network Service (ISO 8473)", ISO/ 1441 IEC 10589:2002, Second Edition, Nov 2002. 1443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1444 Requirement Levels", BCP 14, RFC 2119, 1445 DOI 10.17487/RFC2119, March 1997, 1446 . 1448 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1449 Label Switching Architecture", RFC 3031, 1450 DOI 10.17487/RFC3031, January 2001, 1451 . 1453 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1454 Topology (MT) Routing in Intermediate System to 1455 Intermediate Systems (IS-ISs)", RFC 5120, 1456 DOI 10.17487/RFC5120, February 2008, 1457 . 1459 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1460 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1461 2008, . 1463 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1464 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1465 2008, . 1467 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1468 DOI 10.17487/RFC5308, October 2008, 1469 . 1471 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1472 and M. Fanto, "IS-IS Generic Cryptographic 1473 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1474 2009, . 1476 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1477 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1478 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1479 March 2016, . 1481 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1482 for Advertising Router Information", RFC 7981, 1483 DOI 10.17487/RFC7981, October 2016, 1484 . 1486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1488 May 2017, . 1490 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1491 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1492 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1493 July 2018, . 1495 9.2. Informative References 1497 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1498 Shand, "Simplified Extension of Link State PDU (LSP) Space 1499 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1500 . 1502 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1503 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1504 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1505 December 2008, . 1507 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1508 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1509 Packet Routing in Networking (SPRING) Problem Statement 1510 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1511 2016, . 1513 [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. 1514 Shakir, "Resiliency Use Cases in Source Packet Routing in 1515 Networking (SPRING) Networks", RFC 8355, 1516 DOI 10.17487/RFC8355, March 2018, 1517 . 1519 Authors' Addresses 1521 Stefano Previdi (editor) 1522 Huawei 1523 IT 1525 Email: stefano@previdi.net 1527 Les Ginsberg (editor) 1528 Cisco Systems, Inc. 1529 IT 1531 Email: ginsberg@cisco.com 1532 Clarence Filsfils 1533 Cisco Systems, Inc. 1534 Brussels 1535 BE 1537 Email: cfilsfil@cisco.com 1539 Ahmed Bashandy 1540 Individual 1542 Email: abashandy.ietf@gmail.com 1544 Hannes Gredler 1545 RtBrick Inc. 1547 Email: hannes@rtbrick.com 1549 Bruno Decraene 1550 Orange 1551 FR 1553 Email: bruno.decraene@orange.com