idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-19.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 (July 19, 2018) is 2101 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 1014 -- Looks like a reference, but probably isn't: '199' on line 1014 -- Looks like a reference, but probably isn't: '1000' on line 1015 -- Looks like a reference, but probably isn't: '1099' on line 1015 -- Looks like a reference, but probably isn't: '500' on line 1016 -- Looks like a reference, but probably isn't: '599' on line 1016 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets S. Previdi, Ed. 3 Internet-Draft L. Ginsberg, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: January 20, 2019 Cisco Systems, Inc. 6 A. Bashandy 8 H. Gredler 9 RtBrick Inc. 10 S. Litkowski 11 B. Decraene 12 Orange 13 J. Tantsura 14 Nuage Networks 15 July 19, 2018 17 IS-IS Extensions for Segment Routing 18 draft-ietf-isis-segment-routing-extensions-19 20 Abstract 22 Segment Routing (SR) allows for a flexible definition of end-to-end 23 paths within IGP topologies by encoding paths as sequences of 24 topological sub-paths, called "segments". These segments are 25 advertised by the link-state routing protocols (IS-IS and OSPF). 27 This draft describes the necessary IS-IS extensions that need to be 28 introduced for Segment Routing operating on an MPLS data-plane. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 20, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 74 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 75 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 77 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 78 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 79 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 80 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 81 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 82 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 83 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 84 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 18 85 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 86 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 87 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 88 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 89 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 90 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 23 91 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 92 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 26 93 4. Non backward compatible changes with prior versions of this 94 document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 98 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 27 99 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 28 100 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 101 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 29 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 107 9.2. Informative References . . . . . . . . . . . . . . . . . 33 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 110 1. Introduction 112 Segment Routing (SR) allows for a flexible definition of end-to-end 113 paths within IGP topologies by encoding paths as sequences of 114 topological sub-paths, called "segments". These segments are 115 advertised by the link-state routing protocols (IS-IS and OSPF). 116 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 117 a node), as per the state of the IGP topology. Adjacency segments 118 represent a hop over a specific adjacency between two nodes in the 119 IGP. A prefix segment is typically a multi-hop path while an 120 adjacency segment, in most of the cases, is a one-hop path. SR's 121 control-plane can be applied to both IPv6 and MPLS data-planes, and 122 do not require any additional signaling (other than the regular IGP). 123 For example, when used in MPLS networks, SR paths do not require any 124 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 125 of LSPs established with RSVP or LDP. 127 There are additional segment types, e.g., Binding SID defined in 128 [I-D.ietf-spring-segment-routing]. This draft also defines an 129 advertisement for one type of BindingSID: the Mirror Context segment. 131 This draft describes the necessary IS-IS extensions that need to be 132 introduced for Segment Routing operating on an MPLS data-plane. 134 Segment Routing architecture is described in 135 [I-D.ietf-spring-segment-routing]. 137 Segment Routing use cases are described in [RFC7855]. 139 2. Segment Routing Identifiers 141 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 142 defines different types of Segment Identifiers (SID). This document 143 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 144 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 146 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 148 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 149 (Prefix-SID sub-TLV). 151 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 152 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 153 be unique within a given IGP domain (when the L-flag is not set). 154 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 155 that determines the actual SID/label value inside the set of all 156 advertised SID/label ranges of a given router. A receiving router 157 uses the index to determine the actual SID/label value in order to 158 construct forwarding state to a particular destination router. 160 In many use-cases a 'stable transport' IP Address is overloaded as an 161 identifier of a given node. Because the IP Prefixes may be re- 162 advertised into other levels there may be some ambiguity (e.g. 163 Originating router vs. L1L2 router) for which node a particular IP 164 prefix serves as identifier. The Prefix-SID sub-TLV contains the 165 necessary flags to disambiguate IP Prefix to node mappings. 166 Furthermore if a given node has several 'stable transport' IP 167 addresses there are flags to differentiate those among other IP 168 Prefixes advertised from a given node. 170 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 171 and MAY be present in any of the following TLVs: 173 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 175 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 177 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 179 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 181 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 182 and Section 2.5 respectively. 184 When the IP Reachability TLV is propagated across level boundaries, 185 the Prefix-SID sub-TLV SHOULD be kept. 187 The Prefix-SID sub-TLV has the following format: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | Flags | Algorithm | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | SID/Index/Label (variable) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 where: 199 Type: TBD, suggested value 3 201 Length: variable. 203 Flags: 1 octet field of following flags: 205 0 1 2 3 4 5 6 7 206 +-+-+-+-+-+-+-+-+ 207 |R|N|P|E|V|L| | 208 +-+-+-+-+-+-+-+-+ 210 where: 212 R-Flag: Re-advertisement flag. If set, then the prefix to 213 which this Prefix-SID is attached, has been propagated by the 214 router either from another level (i.e., from level-1 to level-2 215 or the opposite) or from redistribution (e.g.: from another 216 protocol). 218 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 219 the router identified by the prefix. Typically, the N-Flag is 220 set on Prefix-SIDs attached to a router loopback address. The 221 N-Flag is set when the Prefix-SID is a Node-SID as described in 222 [I-D.ietf-spring-segment-routing]. 224 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 225 pop the Prefix-SID before delivering the packet to the node 226 that advertised the Prefix-SID. 228 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 229 the Prefix-SID originator MUST replace the Prefix-SID with a 230 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 231 IPv6) before forwarding the packet. 233 V-Flag: Value flag. If set, then the Prefix-SID carries a 234 value (instead of an index). By default the flag is UNSET. 236 L-Flag: Local Flag. If set, then the value/index carried by 237 the Prefix-SID has local significance. By default the flag is 238 UNSET. 240 Other bits: MUST be zero when originated and ignored when 241 received. 243 Algorithm: the router may use various algorithms when calculating 244 reachability to other nodes or to prefixes attached to these 245 nodes. Algorithms identifiers are defined in Section 3.2. 246 Examples of these algorithms are metric based Shortest Path First 247 (SPF), various sorts of Constrained SPF, etc. The algorithm field 248 of the Prefix-SID contains the identifier of the algorithm the 249 router has used in order to compute the reachability of the prefix 250 to which the Prefix-SID is associated. 252 At origination, the Prefix-SID algorithm field MUST be set to 0 or 253 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 255 A router receiving a Prefix-SID from a remote node and with an 256 algorithm value that such remote node has not advertised in the 257 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 258 TLV. 260 SID/Index/Label: according to the V and L flags, it contains 261 either: 263 * A 4 octet index defining the offset in the SID/Label space 264 advertised by this router using the encodings defined in 265 Section 3.1. In this case the V and L flags MUST be unset. 267 * A 3 octet local label where the 20 rightmost bits are used for 268 encoding the label value. In this case the V and L flags MUST 269 be set. 271 2.1.1. Flags 273 2.1.1.1. R and N Flags 275 The R-Flag MUST be set for prefixes that are not local to the router 276 and either: 278 advertised because of propagation (Level-1 into Level-2); 280 advertised because of leaking (Level-2 into Level-1); 282 advertised because of redistribution (e.g.: from another 283 protocol). 285 In the case where a Level-1-2 router has local interface addresses 286 configured in one level, it may also propagate these addresses into 287 the other level. In such case, the Level-1-2 router MUST NOT set the 288 R bit. The R-bit MUST be set only for prefixes that are not local to 289 the router and advertised by the router because of propagation and/or 290 leaking. 292 The N-Flag is used in order to define a Node-SID. A router MAY set 293 the N-Flag only if all of the following conditions are met: 295 The prefix to which the Prefix-SID is attached is local to the 296 router (i.e., the prefix is configured on one of the local 297 interfaces, e.g., a 'stable transport' loopback). 299 The prefix to which the Prefix-SID is attached MUST have a Prefix 300 length of either /32 (IPv4) or /128 (IPv6). 302 The router MUST ignore the N-Flag on a received Prefix-SID if the 303 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 305 [RFC7794] also defines the N and R flags and with the same semantics 306 of the equivalent flags defined in this document. There will be a 307 transition period where both sets of flags will be used and 308 eventually only the flags of the Prefix Attributes will remain. 309 During the transition period implementations supporting the N and R 310 flags defined in this document and the N and R flags defined in 311 [RFC7794] MUST advertise and parse all flags. In case the received 312 flags have different values, the value of the flags defined in 313 [RFC7794] prevails. 315 2.1.1.2. E and P Flags 317 When calculating the outgoing label for the prefix, the router MUST 318 take into account E and P flags advertised by the next-hop router, if 319 next-hop router advertised the SID for the prefix. This MUST be done 320 regardless of next-hop router contributing to the best path to the 321 prefix or not. 323 When propagating (either from Level-1 to Level-2 or vice versa) a 324 reachability advertisement originated by another IS-IS speaker, the 325 router MUST set the P-flag and MUST clear the E-flag of the related 326 Prefix-SIDs. 328 The following behavior is associated with the settings of the E and P 329 flags: 331 o If the P-flag is not set then any upstream neighbor of the Prefix- 332 SID originator MUST pop the Prefix-SID. This is equivalent to the 333 penultimate hop popping mechanism used in the MPLS dataplane which 334 improves performance of the ultimate hop. MPLS EXP bits of the 335 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 336 being removed). If the P-flag is unset the received E-flag is 337 ignored. 339 o If the P-flag is set then: 341 * If the E-flag is not set then any upstream neighbor of the 342 Prefix-SID originator MUST keep the Prefix-SID on top of the 343 stack. This is useful when, e.g., the originator of the 344 Prefix-SID must stitch the incoming packet into a continuing 345 MPLS LSP to the final destination. This could occur at an 346 inter-area border router (prefix propagation from one area to 347 another) or at an inter-domain border router (prefix 348 propagation from one domain to another). 350 * If the E-flag is set then any upstream neighbor of the Prefix- 351 SID originator MUST replace the PrefixSID with a Prefix-SID 352 having an Explicit-NULL value. This is useful, e.g., when the 353 originator of the Prefix-SID is the final destination for the 354 related prefix and the originator wishes to receive the packet 355 with the original EXP bits. 357 2.1.2. Prefix-SID Propagation 359 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 360 gets propagated across level boundaries. 362 The level-1-2 router that propagates the Prefix-SID sub-TLV between 363 levels MUST set the R-flag. 365 If the Prefix-SID contains a global index (L and V flags unset) and 366 it is propagated as such (with L and V flags unset), the value of the 367 index MUST be preserved when propagated between levels. 369 The level-1-2 router that propagates the Prefix-SID sub-TLV between 370 levels MAY change the setting of the L and V flags in case a local 371 label value is encoded in the Prefix-SID instead of the received 372 value. 374 2.2. Adjacency Segment Identifier 376 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 377 TLV (Adj-SID sub-TLV). 379 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 380 Routing IGP-Adjacency-SID as defined in 382 [I-D.ietf-spring-segment-routing] with flags and fields that may be 383 used, in future extensions of Segment Routing, for carrying other 384 types of SIDs. 386 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 387 below: 389 TLV-22 (Extended IS reachability)[RFC5305] 391 TLV-222 (Multitopology IS)[RFC5120] 393 TLV-23 (IS Neighbor Attribute)[RFC5311] 395 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 397 TLV-141 (inter-AS reachability information)[RFC5316] 399 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 400 neighbor. 402 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 404 The following format is defined for the Adj-SID sub-TLV: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | Flags | Weight | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | SID/Label/Index (variable) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 where: 416 Type: TBD, suggested value 31 418 Length: variable. 420 Flags: 1 octet field of following flags: 422 0 1 2 3 4 5 6 7 423 +-+-+-+-+-+-+-+-+ 424 |F|B|V|L|S|P| | 425 +-+-+-+-+-+-+-+-+ 427 where: 429 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 430 to an adjacency with outgoing IPv4 encapsulation. If set then 431 the Adj-SID refers to an adjacency with outgoing IPv6 432 encapsulation. 434 B-Flag: Backup flag. If set, the Adj-SID is eligible for 435 protection (e.g.: using IPFRR or MPLS-FRR) as described in 436 [RFC8355]. 438 V-Flag: Value flag. If set, then the Adj-SID carries a value. 439 By default the flag is SET. 441 L-Flag: Local Flag. If set, then the value/index carried by 442 the Adj-SID has local significance. By default the flag is 443 SET. 445 S-Flag. Set flag. When set, the S-Flag indicates that the 446 Adj-SID refers to a set of adjacencies (and therefore MAY be 447 assigned to other adjacencies as well). 449 P-Flag. Persistent flag. When set, the P-Flag indicates that 450 the Adj-SID is persistently allocated, i.e., the Adj-SID value 451 remains consistent across router restart and/or interface flap. 453 Other bits: MUST be zero when originated and ignored when 454 received. 456 Weight: 1 octet. The value represents the weight of the Adj-SID 457 for the purpose of load balancing. The use of the weight is 458 defined in [I-D.ietf-spring-segment-routing]. 460 SID/Index/Label: according to the V and L flags, it contains 461 either: 463 * A 3 octet local label where the 20 rightmost bits are used for 464 encoding the label value. In this case the V and L flags MUST 465 be set. 467 * A 4 octet index defining the offset in the SID/Label space 468 advertised by this router using the encodings defined in 469 Section 3.1. In this case V and L flags MUST be unset. 471 An SR capable router MAY allocate an Adj-SID for each of its 472 adjacencies and SHOULD set the B-Flag when the adjacency is 473 eligible for protection (IP or MPLS). 475 An SR capable router MAY allocate more than one Adj-SID to an 476 adjacency. 478 An SR capable router MAY allocate the same Adj-SID to different 479 adjacencies. 481 When the P-flag is not set, the Adj-SID MAY be persistent. When 482 the P-flag is set, the Adj-SID MUST be persistent. 484 Examples of use of the Adj-SID sub-TLV are described in 485 [I-D.ietf-spring-segment-routing]. 487 The F-flag is used in order for the router to advertise the 488 outgoing encapsulation of the adjacency the Adj-SID is attached 489 to. 491 2.2.2. Adjacency Segment Identifiers in LANs 493 In LAN subnetworks, the Designated Intermediate System (DIS) is 494 elected and originates the Pseudonode-LSP (PN-LSP) including all 495 neighbors of the DIS. 497 When Segment Routing is used, each router in the LAN MAY advertise 498 the Adj-SID of each of its neighbors. Since, on LANs, each router 499 only advertises one adjacency to the DIS (and doesn't advertise any 500 other adjacency), each router advertises the set of Adj-SIDs (for 501 each of its neighbors) inside a newly defined sub-TLV part of the TLV 502 advertising the adjacency to the DIS (e.g.: TLV-22). 504 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 505 suggested value 32) containing the set of Adj-SIDs the router 506 assigned to each of its LAN neighbors. 508 The format of the LAN-Adj-SID sub-TLV is as follows: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | Flags | Weight | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | System-ID (6 octets) | 518 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | SID/Label/Index (variable) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 where: 528 Type: TBD, suggested value 32 530 Length: variable. 532 Flags: 1 octet field of following flags: 534 0 1 2 3 4 5 6 7 535 +-+-+-+-+-+-+-+-+ 536 |F|B|V|L|S|P| | 537 +-+-+-+-+-+-+-+-+ 539 where F, B, V, L, S and P flags are defined in Section 2.2.1. 540 Other bits: MUST be zero when originated and ignored when 541 received. 543 Weight: 1 octet. The value represents the weight of the Adj-SID 544 for the purpose of load balancing. The use of the weight is 545 defined in [I-D.ietf-spring-segment-routing]. 547 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 548 defined in [ISO10589]. 550 SID/Index/Label: according to the V and L flags, it contains 551 either: 553 * A 3 octet local label where the 20 rightmost bits are used for 554 encoding the label value. In this case the V and L flags MUST 555 be set. 557 * A 4 octet index defining the offset in the SID/Label space 558 advertised by this router using the encodings defined in 559 Section 3.1. In this case V and L flags MUST be unset. 561 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 562 MUST NOT appear in TLV 141. 564 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 565 the P-flag is set, the LAN-Adj-SID MUST be persistent. 567 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 568 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 569 advertisements of the adjacency to the DIS MUST be used and all 570 advertisements MUST have the same metric. 572 Each router within the level, by receiving the DIS PN LSP as well as 573 the non-PN LSP of each router in the LAN, is capable of 574 reconstructing the LAN topology as well as the set of Adj-SID each 575 router uses for each of its neighbors. 577 A label is encoded in 3 octets (in the 20 rightmost bits). 579 An index is encoded in 4 octets. 581 2.3. SID/Label Sub-TLV 583 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 584 defined in this document: 586 SR-Capabilities Sub-TLV (Section 3.1) 588 SR Local Block Sub-TLV (Section 3.3) 590 SID/Label Binding TLV (Section 2.4) 592 Multi-Topology SID/Label Binding TLV (Section 2.5) 594 Note that the code point used in all of the above cases is the SID/ 595 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 596 149 and 150" registry. 598 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 599 sub-TLV has the following format: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | SID/Label (variable) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 where: 611 Type: TBD, suggested value 1 613 Length: variable 615 SID/Label: if length is set to 3 then the 20 rightmost bits 616 represent a MPLS label. 618 2.4. SID/Label Binding TLV 620 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 621 domain. There are multiple uses of the SID/Label Binding TLV. 623 The SID/Label Binding TLV may be used to advertise prefixes to SID/ 624 Label mappings. This functionality is called the Segment Routing 625 Mapping Server (SRMS). The behavior of the SRMS is defined in 626 [I-D.ietf-spring-segment-routing-ldp-interop]. 628 The SID/Label BInding TLV may also be used to advertise a Mirror SID 629 to advertise the ability to process traffic originally destined to 630 another IGP node. This behavior is defined in 631 [I-D.ietf-spring-segment-routing]. 633 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 634 the following format: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length | Flags | RESERVED | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Range | Prefix Length | Prefix | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 // Prefix (continued, variable) // 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | SubTLVs (variable) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 1: SID/Label Binding TLV format 650 o Type: TBD, suggested value 149 652 o Length: variable. 654 o 1 octet of flags 656 o 1 octet of RESERVED 658 o 2 octets of Range 660 o 1 octet of Prefix Length 662 o 0-16 octets of Prefix 664 o sub-TLVs, where each sub-TLV consists of a sequence of: 666 * 1 octet of sub-TLV type 668 * 1 octet of length of the value field of the sub-TLV 670 * 0-243 octets of value 672 2.4.1. Flags 674 Flags: 1 octet field of following flags: 676 0 1 2 3 4 5 6 7 677 +-+-+-+-+-+-+-+-+ 678 |F|M|S|D|A| | 679 +-+-+-+-+-+-+-+-+ 681 where: 683 F-Flag: Address Family flag. If unset, then the Prefix carries an 684 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 686 M-Flag: Mirror Context flag. Set if the advertised SID 687 corresponds to a mirrored context. The use of the M flag is 688 described in [I-D.ietf-spring-segment-routing]. 690 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 691 the entire routing domain. If the S flag is not set, the SID/ 692 Label Binding TLV MUST NOT be leaked between levels. This bit 693 MUST NOT be altered during the TLV leaking. 695 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 696 level-1, the D bit MUST be set. Otherwise, this bit MUST be 697 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 698 leaked from level-1 to level-2. This is to prevent TLV looping 699 across levels. 701 A-Flag: Attached flag. The originator of the SID/Label Binding 702 TLV MAY set the A bit in order to signal that the prefixes and 703 SIDs advertised in the SID/Label Binding TLV are directly 704 connected to their originators. The mechanisms through which the 705 originator of the SID/Label Binding TLV can figure out if a prefix 706 is attached or not are outside the scope of this document (e.g.: 707 through explicit configuration). If the Binding TLV is leaked to 708 other areas/levels the A-flag MUST be cleared. 710 An implementation MAY decide not to honor the S-flag in order not 711 to leak Binding TLV's between levels (for policy reasons). In all 712 cases, the D flag MUST always be set by any router leaking the 713 Binding TLV from level-2 into level-1 and MUST be checked when 714 propagating the Binding TLV from level-1 into level-2. If the D 715 flag is set, the Binding TLV MUST NOT be propagated into level-2. 717 Other bits: MUST be zero when originated and ignored when 718 received. 720 2.4.2. Range 722 The 'Range' field provides the ability to specify a range of 723 addresses and their associated Prefix SIDs. This advertisement 724 supports the SRMS functionality. It is essentially a compression 725 scheme to distribute a continuous Prefix and their continuous, 726 corresponding SID/Label Block. If a single SID is advertised then 727 the range field MUST be set to one. For range advertisements > 1, 728 the number of addresses that need to be mapped into a Prefix-SID and 729 the starting value of the Prefix-SID range. 731 Example 1: if the following router addresses (loopback addresses) 732 need to be mapped into the corresponding Prefix SID indexes. 734 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 735 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 736 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 737 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type | Length |0|0| | RESERVED | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Range = 4 | /32 | 192 | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | .0 | .2 | .1 |Prefix-SID Type| 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | sub-TLV Length| Flags | Algorithm | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | 1 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Example-2: If the following prefixes need to be mapped into the 753 corresponding Prefix-SID indexes: 755 10.1.1/24, Prefix-SID: Index 51 756 10.1.2/24, Prefix-SID: Index 52 757 10.1.3/24, Prefix-SID: Index 53 758 10.1.4/24, Prefix-SID: Index 54 759 10.1.5/24, Prefix-SID: Index 55 760 10.1.6/24, Prefix-SID: Index 56 761 10.1.7/24, Prefix-SID: Index 57 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length |0|0| | RESERVED | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Range = 7 | /24 | 10 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Flags | Algorithm | | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | 51 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 It is not expected that a network operator will be able to keep fully 778 continuous Prefix / SID/Index mappings. In order to support 779 noncontinuous mapping ranges an implementation MAY generate several 780 instances of Binding TLVs. 782 For example if a router wants to advertise the following ranges: 784 Range 16: { 192.0.2.1-15, Index 1-15 } 785 Range 6: { 192.0.2.22-27, Index 22-27 } 787 Range 41: { 192.0.2.44-84, Index 80-120 } 789 A router would need to advertise three instances of the Binding TLV. 791 2.4.3. Prefix Length, Prefix 793 The 'Prefix' represents the Forwarding equivalence class at the tail- 794 end of the advertised path. The 'Prefix' does not need to correspond 795 to a routable prefix of the originating node. 797 The 'Prefix Length' field contains the length of the prefix in bits. 798 Only the most significant octets of the Prefix are encoded. (i.e., 1 799 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 800 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 801 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 803 2.4.4. Mapping Server Prefix-SID 805 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 806 and contains the SID/index/label value associated with the prefix and 807 range. The Prefix-SID SubTLV MUST be present in the SID/Label 808 Binding TLV unless the M-flag is set in the Flags field of the parent 809 TLV. 811 A node receiving a MS entry for a prefix MUST check the existence of 812 such prefix in its link-state database prior to consider and use the 813 associated SID. 815 2.4.4.1. Prefix-SID Flags 817 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 818 MAY advertise a mapping with the N flag set when the prefix being 819 mapped is known in the link-state topology with a mask length of 32 820 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 821 mechanisms through which the operator defines that a prefix 822 represents a node are outside the scope of this document (typically 823 it will be through configuration). 825 The other flags defined in Section 2.1 are not used by the Mapping 826 Server and MUST be ignored at reception. 828 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 830 As the mapping server does not specify the originator of a prefix 831 advertisement it is not possible to determine PHP behavior solely 832 based on the Mapping Server Advertisement. However, if additional 833 information is available PHP behavior may safely be done. The 834 required information consists of: 836 o A prefix reachability advertisement for the prefix has been 837 received which includes the Extended Reachability Attribute Flags 838 sub-TLV ([RFC7794]). 840 o X and R flags are both set to 0 in the Extended Reachability 841 Attribute Flags sub-TLV. 843 In the absence of an Extended Reachability Attribute Flags sub-TLV 844 ([RFC7794]) the A flag in the binding TLV indicates that the 845 originator of a prefix reachability advertisement is directly 846 connected to the prefix and thus PHP MUST be done by the neighbors of 847 the router originating the prefix reachability advertisement. Note 848 that A-flag is only valid in the original area in which the Binding 849 TLV is advertised. 851 2.4.4.3. Prefix-SID Algorithm 853 The algorithm field contains the identifier of the algorithm the 854 router MUST use in order to compute reachability to the range of 855 prefixes. Use of the algorithm field is described in Section 2.1. 857 2.4.5. SID/Label Sub-TLV 859 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 860 SID/Label value as defined in Section 2.3. It MUST be present in the 861 SID/Label Binding TLV when the M-flag is set in the Flags field of 862 the parent TLV. 864 2.5. Multi-Topology SID/Label Binding TLV 866 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 867 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 868 has the same format as the SID/Label Binding TLV defined in 869 Section 2.4 with the difference consisting of a Multitopology 870 Identifier (MTID) as defined here below: 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Type | Length | MTID | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Flags | RESERVED | Range | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Prefix Length | Prefix (variable) // 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | SubTLVs (variable) | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Figure 2: Multi-Topology SID/Label Binding TLV format 886 where: 888 Type: TBD, suggested value 150 890 Length: variable 892 MTID is the multitopology identifier defined as: 894 0 1 895 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | RESVD | MTID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 RESVD: reserved bits. MUST be reset on transmission and 901 ignored on receive. 903 MTID: a 12-bit field containing the non-zero ID of the topology 904 being announced. The TLV MUST be ignored if the ID is zero. 905 This is to ensure the consistent view of the standard unicast 906 topology. 908 The other fields and SubTLVs are defined in Section 2.4. 910 3. Router Capabilities 912 This section defines sub-TLVs which are inserted into the IS-IS 913 Router Capability TLV-242 that is defined in [RFC7981]. 915 3.1. SR-Capabilities Sub-TLV 917 Segment Routing requires each router to advertise its SR data-plane 918 capability and the range of MPLS label values it uses for Segment 919 Routing in the case where global SIDs are allocated (i.e., global 920 indexes). Data-plane capabilities and label ranges are advertised 921 using the newly defined SR-Capabilities sub-TLV. 923 The Router Capability TLV specifies flags that control its 924 advertisement. The SR Capabilities sub-TLV MUST be propagated 925 throughout the level and MUST NOT be advertised across level 926 boundaries. Therefore Router Capability TLV distribution flags are 927 set accordingly, i.e., the S flag in the Router Capability TLV 928 ([RFC7981]) MUST be unset. 930 The SR Capabilities sub-TLV has following format: 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Type | Length | Flags | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Range | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 // SID/Label Sub-TLV (variable) // 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Type: TBD, suggested value 2 946 Length: variable. 948 Flags: 1 octet of flags. The following are defined: 950 0 1 2 3 4 5 6 7 951 +-+-+-+-+-+-+-+-+ 952 |I|V| | 953 +-+-+-+-+-+-+-+-+ 955 where: 957 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 958 processing SR MPLS encapsulated IPv4 packets on all interfaces. 960 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 961 processing SR MPLS encapsulated IPv6 packets on all interfaces. 963 One or more SRGB Descriptor entries, each of which have the 964 following format: 966 Range: 3 octets. 968 SID/Label sub-TLV (as defined in Section 2.3). 970 SID/Label sub-TLV contains the first value of the SRGB while the 971 range contains the number of SRGB elements. The range value MUST be 972 higher than 0. 974 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 975 but a router MUST NOT advertise more than one SR-Capabilities sub- 976 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 977 same originator, SHOULD select the first advertisement in the lowest 978 numbered LSP. 980 When multiple SRGB Descriptors are advertised the entries define an 981 ordered set of ranges on which a SID index is to be applied. For 982 this reason changing the order in which the descriptors are 983 advertised will have a disruptive effect on forwarding. 985 When a router adds a new SRGB Descriptor to an existing SR- 986 Capabilities sub-TLV the new Descriptor SHOULD add the newly 987 configured block at the end of the sub-TLV and SHOULD NOT change the 988 order of previously advertised blocks. Changing the order of the 989 advertised descriptors will create label churn in the FIB and 990 blackhole / misdirect some traffic during the IGP convergence. In 991 particular, if a range which is not the last is extended it's 992 preferable to add a new range rather than extending the previously 993 advertised range. 995 The originating router MUST ensure the order is same after a graceful 996 restart (using checkpointing, non-volatile storage or any other 997 mechanism) in order to guarantee the same order before and after GR. 999 The originating router MUST NOT advertise overlapping ranges. 1001 When a router receives multiple overlapping ranges, it MUST conform 1002 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 1004 Here follows an example of advertisement of multiple ranges: 1006 The originating router advertises following ranges: 1007 SR-Cap: range: 100, SID value: 100 1008 SR-Cap: range: 100, SID value: 1000 1009 SR-Cap: range: 100, SID value: 500 1011 The receiving routers concatenate the ranges in the received 1012 order and build the SRGB as follows: 1014 SRGB = [100, 199] 1015 [1000, 1099] 1016 [500, 599] 1018 The indexes span multiple ranges: 1020 index=0 means label 100 1021 ... 1022 index 99 means label 199 1023 index 100 means label 1000 1024 index 199 means label 1099 1025 ... 1026 index 200 means label 500 1027 ... 1029 3.2. SR-Algorithm Sub-TLV 1031 The router may use various algorithms when calculating reachability 1032 to other nodes or to prefixes attached to these nodes. Examples of 1033 these algorithms are metric based Shortest Path First (SPF), various 1034 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1035 suggested value 19) allows the router to advertise the algorithms 1036 that the router is currently using. Algorithm values are defined in 1037 the "IGP Algorithm Type" registry defined in 1038 [I-D.ietf-ospf-segment-routing-extensions]. The following values 1039 have been defined: 1041 0: Shortest Path First (SPF) algorithm based on link metric. This 1042 is the well-known shortest path algorithm as computed by the IS-IS 1043 Decision process. Consistent with the deployed practice for link- 1044 state protocols, algorithm 0 permits any node to overwrite the SPF 1045 path with a different path based on local policy. 1047 1: Strict Shortest Path First (SPF) algorithm based on link 1048 metric. The algorithm is identical to algorithm 0 but algorithm 1 1049 requires that all nodes along the path will honor the SPF routing 1050 decision. Local policy MUST NOT alter the forwarding decision 1051 computed by algorithm 1 at the node claiming to support algorithm 1052 1. 1054 The Router Capability TLV specifies flags that control its 1055 advertisement. The SR-Algorithm MUST be propagated throughout the 1056 level and MUST NOT be advertised across level boundaries. Therefore 1057 Router Capability TLV distribution flags are set accordingly, i.e., 1058 the S flag MUST be unset. 1060 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1061 time inside the Router Capability TLV. 1063 When the originating router does not advertise the SR-Algorithm sub- 1064 TLV, then all the Prefix-SIDs advertised by the router MUST have 1065 algorithm field set to 0. Any receiving router MUST assume SPF 1066 algorithm (i.e., Shortest Path First). 1068 When the originating router does advertise the SR-Algorithm sub-TLV, 1069 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1071 The SR-Algorithm sub-TLV has following format: 1073 0 1 2 3 1074 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Type | Length | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 where: 1083 Type: TBD, suggested value 19 1085 Length: variable. 1087 Algorithm: 1 octet of algorithm Section 2.1 1089 3.3. SR Local Block Sub-TLV 1091 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1092 node has reserved for local SIDs. Local SIDs are used, e.g., for 1093 Adjacency-SIDs, and may also be allocated by other components than 1094 IS-IS protocol. As an example, an application or a controller may 1095 instruct the router to allocate a specific local SID. Therefore, in 1096 order for such applications or controllers to know what are the local 1097 SIDs available in the router, it is required that the router 1098 advertises its SRLB. 1100 The SRLB Sub-TLV is used for that purpose and has following format: 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Type | Length | Flags | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Range | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 // SID/Label Sub-TLV (variable) // 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 Type: TBD, suggested value 22. 1116 Length: variable. 1118 Flags: 1 octet of flags. None are defined at this stage. 1120 One or more SRLB Descriptor entries, each of which have the 1121 following format: 1123 Range: 3 octets. 1125 SID/Label sub-TLV (as defined in Section 2.3). 1127 SID/Label sub-TLV contains the first value of the SRLB while the 1128 range contains the number of SRLB elements. The range value MUST be 1129 higher than 0. 1131 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1132 router MUST NOT advertise more than one SRLB sub-TLV. A router 1133 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1134 select the first advertisement in the lowest numbered LSP. 1136 The originating router MUST NOT advertise overlapping ranges. 1138 It is important to note that each time a SID from the SRLB is 1139 allocated, it SHOULD also be reported to all components (e.g.: 1140 controller or applications) in order for these components to have an 1141 up-to-date view of the current SRLB allocation and in order to avoid 1142 collision between allocation instructions. 1144 Within the context of IS-IS, the reporting of local SIDs is done 1145 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1146 reporting of allocated local SIDs may also be done through other 1147 means and protocols which mechanisms are outside the scope of this 1148 document. 1150 A router advertising the SRLB TLV may also have other label ranges, 1151 outside the SRLB, for its local allocation purposes which are NOT 1152 advertised in the SRLB. For example, it is possible that an 1153 Adjacency-SID is allocated using a local label not part of the SRLB. 1155 3.4. SRMS Preference Sub-TLV 1157 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1158 in order to associate a preference with SRMS advertisements from a 1159 particular source. 1161 The SRMS Preference sub-TLV has following format: 1163 0 1 2 3 1164 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 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Type | Length | Preference | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Type: TBD, suggested value 24. 1171 Length: 1. 1173 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1175 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1176 but a router MUST NOT advertise more than one SRMS Preference sub- 1177 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1178 same originator, SHOULD select the first advertisement in the lowest 1179 numbered LSP. 1181 The use of the SRMS Preference during the SID selection process is 1182 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1184 4. Non backward compatible changes with prior versions of this document 1186 This section describes the changes that have been applied to this 1187 document that are not backward compatible with previous versions. 1189 4.1. Encoding of Multiple SRGBs 1191 Version -04 of this document introduced a change in Section 3.1 1192 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1193 and made the support of multiple SRGBs REQUIRED. 1195 The modified method consists of having a single SR-Cap Sub-TLV where 1196 all SRGBs are encoded. In previous versions (prior to version -04) 1197 of this document it was allowed to have multiple occurrences of the 1198 SR-Cap Sub-TLV. 1200 At the time of writing this document, no existing implementations are 1201 affected by the change since no implementations actually (i.e., at 1202 the time of updating this document) encode multiple SRGBs anyway. 1204 5. IANA Considerations 1206 This documents request allocation for the following TLVs and subTLVs. 1208 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1210 This document makes the following registrations in the "sub-TLVs for 1211 TLV 22, 23, 25, 141, 222 and 223" registry. 1213 Type: TBD (suggested value 31) 1215 Description: Adjacency Segment Identifier 1217 TLV 22: yes 1219 TLV 23: yes 1221 TLV 25: no 1223 TLV 141: yes 1225 TLV 222: yes 1227 TLV 223: yes 1229 Reference: This document (Section 2.2.1) 1231 Type: TBD (suggested value 32) 1233 Description: LAN Adjacency Segment Identifier 1235 TLV 22: yes 1237 TLV 23: yes 1239 TLV 25: no 1240 TLV 141: yes 1242 TLV 222: yes 1244 TLV 223: yes 1246 Reference: This document (Section 2.2.2) 1248 5.2. Sub TLVs for Type 135,235,236 and 237 1250 This document makes the following registrations in the "sub-TLVs for 1251 TLV 135,235,236 and 237" registry. 1253 Type: TBD (suggested value 3) 1255 Description: Prefix Segment Identifier 1257 TLV 135: yes 1259 TLV 235: yes 1261 TLV 236: yes 1263 TLV 237: yes 1265 Reference: This document (Section 2.1) 1267 5.3. Sub TLVs for Type 242 1269 This document makes the following registrations in the "sub-TLVs for 1270 TLV 242" registry. 1272 Type: TBD (suggested value 2) 1274 Description: Segment Routing Capability 1276 Reference: This document (Section 3.1) 1278 Type: TBD (suggested value 19) 1280 Description: Segment Routing Algorithm 1282 Reference: This document (Section 3.2) 1283 Type: TBD (suggested value 22) 1285 Description: Segment Routing Local Block (SRLB) 1287 Reference: This document (Section 3.3) 1289 Type: TBD (suggested value 24) 1291 Description: Segment Routing Mapping Server Preference (SRMS 1292 Preference) 1294 Reference: This document (Section 3.4) 1296 5.4. New TLV Codepoint and Sub-TLV registry 1298 This document registers the following TLV: 1300 Type: TBD (suggested value 149) 1302 name: Segment Identifier / Label Binding 1304 IIH: no 1306 LSP: yes 1308 SNP: no 1310 Purge: no 1312 Reference: This document (Section 2.4) 1314 Type: TBD (suggested value 150) 1316 name: Multi-Topology Segment Identifier / Label Binding 1318 IIH: no 1320 LSP: yes 1322 SNP: no 1324 Purge: no 1326 Reference: This document (Section 2.5) 1328 This document creates the following sub-TLV Registry: 1330 Registry: sub-TLVs for TLV 149 and 150 1332 Registration Procedure: Expert review 1334 Reference: This document (Section 2.4) 1336 Type: TBD, suggested value 1 1338 Description: SID/Label 1340 Reference: This document (Section 2.4.5) 1342 Type: TBD, suggested value 3 1344 Description: Prefix-SID 1346 Reference: This document (Section 2.1) 1348 6. Security Considerations 1350 With the use of the extensions defined in this document, IS-IS 1351 carries information which will be used to program the MPLS data plane 1352 [RFC3031]. In general, the same types of attacks that can be carried 1353 out on the IP/IPv6 control plane can be carried out on the MPLS 1354 control plane resulting in traffic being misrouted in the respective 1355 data planes. However, the latter may be more difficult to detect and 1356 isolate. Existing security extensions as described in [RFC5304] and 1357 [RFC5310] apply to these segment routing extensions. 1359 7. Acknowledgements 1361 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1362 Francois and Jesper Skrivers for their contribution to the content of 1363 this document. 1365 8. Contributors 1367 The following people gave a substantial contribution to the content 1368 of this document and should be considered as co-authors: 1370 Peter Psenak 1371 Cisco Systems Inc. 1372 US 1374 Email: ppsenak@cisco.com 1375 Martin Horneffer 1376 Deutsche Telekom 1377 DE 1379 Email: Martin.Horneffer@telekom.de 1381 Wim Henderickx 1382 Nokia 1383 BE 1385 Email: wim.henderickx@nokia.com 1387 Edward Crabbe 1388 Oracle 1389 US 1391 Email: edward.crabbe@oracle.com 1393 Rob Shakir 1394 Google 1395 UK 1397 Email: robjs@google.com 1399 Igor Milojevic 1400 Individual 1401 RS 1403 Email: milojevicigor@gmail.com 1405 Saku Ytti 1406 TDC 1407 FI 1409 Email: saku@ytti.fi 1411 Steven Luong 1412 Cisco Systems Inc. 1413 US 1415 Email: sluong@cisco.com 1417 9. References 1419 9.1. Normative References 1421 [I-D.ietf-ospf-segment-routing-extensions] 1422 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1423 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1424 Extensions for Segment Routing", draft-ietf-ospf-segment- 1425 routing-extensions-25 (work in progress), April 2018. 1427 [I-D.ietf-spring-segment-routing] 1428 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1429 Litkowski, S., and R. Shakir, "Segment Routing 1430 Architecture", draft-ietf-spring-segment-routing-15 (work 1431 in progress), January 2018. 1433 [I-D.ietf-spring-segment-routing-ldp-interop] 1434 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1435 S. Litkowski, "Segment Routing interworking with LDP", 1436 draft-ietf-spring-segment-routing-ldp-interop-14 (work in 1437 progress), July 2018. 1439 [I-D.ietf-spring-segment-routing-mpls] 1440 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1441 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1442 data plane", draft-ietf-spring-segment-routing-mpls-14 1443 (work in progress), June 2018. 1445 [ISO10589] 1446 International Organization for Standardization, 1447 "Intermediate system to Intermediate system intra-domain 1448 routeing information exchange protocol for use in 1449 conjunction with the protocol for providing the 1450 connectionless-mode Network Service (ISO 8473)", ISO/ 1451 IEC 10589:2002, Second Edition, Nov 2002. 1453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1454 Requirement Levels", BCP 14, RFC 2119, 1455 DOI 10.17487/RFC2119, March 1997, 1456 . 1458 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1459 Label Switching Architecture", RFC 3031, 1460 DOI 10.17487/RFC3031, January 2001, 1461 . 1463 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1464 Topology (MT) Routing in Intermediate System to 1465 Intermediate Systems (IS-ISs)", RFC 5120, 1466 DOI 10.17487/RFC5120, February 2008, 1467 . 1469 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1470 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1471 2008, . 1473 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1474 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1475 2008, . 1477 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1478 DOI 10.17487/RFC5308, October 2008, 1479 . 1481 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1482 and M. Fanto, "IS-IS Generic Cryptographic 1483 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1484 2009, . 1486 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1487 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1488 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1489 March 2016, . 1491 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1492 for Advertising Router Information", RFC 7981, 1493 DOI 10.17487/RFC7981, October 2016, 1494 . 1496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1498 May 2017, . 1500 9.2. Informative References 1502 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1503 Shand, "Simplified Extension of Link State PDU (LSP) Space 1504 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1505 . 1507 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1508 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1509 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1510 December 2008, . 1512 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1513 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1514 Packet Routing in Networking (SPRING) Problem Statement 1515 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1516 2016, . 1518 [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. 1519 Shakir, "Resiliency Use Cases in Source Packet Routing in 1520 Networking (SPRING) Networks", RFC 8355, 1521 DOI 10.17487/RFC8355, March 2018, 1522 . 1524 Authors' Addresses 1526 Stefano Previdi (editor) 1527 Cisco Systems, Inc. 1528 IT 1530 Email: stefano@previdi.net 1532 Les Ginsberg (editor) 1533 Cisco Systems, Inc. 1534 IT 1536 Email: ginsberg@cisco.com 1538 Clarence Filsfils 1539 Cisco Systems, Inc. 1540 Brussels 1541 BE 1543 Email: cfilsfil@cisco.com 1545 Ahmed Bashandy 1547 Email: abashandy.ietf@gmail.com 1549 Hannes Gredler 1550 RtBrick Inc. 1552 Email: hannes@rtbrick.com 1553 Stephane Litkowski 1554 Orange 1555 FR 1557 Email: stephane.litkowski@orange.com 1559 Bruno Decraene 1560 Orange 1561 FR 1563 Email: bruno.decraene@orange.com 1565 Jeff Tantsura 1566 Nuage Networks 1568 Email: jefftant@gmail.com