idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-20.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 (November 8, 2018) is 1995 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 1011 -- Looks like a reference, but probably isn't: '199' on line 1011 -- Looks like a reference, but probably isn't: '1000' on line 1012 -- Looks like a reference, but probably isn't: '1099' on line 1012 -- Looks like a reference, but probably isn't: '500' on line 1013 -- Looks like a reference, but probably isn't: '599' on line 1013 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-15 -- 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 (~~), 3 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: May 12, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 A. Bashandy 8 Individual 9 H. Gredler 10 RtBrick Inc. 11 B. Decraene 12 Orange 13 November 8, 2018 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-20 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 May 12, 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 . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . 23 89 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 90 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 27 95 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 27 96 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 28 97 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 98 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 29 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 101 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 104 9.2. Informative References . . . . . . . . . . . . . . . . . 34 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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 [I-D.ietf-spring-segment-routing]. This draft also defines an 126 advertisement for one type of 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 132 [I-D.ietf-spring-segment-routing]. 134 Segment Routing use cases are described in [RFC7855]. 136 2. Segment Routing Identifiers 138 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 139 defines different types of Segment Identifiers (SID). This document 140 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 141 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 143 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 145 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 146 (Prefix-SID sub-TLV). 148 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 149 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 150 be unique within a given IGP domain (when the L-flag is not set). 151 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 152 that determines the actual SID/label value inside the set of all 153 advertised SID/label ranges of a given router. A receiving router 154 uses the index to determine the actual SID/label value in order to 155 construct forwarding state to a particular destination router. 157 In many use-cases a 'stable transport' IP Address is overloaded as an 158 identifier of a given node. Because the IP Prefixes may be re- 159 advertised into other levels there may be some ambiguity (e.g. 160 Originating router vs. L1L2 router) for which node a particular IP 161 prefix serves as identifier. The Prefix-SID sub-TLV contains the 162 necessary flags to disambiguate IP Prefix to node mappings. 163 Furthermore if a given node has several 'stable transport' IP 164 addresses there are flags to differentiate those among other IP 165 Prefixes advertised from a given node. 167 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 168 and MAY be present in any of the following TLVs: 170 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 172 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 174 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 176 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 178 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 179 and Section 2.5 respectively. 181 When the IP Reachability TLV is propagated across level boundaries, 182 the Prefix-SID sub-TLV SHOULD be kept. 184 The Prefix-SID sub-TLV has the following format: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | Flags | Algorithm | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SID/Index/Label (variable) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 Type: TBD, suggested value 3 198 Length: variable. 200 Flags: 1 octet field of following flags: 202 0 1 2 3 4 5 6 7 203 +-+-+-+-+-+-+-+-+ 204 |R|N|P|E|V|L| | 205 +-+-+-+-+-+-+-+-+ 207 where: 209 R-Flag: Re-advertisement flag. If set, then the prefix to 210 which this Prefix-SID is attached, has been propagated by the 211 router either from another level (i.e., from level-1 to level-2 212 or the opposite) or from redistribution (e.g.: from another 213 protocol). 215 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 216 the router identified by the prefix. Typically, the N-Flag is 217 set on Prefix-SIDs attached to a router loopback address. The 218 N-Flag is set when the Prefix-SID is a Node-SID as described in 219 [I-D.ietf-spring-segment-routing]. 221 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 222 pop the Prefix-SID before delivering the packet to the node 223 that advertised the Prefix-SID. 225 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 226 the Prefix-SID originator MUST replace the Prefix-SID with a 227 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 228 IPv6) before forwarding the packet. 230 V-Flag: Value flag. If set, then the Prefix-SID carries a 231 value (instead of an index). By default the flag is UNSET. 233 L-Flag: Local Flag. If set, then the value/index carried by 234 the Prefix-SID has local significance. By default the flag is 235 UNSET. 237 Other bits: MUST be zero when originated and ignored when 238 received. 240 Algorithm: the router may use various algorithms when calculating 241 reachability to other nodes or to prefixes attached to these 242 nodes. Algorithms identifiers are defined in Section 3.2. 243 Examples of these algorithms are metric based Shortest Path First 244 (SPF), various sorts of Constrained SPF, etc. The algorithm field 245 of the Prefix-SID contains the identifier of the algorithm the 246 router has used in order to compute the reachability of the prefix 247 to which the Prefix-SID is associated. 249 At origination, the Prefix-SID algorithm field MUST be set to 0 or 250 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 252 A router receiving a Prefix-SID from a remote node and with an 253 algorithm value that such remote node has not advertised in the 254 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 255 TLV. 257 SID/Index/Label: according to the V and L flags, it contains 258 either: 260 * A 4 octet index defining the offset in the SID/Label space 261 advertised by this router using the encodings defined in 262 Section 3.1. In this case the V and L flags MUST be unset. 264 * A 3 octet local label where the 20 rightmost bits are used for 265 encoding the label value. In this case the V and L flags MUST 266 be set. 268 2.1.1. Flags 270 2.1.1.1. R and N Flags 272 The R-Flag MUST be set for prefixes that are not local to the router 273 and either: 275 advertised because of propagation (Level-1 into Level-2); 277 advertised because of leaking (Level-2 into Level-1); 279 advertised because of redistribution (e.g.: from another 280 protocol). 282 In the case where a Level-1-2 router has local interface addresses 283 configured in one level, it may also propagate these addresses into 284 the other level. In such case, the Level-1-2 router MUST NOT set the 285 R bit. The R-bit MUST be set only for prefixes that are not local to 286 the router and advertised by the router because of propagation and/or 287 leaking. 289 The N-Flag is used in order to define a Node-SID. A router MAY set 290 the N-Flag only if all of the following conditions are met: 292 The prefix to which the Prefix-SID is attached is local to the 293 router (i.e., the prefix is configured on one of the local 294 interfaces, e.g., a 'stable transport' loopback). 296 The prefix to which the Prefix-SID is attached MUST have a Prefix 297 length of either /32 (IPv4) or /128 (IPv6). 299 The router MUST ignore the N-Flag on a received Prefix-SID if the 300 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 302 [RFC7794] also defines the N and R flags and with the same semantics 303 of the equivalent flags defined in this document. There will be a 304 transition period where both sets of flags will be used and 305 eventually only the flags of the Prefix Attributes will remain. 306 During the transition period implementations supporting the N and R 307 flags defined in this document and the N and R flags defined in 308 [RFC7794] MUST advertise and parse all flags. In case the received 309 flags have different values, the value of the flags defined in 310 [RFC7794] prevails. 312 2.1.1.2. E and P Flags 314 When calculating the outgoing label for the prefix, the router MUST 315 take into account E and P flags advertised by the next-hop router, if 316 next-hop router advertised the SID for the prefix. This MUST be done 317 regardless of next-hop router contributing to the best path to the 318 prefix or not. 320 When propagating (either from Level-1 to Level-2 or vice versa) a 321 reachability advertisement originated by another IS-IS speaker, the 322 router MUST set the P-flag and MUST clear the E-flag of the related 323 Prefix-SIDs. 325 The following behavior is associated with the settings of the E and P 326 flags: 328 o If the P-flag is not set then any upstream neighbor of the Prefix- 329 SID originator MUST pop the Prefix-SID. This is equivalent to the 330 penultimate hop popping mechanism used in the MPLS dataplane which 331 improves performance of the ultimate hop. MPLS EXP bits of the 332 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 333 being removed). If the P-flag is unset the received E-flag is 334 ignored. 336 o If the P-flag is set then: 338 * If the E-flag is not set then any upstream neighbor of the 339 Prefix-SID originator MUST keep the Prefix-SID on top of the 340 stack. This is useful when, e.g., the originator of the 341 Prefix-SID must stitch the incoming packet into a continuing 342 MPLS LSP to the final destination. This could occur at an 343 inter-area border router (prefix propagation from one area to 344 another) or at an inter-domain border router (prefix 345 propagation from one domain to another). 347 * If the E-flag is set then any upstream neighbor of the Prefix- 348 SID originator MUST replace the PrefixSID with a Prefix-SID 349 having an Explicit-NULL value. This is useful, e.g., when the 350 originator of the Prefix-SID is the final destination for the 351 related prefix and the originator wishes to receive the packet 352 with the original EXP bits. 354 2.1.2. Prefix-SID Propagation 356 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 357 gets propagated across level boundaries. 359 The level-1-2 router that propagates the Prefix-SID sub-TLV between 360 levels MUST set the R-flag. 362 If the Prefix-SID contains a global index (L and V flags unset) and 363 it is propagated as such (with L and V flags unset), the value of the 364 index MUST be preserved when propagated between levels. 366 The level-1-2 router that propagates the Prefix-SID sub-TLV between 367 levels MAY change the setting of the L and V flags in case a local 368 label value is encoded in the Prefix-SID instead of the received 369 value. 371 2.2. Adjacency Segment Identifier 373 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 374 TLV (Adj-SID sub-TLV). 376 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 377 Routing IGP-Adjacency-SID as defined in 379 [I-D.ietf-spring-segment-routing] with flags and fields that may be 380 used, in future extensions of Segment Routing, for carrying other 381 types of SIDs. 383 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 384 below: 386 TLV-22 (Extended IS reachability)[RFC5305] 388 TLV-222 (Multitopology IS)[RFC5120] 390 TLV-23 (IS Neighbor Attribute)[RFC5311] 392 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 394 TLV-141 (inter-AS reachability information)[RFC5316] 396 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 397 neighbor. 399 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 401 The following format is defined for the Adj-SID sub-TLV: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | Flags | Weight | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | SID/Label/Index (variable) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 where: 413 Type: TBD, suggested value 31 415 Length: variable. 417 Flags: 1 octet field of following flags: 419 0 1 2 3 4 5 6 7 420 +-+-+-+-+-+-+-+-+ 421 |F|B|V|L|S|P| | 422 +-+-+-+-+-+-+-+-+ 424 where: 426 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 427 to an adjacency with outgoing IPv4 encapsulation. If set then 428 the Adj-SID refers to an adjacency with outgoing IPv6 429 encapsulation. 431 B-Flag: Backup flag. If set, the Adj-SID is eligible for 432 protection (e.g.: using IPFRR or MPLS-FRR) as described in 433 [RFC8355]. 435 V-Flag: Value flag. If set, then the Adj-SID carries a value. 436 By default the flag is SET. 438 L-Flag: Local Flag. If set, then the value/index carried by 439 the Adj-SID has local significance. By default the flag is 440 SET. 442 S-Flag. Set flag. When set, the S-Flag indicates that the 443 Adj-SID refers to a set of adjacencies (and therefore MAY be 444 assigned to other adjacencies as well). 446 P-Flag. Persistent flag. When set, the P-Flag indicates that 447 the Adj-SID is persistently allocated, i.e., the Adj-SID value 448 remains consistent across router restart and/or interface flap. 450 Other bits: MUST be zero when originated and ignored when 451 received. 453 Weight: 1 octet. The value represents the weight of the Adj-SID 454 for the purpose of load balancing. The use of the weight is 455 defined in [I-D.ietf-spring-segment-routing]. 457 SID/Index/Label: according to the V and L flags, it contains 458 either: 460 * A 3 octet local label where the 20 rightmost bits are used for 461 encoding the label value. In this case the V and L flags MUST 462 be set. 464 * A 4 octet index defining the offset in the SID/Label space 465 advertised by this router using the encodings defined in 466 Section 3.1. In this case V and L flags MUST be unset. 468 An SR capable router MAY allocate an Adj-SID for each of its 469 adjacencies and SHOULD set the B-Flag when the adjacency is 470 eligible for protection (IP or MPLS). 472 An SR capable router MAY allocate more than one Adj-SID to an 473 adjacency. 475 An SR capable router MAY allocate the same Adj-SID to different 476 adjacencies. 478 When the P-flag is not set, the Adj-SID MAY be persistent. When 479 the P-flag is set, the Adj-SID MUST be persistent. 481 Examples of use of the Adj-SID sub-TLV are described in 482 [I-D.ietf-spring-segment-routing]. 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 [I-D.ietf-spring-segment-routing]. 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 545 defined in [ISO10589]. 547 SID/Index/Label: according to the V and L flags, it contains 548 either: 550 * A 3 octet local label where the 20 rightmost bits are used for 551 encoding the label value. In this case the V and L flags MUST 552 be set. 554 * A 4 octet index defining the offset in the SID/Label space 555 advertised by this router using the encodings defined in 556 Section 3.1. In this case V and L flags MUST be unset. 558 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 559 MUST NOT appear in TLV 141. 561 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 562 the P-flag is set, the LAN-Adj-SID MUST be persistent. 564 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 565 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 566 advertisements of the adjacency to the DIS MUST be used and all 567 advertisements MUST have the same metric. 569 Each router within the level, by receiving the DIS PN LSP as well as 570 the non-PN LSP of each router in the LAN, is capable of 571 reconstructing the LAN topology as well as the set of Adj-SID each 572 router uses for each of its neighbors. 574 A label is encoded in 3 octets (in the 20 rightmost bits). 576 An index is encoded in 4 octets. 578 2.3. SID/Label Sub-TLV 580 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 581 defined in this document: 583 SR-Capabilities Sub-TLV (Section 3.1) 585 SR Local Block Sub-TLV (Section 3.3) 587 SID/Label Binding TLV (Section 2.4) 589 Multi-Topology SID/Label Binding TLV (Section 2.5) 591 Note that the code point used in all of the above cases is the SID/ 592 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 593 149 and 150" registry. 595 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 596 sub-TLV has the following format: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type | Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | SID/Label (variable) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 where: 608 Type: TBD, suggested value 1 610 Length: variable 612 SID/Label: if length is set to 3 then the 20 rightmost bits 613 represent a MPLS label. 615 2.4. SID/Label Binding TLV 617 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 618 domain. There are multiple uses of the SID/Label Binding TLV. 620 The SID/Label Binding TLV may be used to advertise prefixes to SID/ 621 Label mappings. This functionality is called the Segment Routing 622 Mapping Server (SRMS). The behavior of the SRMS is defined in 623 [I-D.ietf-spring-segment-routing-ldp-interop]. 625 The SID/Label BInding TLV may also be used to advertise a Mirror SID 626 to advertise the ability to process traffic originally destined to 627 another IGP node. This behavior is defined in 628 [I-D.ietf-spring-segment-routing]. 630 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 631 the following format: 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Type | Length | Flags | RESERVED | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Range | Prefix Length | Prefix | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 // Prefix (continued, variable) // 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | SubTLVs (variable) | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Figure 1: SID/Label Binding TLV format 647 o Type: TBD, suggested value 149 649 o Length: variable. 651 o 1 octet of flags 653 o 1 octet of RESERVED 655 o 2 octets of Range 657 o 1 octet of Prefix Length 659 o 0-16 octets of Prefix 661 o sub-TLVs, where each sub-TLV consists of a sequence of: 663 * 1 octet of sub-TLV type 665 * 1 octet of length of the value field of the sub-TLV 667 * 0-243 octets of value 669 2.4.1. Flags 671 Flags: 1 octet field of following flags: 673 0 1 2 3 4 5 6 7 674 +-+-+-+-+-+-+-+-+ 675 |F|M|S|D|A| | 676 +-+-+-+-+-+-+-+-+ 678 where: 680 F-Flag: Address Family flag. If unset, then the Prefix carries an 681 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 683 M-Flag: Mirror Context flag. Set if the advertised SID 684 corresponds to a mirrored context. The use of the M flag is 685 described in [I-D.ietf-spring-segment-routing]. 687 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 688 the entire routing domain. If the S flag is not set, the SID/ 689 Label Binding TLV MUST NOT be leaked between levels. This bit 690 MUST NOT be altered during the TLV leaking. 692 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 693 level-1, the D bit MUST be set. Otherwise, this bit MUST be 694 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 695 leaked from level-1 to level-2. This is to prevent TLV looping 696 across levels. 698 A-Flag: Attached flag. The originator of the SID/Label Binding 699 TLV MAY set the A bit in order to signal that the prefixes and 700 SIDs advertised in the SID/Label Binding TLV are directly 701 connected to their originators. The mechanisms through which the 702 originator of the SID/Label Binding TLV can figure out if a prefix 703 is attached or not are outside the scope of this document (e.g.: 704 through explicit configuration). If the Binding TLV is leaked to 705 other areas/levels the A-flag MUST be cleared. 707 An implementation MAY decide not to honor the S-flag in order not 708 to leak Binding TLV's between levels (for policy reasons). In all 709 cases, the D flag MUST always be set by any router leaking the 710 Binding TLV from level-2 into level-1 and MUST be checked when 711 propagating the Binding TLV from level-1 into level-2. If the D 712 flag is set, the Binding TLV MUST NOT be propagated into level-2. 714 Other bits: MUST be zero when originated and ignored when 715 received. 717 2.4.2. Range 719 The 'Range' field provides the ability to specify a range of 720 addresses and their associated Prefix SIDs. This advertisement 721 supports the SRMS functionality. It is essentially a compression 722 scheme to distribute a continuous Prefix and their continuous, 723 corresponding SID/Label Block. If a single SID is advertised then 724 the range field MUST be set to one. For range advertisements > 1, 725 the number of addresses that need to be mapped into a Prefix-SID and 726 the starting value of the Prefix-SID range. 728 Example 1: if the following router addresses (loopback addresses) 729 need to be mapped into the corresponding Prefix SID indexes. 731 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 732 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 733 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 734 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length |0|0| | RESERVED | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Range = 4 | /32 | 192 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | .0 | .2 | .1 |Prefix-SID Type| 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | sub-TLV Length| Flags | Algorithm | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | 1 | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Example-2: If the following prefixes need to be mapped into the 750 corresponding Prefix-SID indexes: 752 10.1.1/24, Prefix-SID: Index 51 753 10.1.2/24, Prefix-SID: Index 52 754 10.1.3/24, Prefix-SID: Index 53 755 10.1.4/24, Prefix-SID: Index 54 756 10.1.5/24, Prefix-SID: Index 55 757 10.1.6/24, Prefix-SID: Index 56 758 10.1.7/24, Prefix-SID: Index 57 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type | Length |0|0| | RESERVED | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Range = 7 | /24 | 10 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Flags | Algorithm | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | 51 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 It is not expected that a network operator will be able to keep fully 775 continuous Prefix / SID/Index mappings. In order to support 776 noncontinuous mapping ranges an implementation MAY generate several 777 instances of Binding TLVs. 779 For example if a router wants to advertise the following ranges: 781 Range 16: { 192.0.2.1-15, Index 1-15 } 782 Range 6: { 192.0.2.22-27, Index 22-27 } 784 Range 41: { 192.0.2.44-84, Index 80-120 } 786 A router would need to advertise three instances of the Binding TLV. 788 2.4.3. Prefix Length, Prefix 790 The 'Prefix' represents the Forwarding equivalence class at the tail- 791 end of the advertised path. The 'Prefix' does not need to correspond 792 to a routable prefix of the originating node. 794 The 'Prefix Length' field contains the length of the prefix in bits. 795 Only the most significant octets of the Prefix are encoded. (i.e., 1 796 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 797 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 798 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 800 2.4.4. Mapping Server Prefix-SID 802 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 803 and contains the SID/index/label value associated with the prefix and 804 range. The Prefix-SID SubTLV MUST be present in the SID/Label 805 Binding TLV unless the M-flag is set in the Flags field of the parent 806 TLV. 808 A node receiving a MS entry for a prefix MUST check the existence of 809 such prefix in its link-state database prior to consider and use the 810 associated SID. 812 2.4.4.1. Prefix-SID Flags 814 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 815 MAY advertise a mapping with the N flag set when the prefix being 816 mapped is known in the link-state topology with a mask length of 32 817 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 818 mechanisms through which the operator defines that a prefix 819 represents a node are outside the scope of this document (typically 820 it will be through configuration). 822 The other flags defined in Section 2.1 are not used by the Mapping 823 Server and MUST be ignored at reception. 825 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 827 As the mapping server does not specify the originator of a prefix 828 advertisement it is not possible to determine PHP behavior solely 829 based on the Mapping Server Advertisement. However, if additional 830 information is available PHP behavior may safely be done. The 831 required information consists of: 833 o A prefix reachability advertisement for the prefix has been 834 received which includes the Extended Reachability Attribute Flags 835 sub-TLV ([RFC7794]). 837 o X and R flags are both set to 0 in the Extended Reachability 838 Attribute Flags sub-TLV. 840 In the absence of an Extended Reachability Attribute Flags sub-TLV 841 ([RFC7794]) the A flag in the binding TLV indicates that the 842 originator of a prefix reachability advertisement is directly 843 connected to the prefix and thus PHP MUST be done by the neighbors of 844 the router originating the prefix reachability advertisement. Note 845 that A-flag is only valid in the original area in which the Binding 846 TLV is advertised. 848 2.4.4.3. Prefix-SID Algorithm 850 The algorithm field contains the identifier of the algorithm the 851 router MUST use in order to compute reachability to the range of 852 prefixes. Use of the algorithm field is described in Section 2.1. 854 2.4.5. SID/Label Sub-TLV 856 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 857 SID/Label value as defined in Section 2.3. It MUST be present in the 858 SID/Label Binding TLV when the M-flag is set in the Flags field of 859 the parent TLV. 861 2.5. Multi-Topology SID/Label Binding TLV 863 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 864 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 865 has the same format as the SID/Label Binding TLV defined in 866 Section 2.4 with the difference consisting of a Multitopology 867 Identifier (MTID) as defined here below: 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Type | Length | MTID | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Flags | RESERVED | Range | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Prefix Length | Prefix (variable) // 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | SubTLVs (variable) | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 2: Multi-Topology SID/Label Binding TLV format 883 where: 885 Type: TBD, suggested value 150 887 Length: variable 889 MTID is the multitopology identifier defined as: 891 0 1 892 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | RESVD | MTID | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 RESVD: reserved bits. MUST be reset on transmission and 898 ignored on receive. 900 MTID: a 12-bit field containing the non-zero ID of the topology 901 being announced. The TLV MUST be ignored if the ID is zero. 902 This is to ensure the consistent view of the standard unicast 903 topology. 905 The other fields and SubTLVs are defined in Section 2.4. 907 3. Router Capabilities 909 This section defines sub-TLVs which are inserted into the IS-IS 910 Router Capability TLV-242 that is defined in [RFC7981]. 912 3.1. SR-Capabilities Sub-TLV 914 Segment Routing requires each router to advertise its SR data-plane 915 capability and the range of MPLS label values it uses for Segment 916 Routing in the case where global SIDs are allocated (i.e., global 917 indexes). Data-plane capabilities and label ranges are advertised 918 using the newly defined SR-Capabilities sub-TLV. 920 The Router Capability TLV specifies flags that control its 921 advertisement. The SR Capabilities sub-TLV MUST be propagated 922 throughout the level and MUST NOT be advertised across level 923 boundaries. Therefore Router Capability TLV distribution flags are 924 set accordingly, i.e., the S flag in the Router Capability TLV 925 ([RFC7981]) MUST be unset. 927 The SR Capabilities sub-TLV has following format: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Type | Length | Flags | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Range | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 // SID/Label Sub-TLV (variable) // 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Type: TBD, suggested value 2 943 Length: variable. 945 Flags: 1 octet of flags. The following are defined: 947 0 1 2 3 4 5 6 7 948 +-+-+-+-+-+-+-+-+ 949 |I|V| | 950 +-+-+-+-+-+-+-+-+ 952 where: 954 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 955 processing SR MPLS encapsulated IPv4 packets on all interfaces. 957 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 958 processing SR MPLS encapsulated IPv6 packets on all interfaces. 960 One or more SRGB Descriptor entries, each of which have the 961 following format: 963 Range: 3 octets. 965 SID/Label sub-TLV (as defined in Section 2.3). 967 SID/Label sub-TLV contains the first value of the SRGB while the 968 range contains the number of SRGB elements. The range value MUST be 969 higher than 0. 971 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 972 but a router MUST NOT advertise more than one SR-Capabilities sub- 973 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 974 same originator, SHOULD select the first advertisement in the lowest 975 numbered LSP. 977 When multiple SRGB Descriptors are advertised the entries define an 978 ordered set of ranges on which a SID index is to be applied. For 979 this reason changing the order in which the descriptors are 980 advertised will have a disruptive effect on forwarding. 982 When a router adds a new SRGB Descriptor to an existing SR- 983 Capabilities sub-TLV the new Descriptor SHOULD add the newly 984 configured block at the end of the sub-TLV and SHOULD NOT change the 985 order of previously advertised blocks. Changing the order of the 986 advertised descriptors will create label churn in the FIB and 987 blackhole / misdirect some traffic during the IGP convergence. In 988 particular, if a range which is not the last is extended it's 989 preferable to add a new range rather than extending the previously 990 advertised range. 992 The originating router MUST ensure the order is same after a graceful 993 restart (using checkpointing, non-volatile storage or any other 994 mechanism) in order to guarantee the same order before and after GR. 996 The originating router MUST NOT advertise overlapping ranges. 998 When a router receives multiple overlapping ranges, it MUST conform 999 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 1001 Here follows an example of advertisement of multiple ranges: 1003 The originating router advertises following ranges: 1004 SR-Cap: range: 100, SID value: 100 1005 SR-Cap: range: 100, SID value: 1000 1006 SR-Cap: range: 100, SID value: 500 1008 The receiving routers concatenate the ranges in the received 1009 order and build the SRGB as follows: 1011 SRGB = [100, 199] 1012 [1000, 1099] 1013 [500, 599] 1015 The indexes span multiple ranges: 1017 index=0 means label 100 1018 ... 1019 index 99 means label 199 1020 index 100 means label 1000 1021 index 199 means label 1099 1022 ... 1023 index 200 means label 500 1024 ... 1026 3.2. SR-Algorithm Sub-TLV 1028 The router may use various algorithms when calculating reachability 1029 to other nodes or to prefixes attached to these nodes. Examples of 1030 these algorithms are metric based Shortest Path First (SPF), various 1031 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1032 suggested value 19) allows the router to advertise the algorithms 1033 that the router is currently using. Algorithm values are defined in 1034 the "IGP Algorithm Type" registry defined in 1035 [I-D.ietf-ospf-segment-routing-extensions]. The following values 1036 have been defined: 1038 0: Shortest Path First (SPF) algorithm based on link metric. This 1039 is the well-known shortest path algorithm as computed by the IS-IS 1040 Decision process. Consistent with the deployed practice for link- 1041 state protocols, algorithm 0 permits any node to overwrite the SPF 1042 path with a different path based on local policy. 1044 1: Strict Shortest Path First (SPF) algorithm based on link 1045 metric. The algorithm is identical to algorithm 0 but algorithm 1 1046 requires that all nodes along the path will honor the SPF routing 1047 decision. Local policy MUST NOT alter the forwarding decision 1048 computed by algorithm 1 at the node claiming to support algorithm 1049 1. 1051 The Router Capability TLV specifies flags that control its 1052 advertisement. The SR-Algorithm MUST be propagated throughout the 1053 level and MUST NOT be advertised across level boundaries. Therefore 1054 Router Capability TLV distribution flags are set accordingly, i.e., 1055 the S flag MUST be unset. 1057 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1058 time inside the Router Capability TLV. 1060 When the originating router does not advertise the SR-Algorithm sub- 1061 TLV, then all the Prefix-SIDs advertised by the router MUST have 1062 algorithm field set to 0. Any receiving router MUST assume SPF 1063 algorithm (i.e., Shortest Path First). 1065 When the originating router does advertise the SR-Algorithm sub-TLV, 1066 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1068 The SR-Algorithm sub-TLV has following format: 1070 0 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Type | Length | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 where: 1080 Type: TBD, suggested value 19 1082 Length: variable. 1084 Algorithm: 1 octet of algorithm Section 2.1 1086 3.3. SR Local Block Sub-TLV 1088 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1089 node has reserved for local SIDs. Local SIDs are used, e.g., for 1090 Adjacency-SIDs, and may also be allocated by other components than 1091 IS-IS protocol. As an example, an application or a controller may 1092 instruct the router to allocate a specific local SID. Therefore, in 1093 order for such applications or controllers to know what are the local 1094 SIDs available in the router, it is required that the router 1095 advertises its SRLB. 1097 The SRLB Sub-TLV is used for that purpose and has following format: 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Type | Length | Flags | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Range | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 // SID/Label Sub-TLV (variable) // 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 Type: TBD, suggested value 22. 1113 Length: variable. 1115 Flags: 1 octet of flags. None are defined at this stage. 1117 One or more SRLB Descriptor entries, each of which have the 1118 following format: 1120 Range: 3 octets. 1122 SID/Label sub-TLV (as defined in Section 2.3). 1124 SID/Label sub-TLV contains the first value of the SRLB while the 1125 range contains the number of SRLB elements. The range value MUST be 1126 higher than 0. 1128 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1129 router MUST NOT advertise more than one SRLB sub-TLV. A router 1130 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1131 select the first advertisement in the lowest numbered LSP. 1133 The originating router MUST NOT advertise overlapping ranges. 1135 It is important to note that each time a SID from the SRLB is 1136 allocated, it SHOULD also be reported to all components (e.g.: 1137 controller or applications) in order for these components to have an 1138 up-to-date view of the current SRLB allocation and in order to avoid 1139 collision between allocation instructions. 1141 Within the context of IS-IS, the reporting of local SIDs is done 1142 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1143 reporting of allocated local SIDs may also be done through other 1144 means and protocols which mechanisms are outside the scope of this 1145 document. 1147 A router advertising the SRLB TLV may also have other label ranges, 1148 outside the SRLB, for its local allocation purposes which are NOT 1149 advertised in the SRLB. For example, it is possible that an 1150 Adjacency-SID is allocated using a local label not part of the SRLB. 1152 3.4. SRMS Preference Sub-TLV 1154 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1155 in order to associate a preference with SRMS advertisements from a 1156 particular source. 1158 The SRMS Preference sub-TLV has following format: 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Type | Length | Preference | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Type: TBD, suggested value 24. 1168 Length: 1. 1170 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1172 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1173 but a router MUST NOT advertise more than one SRMS Preference sub- 1174 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1175 same originator, SHOULD select the first advertisement in the lowest 1176 numbered LSP. 1178 The use of the SRMS Preference during the SID selection process is 1179 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1181 4. Non backward compatible changes with prior versions of this document 1183 This section describes the changes that have been applied to this 1184 document that are not backward compatible with previous versions. 1186 4.1. Encoding of Multiple SRGBs 1188 Version -04 of this document introduced a change in Section 3.1 1189 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1190 and made the support of multiple SRGBs REQUIRED. 1192 The modified method consists of having a single SR-Cap Sub-TLV where 1193 all SRGBs are encoded. In previous versions (prior to version -04) 1194 of this document it was allowed to have multiple occurrences of the 1195 SR-Cap Sub-TLV. 1197 At the time of writing this document, no existing implementations are 1198 affected by the change since no implementations actually (i.e., at 1199 the time of updating this document) encode multiple SRGBs anyway. 1201 5. IANA Considerations 1203 This documents request allocation for the following TLVs and subTLVs. 1205 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1207 This document makes the following registrations in the "sub-TLVs for 1208 TLV 22, 23, 25, 141, 222 and 223" registry. 1210 Type: TBD (suggested value 31) 1212 Description: Adjacency Segment Identifier 1214 TLV 22: yes 1216 TLV 23: yes 1218 TLV 25: no 1220 TLV 141: yes 1222 TLV 222: yes 1224 TLV 223: yes 1226 Reference: This document (Section 2.2.1) 1228 Type: TBD (suggested value 32) 1230 Description: LAN Adjacency Segment Identifier 1232 TLV 22: yes 1234 TLV 23: yes 1236 TLV 25: no 1237 TLV 141: yes 1239 TLV 222: yes 1241 TLV 223: yes 1243 Reference: This document (Section 2.2.2) 1245 5.2. Sub TLVs for Type 135,235,236 and 237 1247 This document makes the following registrations in the "sub-TLVs for 1248 TLV 135,235,236 and 237" registry. 1250 Type: TBD (suggested value 3) 1252 Description: Prefix Segment Identifier 1254 TLV 135: yes 1256 TLV 235: yes 1258 TLV 236: yes 1260 TLV 237: yes 1262 Reference: This document (Section 2.1) 1264 5.3. Sub TLVs for Type 242 1266 This document makes the following registrations in the "sub-TLVs for 1267 TLV 242" registry. 1269 Type: TBD (suggested value 2) 1271 Description: Segment Routing Capability 1273 Reference: This document (Section 3.1) 1275 Type: TBD (suggested value 19) 1277 Description: Segment Routing Algorithm 1279 Reference: This document (Section 3.2) 1280 Type: TBD (suggested value 22) 1282 Description: Segment Routing Local Block (SRLB) 1284 Reference: This document (Section 3.3) 1286 Type: TBD (suggested value 24) 1288 Description: Segment Routing Mapping Server Preference (SRMS 1289 Preference) 1291 Reference: This document (Section 3.4) 1293 5.4. New TLV Codepoint and Sub-TLV registry 1295 This document registers the following TLV: 1297 Type: TBD (suggested value 149) 1299 name: Segment Identifier / Label Binding 1301 IIH: no 1303 LSP: yes 1305 SNP: no 1307 Purge: no 1309 Reference: This document (Section 2.4) 1311 Type: TBD (suggested value 150) 1313 name: Multi-Topology Segment Identifier / Label Binding 1315 IIH: no 1317 LSP: yes 1319 SNP: no 1321 Purge: no 1323 Reference: This document (Section 2.5) 1325 This document creates the following sub-TLV Registry: 1327 Registry: sub-TLVs for TLV 149 and 150 1329 Registration Procedure: Expert review 1331 Reference: This document (Section 2.4) 1333 Type: TBD, suggested value 1 1335 Description: SID/Label 1337 Reference: This document (Section 2.4.5) 1339 Type: TBD, suggested value 3 1341 Description: Prefix-SID 1343 Reference: This document (Section 2.1) 1345 6. Security Considerations 1347 With the use of the extensions defined in this document, IS-IS 1348 carries information which will be used to program the MPLS data plane 1349 [RFC3031]. In general, the same types of attacks that can be carried 1350 out on the IP/IPv6 control plane can be carried out on the MPLS 1351 control plane resulting in traffic being misrouted in the respective 1352 data planes. However, the latter may be more difficult to detect and 1353 isolate. Existing security extensions as described in [RFC5304] and 1354 [RFC5310] apply to these segment routing extensions. 1356 7. Acknowledgements 1358 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1359 Francois and Jesper Skrivers for their contribution to the content of 1360 this document. 1362 8. Contributors 1364 The following people gave a substantial contribution to the content 1365 of this document and should be considered as co-authors: 1367 Stephane Litkowski 1368 Orange 1369 FR 1371 Email: stephane.litkowski@orange.com 1372 Jeff Tantsura 1373 Apstra, Inc. 1375 Email: jefftant@gmail.com 1377 Peter Psenak 1378 Cisco Systems Inc. 1379 US 1381 Email: ppsenak@cisco.com 1383 Martin Horneffer 1384 Deutsche Telekom 1385 DE 1387 Email: Martin.Horneffer@telekom.de 1389 Wim Henderickx 1390 Nokia 1391 BE 1393 Email: wim.henderickx@nokia.com 1395 Edward Crabbe 1396 Oracle 1397 US 1399 Email: edward.crabbe@oracle.com 1401 Rob Shakir 1402 Google 1403 UK 1405 Email: robjs@google.com 1407 Igor Milojevic 1408 Individual 1409 RS 1411 Email: milojevicigor@gmail.com 1413 Saku Ytti 1414 TDC 1415 FI 1417 Email: saku@ytti.fi 1419 Steven Luong 1420 Cisco Systems Inc. 1421 US 1423 Email: sluong@cisco.com 1425 9. References 1427 9.1. Normative References 1429 [I-D.ietf-ospf-segment-routing-extensions] 1430 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1431 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1432 Extensions for Segment Routing", draft-ietf-ospf-segment- 1433 routing-extensions-25 (work in progress), April 2018. 1435 [I-D.ietf-spring-segment-routing] 1436 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1437 Litkowski, S., and R. Shakir, "Segment Routing 1438 Architecture", draft-ietf-spring-segment-routing-15 (work 1439 in progress), January 2018. 1441 [I-D.ietf-spring-segment-routing-ldp-interop] 1442 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1443 S. Litkowski, "Segment Routing interworking with LDP", 1444 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1445 progress), September 2018. 1447 [I-D.ietf-spring-segment-routing-mpls] 1448 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1449 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1450 data plane", draft-ietf-spring-segment-routing-mpls-15 1451 (work in progress), October 2018. 1453 [ISO10589] 1454 International Organization for Standardization, 1455 "Intermediate system to Intermediate system intra-domain 1456 routeing information exchange protocol for use in 1457 conjunction with the protocol for providing the 1458 connectionless-mode Network Service (ISO 8473)", ISO/ 1459 IEC 10589:2002, Second Edition, Nov 2002. 1461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1462 Requirement Levels", BCP 14, RFC 2119, 1463 DOI 10.17487/RFC2119, March 1997, 1464 . 1466 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1467 Label Switching Architecture", RFC 3031, 1468 DOI 10.17487/RFC3031, January 2001, 1469 . 1471 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1472 Topology (MT) Routing in Intermediate System to 1473 Intermediate Systems (IS-ISs)", RFC 5120, 1474 DOI 10.17487/RFC5120, February 2008, 1475 . 1477 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1478 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1479 2008, . 1481 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1482 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1483 2008, . 1485 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1486 DOI 10.17487/RFC5308, October 2008, 1487 . 1489 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1490 and M. Fanto, "IS-IS Generic Cryptographic 1491 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1492 2009, . 1494 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1495 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1496 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1497 March 2016, . 1499 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1500 for Advertising Router Information", RFC 7981, 1501 DOI 10.17487/RFC7981, October 2016, 1502 . 1504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1506 May 2017, . 1508 9.2. Informative References 1510 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1511 Shand, "Simplified Extension of Link State PDU (LSP) Space 1512 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1513 . 1515 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1516 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1517 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1518 December 2008, . 1520 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1521 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1522 Packet Routing in Networking (SPRING) Problem Statement 1523 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1524 2016, . 1526 [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. 1527 Shakir, "Resiliency Use Cases in Source Packet Routing in 1528 Networking (SPRING) Networks", RFC 8355, 1529 DOI 10.17487/RFC8355, March 2018, 1530 . 1532 Authors' Addresses 1534 Stefano Previdi (editor) 1535 Huawei 1536 IT 1538 Email: stefano@previdi.net 1540 Les Ginsberg (editor) 1541 Cisco Systems, Inc. 1542 IT 1544 Email: ginsberg@cisco.com 1546 Clarence Filsfils 1547 Cisco Systems, Inc. 1548 Brussels 1549 BE 1551 Email: cfilsfil@cisco.com 1552 Ahmed Bashandy 1553 Individual 1555 Email: abashandy.ietf@gmail.com 1557 Hannes Gredler 1558 RtBrick Inc. 1560 Email: hannes@rtbrick.com 1562 Bruno Decraene 1563 Orange 1564 FR 1566 Email: bruno.decraene@orange.com