idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-16.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 (April 19, 2018) is 2200 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 1003 -- Looks like a reference, but probably isn't: '199' on line 1003 -- Looks like a reference, but probably isn't: '1000' on line 1004 -- Looks like a reference, but probably isn't: '1099' on line 1004 -- Looks like a reference, but probably isn't: '500' on line 1005 -- Looks like a reference, but probably isn't: '599' on line 1005 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-13 -- 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: October 21, 2018 A. Bashandy 6 Cisco Systems, Inc. 7 H. Gredler 8 RtBrick Inc. 9 S. Litkowski 10 B. Decraene 11 Orange 12 J. Tantsura 13 Individual 14 April 19, 2018 16 IS-IS Extensions for Segment Routing 17 draft-ietf-isis-segment-routing-extensions-16 19 Abstract 21 Segment Routing (SR) allows for a flexible definition of end-to-end 22 paths within IGP topologies by encoding paths as sequences of 23 topological sub-paths, called "segments". These segments are 24 advertised by the link-state routing protocols (IS-IS and OSPF). 26 This draft describes the necessary IS-IS extensions that need to be 27 introduced for Segment Routing operating on an MPLS data-plane. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 21, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 73 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 74 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 76 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 77 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 78 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 79 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 80 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 81 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 82 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 83 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 18 84 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 85 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 86 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 87 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 88 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 89 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 23 90 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 91 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 26 92 4. Non backward compatible changes with prior versions of this 93 document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 27 97 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 28 98 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 99 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 29 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 102 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 105 9.2. Informative References . . . . . . . . . . . . . . . . . 33 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Introduction 110 Segment Routing (SR) allows for a flexible definition of end-to-end 111 paths within IGP topologies by encoding paths as sequences of 112 topological sub-paths, called "segments". These segments are 113 advertised by the link-state routing protocols (IS-IS and OSPF). Two 114 types of segments are defined, Prefix segments and Adjacency 115 segments. Prefix segments represent an ecmp-aware shortest-path to a 116 prefix, as per the state of the IGP topology. Adjacency segments 117 represent a hop over a specific adjacency between two nodes in the 118 IGP. A prefix segment is typically a multi-hop path while an 119 adjacency segment, in most of the cases, is a one-hop path. SR's 120 control-plane can be applied to both IPv6 and MPLS data-planes, and 121 do not require any additional signaling (other than the regular IGP). 122 For example, when used in MPLS networks, SR paths do not require any 123 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 124 of LSPs established with RSVP or LDP. 126 This draft describes the necessary IS-IS extensions that need to be 127 introduced for Segment Routing operating on an MPLS data-plane. 129 Segment Routing architecture is described in 130 [I-D.ietf-spring-segment-routing]. 132 Segment Routing use cases are described in [RFC7855]. 134 2. Segment Routing Identifiers 136 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 137 defines different types of Segment Identifiers (SID). This document 138 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 139 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 141 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 143 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 144 (Prefix-SID sub-TLV). 146 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 147 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 148 be unique within a given IGP domain (when the L-flag is not set). 149 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 150 that determines the actual SID/label value inside the set of all 151 advertised SID/label ranges of a given router. A receiving router 152 uses the index to determine the actual SID/label value in order to 153 construct forwarding state to a particular destination router. 155 In many use-cases a 'stable transport' IP Address is overloaded as an 156 identifier of a given node. Because the IP Prefixes may be re- 157 advertised into other levels there may be some ambiguity (e.g. 158 Originating router vs. L1L2 router) for which node a particular IP 159 prefix serves as identifier. The Prefix-SID sub-TLV contains the 160 necessary flags to disambiguate IP Prefix to node mappings. 161 Furthermore if a given node has several 'stable transport' IP 162 addresses there are flags to differentiate those among other IP 163 Prefixes advertised from a given node. 165 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 166 and MAY be present in any of the following TLVs: 168 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 170 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 172 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 174 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 176 Binding-TLV defined in Section 2.4. 178 When the IP Reachability TLV is propagated across level boundaries, 179 the Prefix-SID sub-TLV SHOULD be kept. 181 The Prefix-SID sub-TLV has the following format: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | Flags | Algorithm | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SID/Index/Label (variable) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 where: 193 Type: TBD, suggested value 3 195 Length: variable. 197 Flags: 1 octet field of following flags: 199 0 1 2 3 4 5 6 7 200 +-+-+-+-+-+-+-+-+ 201 |R|N|P|E|V|L| | 202 +-+-+-+-+-+-+-+-+ 204 where: 206 R-Flag: Re-advertisement flag. If set, then the prefix to 207 which this Prefix-SID is attached, has been propagated by the 208 router either from another level (i.e., from level-1 to level-2 209 or the opposite) or from redistribution (e.g.: from another 210 protocol). 212 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 213 the router identified by the prefix. Typically, the N-Flag is 214 set on Prefix-SIDs attached to a router loopback address. The 215 N-Flag is set when the Prefix-SID is a Node-SID as described in 216 [I-D.ietf-spring-segment-routing]. 218 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 219 pop the Prefix-SID before delivering the packet to the node 220 that advertised the Prefix-SID. 222 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 223 the Prefix-SID originator MUST replace the Prefix-SID with a 224 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 225 IPv6) before forwarding the packet. 227 V-Flag: Value flag. If set, then the Prefix-SID carries a 228 value (instead of an index). By default the flag is UNSET. 230 L-Flag: Local Flag. If set, then the value/index carried by 231 the Prefix-SID has local significance. By default the flag is 232 UNSET. 234 Other bits: MUST be zero when originated and ignored when 235 received. 237 Algorithm: the router may use various algorithms when calculating 238 reachability to other nodes or to prefixes attached to these 239 nodes. Algorithms identifiers are defined in Section 3.2. 240 Examples of these algorithms are metric based Shortest Path First 241 (SPF), various sorts of Constrained SPF, etc. The algorithm field 242 of the Prefix-SID contains the identifier of the algorithm the 243 router has used in order to compute the reachability of the prefix 244 to which the Prefix-SID is associated. 246 At origination, the Prefix-SID algorithm field MUST be set to 0 or 247 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 249 A router receiving a Prefix-SID from a remote node and with an 250 algorithm value that such remote node has not advertised in the 251 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 252 TLV. 254 SID/Index/Label: according to the V and L flags, it contains 255 either: 257 * A 4 octet index defining the offset in the SID/Label space 258 advertised by this router using the encodings defined in 259 Section 3.1. In this case the V and L flags MUST be unset. 261 * A 3 octet local label where the 20 rightmost bits are used for 262 encoding the label value. In this case the V and L flags MUST 263 be set. 265 2.1.1. Flags 267 2.1.1.1. R and N Flags 269 The R-Flag MUST be set for prefixes that are not local to the router 270 and either: 272 advertised because of propagation (Level-1 into Level-2); 274 advertised because of leaking (Level-2 into Level-1); 276 advertised because of redistribution (e.g.: from another 277 protocol). 279 In the case where a Level-1-2 router has local interface addresses 280 configured in one level, it may also propagate these addresses into 281 the other level. In such case, the Level-1-2 router MUST NOT set the 282 R bit. The R-bit MUST be set only for prefixes that are not local to 283 the router and advertised by the router because of propagation and/or 284 leaking. 286 The N-Flag is used in order to define a Node-SID. A router MAY set 287 the N-Flag only if all of the following conditions are met: 289 The prefix to which the Prefix-SID is attached is local to the 290 router (i.e., the prefix is configured on one of the local 291 interfaces, e.g., a 'stable transport' loopback). 293 The prefix to which the Prefix-SID is attached MUST have a Prefix 294 length of either /32 (IPv4) or /128 (IPv6). 296 The router MUST ignore the N-Flag on a received Prefix-SID if the 297 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 299 [RFC7794] also defines the N and R flags and with the same semantics 300 of the equivalent flags defined in this document. There will be a 301 transition period where both sets of flags will be used and 302 eventually only the flags of the Prefix Attributes will remain. 303 During the transition period implementations supporting the N and R 304 flags defined in this document and the N and R flags defined in 305 [RFC7794] MUST advertise and parse all flags. In case the received 306 flags have different values, the value of the flags defined in 307 [RFC7794] prevails. 309 2.1.1.2. E and P Flags 311 When calculating the outgoing label for the prefix, the router MUST 312 take into account E and P flags advertised by the next-hop router, if 313 next-hop router advertised the SID for the prefix. This MUST be done 314 regardless of next-hop router contributing to the best path to the 315 prefix or not. 317 When propagating (either from Level-1 to Level-2 or vice versa) a 318 reachability advertisement originated by another IS-IS speaker, the 319 router MUST set the P-flag and MUST clear the E-flag of the related 320 Prefix-SIDs. 322 The following behavior is associated with the settings of the E and P 323 flags: 325 o If the P-flag is not set then any upstream neighbor of the Prefix- 326 SID originator MUST pop the Prefix-SID. This is equivalent to the 327 penultimate hop popping mechanism used in the MPLS dataplane which 328 improves performance of the ultimate hop. MPLS EXP bits of the 329 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 330 being removed). If the P-flag is unset the received E-flag is 331 ignored. 333 o If the P-flag is set then: 335 * If the E-flag is not set then any upstream neighbor of the 336 Prefix-SID originator MUST keep the Prefix-SID on top of the 337 stack. This is useful when, e.g., the originator of the 338 Prefix-SID must stitch the incoming packet into a continuing 339 MPLS LSP to the final destination. This could occur at an 340 inter-area border router (prefix propagation from one area to 341 another) or at an inter-domain border router (prefix 342 propagation from one domain to another). 344 * If the E-flag is set then any upstream neighbor of the Prefix- 345 SID originator MUST replace the PrefixSID with a Prefix-SID 346 having an Explicit-NULL value. This is useful, e.g., when the 347 originator of the Prefix-SID is the final destination for the 348 related prefix and the originator wishes to receive the packet 349 with the original EXP bits. 351 2.1.2. Prefix-SID Propagation 353 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 354 gets propagated across level boundaries. 356 The level-1-2 router that propagates the Prefix-SID sub-TLV between 357 levels MUST set the R-flag. 359 If the Prefix-SID contains a global index (L and V flags unset) and 360 it is propagated as such (with L and V flags unset), the value of the 361 index MUST be preserved when propagated between levels. 363 The level-1-2 router that propagates the Prefix-SID sub-TLV between 364 levels MAY change the setting of the L and V flags in case a local 365 label value is encoded in the Prefix-SID instead of the received 366 value. 368 2.2. Adjacency Segment Identifier 370 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 371 TLV (Adj-SID sub-TLV). 373 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 374 Routing IGP-Adjacency-SID as defined in 376 [I-D.ietf-spring-segment-routing] with flags and fields that may be 377 used, in future extensions of Segment Routing, for carrying other 378 types of SIDs. 380 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 381 below: 383 TLV-22 (Extended IS reachability)[RFC5305] 385 TLV-222 (Multitopology IS)[RFC5120] 387 TLV-23 (IS Neighbor Attribute)[RFC5311] 389 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 391 TLV-141 (inter-AS reachability information)[RFC5316] 393 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 394 neighbor. 396 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 398 The following format is defined for the Adj-SID sub-TLV: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | Flags | Weight | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | SID/Label/Index (variable) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 where: 410 Type: TBD, suggested value 31 412 Length: variable. 414 Flags: 1 octet field of following flags: 416 0 1 2 3 4 5 6 7 417 +-+-+-+-+-+-+-+-+ 418 |F|B|V|L|S|P| | 419 +-+-+-+-+-+-+-+-+ 421 where: 423 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 424 to an adjacency with outgoing IPv4 encapsulation. If set then 425 the Adj-SID refers to an adjacency with outgoing IPv6 426 encapsulation. 428 B-Flag: Backup flag. If set, the Adj-SID is eligible for 429 protection (e.g.: using IPFRR or MPLS-FRR) as described in 430 [RFC8355]. 432 V-Flag: Value flag. If set, then the Adj-SID carries a value. 433 By default the flag is SET. 435 L-Flag: Local Flag. If set, then the value/index carried by 436 the Adj-SID has local significance. By default the flag is 437 SET. 439 S-Flag. Set flag. When set, the S-Flag indicates that the 440 Adj-SID refers to a set of adjacencies (and therefore MAY be 441 assigned to other adjacencies as well). 443 P-Flag. Persistent flag. When set, the P-Flag indicates that 444 the Adj-SID is persistently allocated, i.e., the Adj-SID value 445 remains consistent across router restart and/or interface flap. 447 Other bits: MUST be zero when originated and ignored when 448 received. 450 Weight: 1 octet. The value represents the weight of the Adj-SID 451 for the purpose of load balancing. The use of the weight is 452 defined in [I-D.ietf-spring-segment-routing]. 454 SID/Index/Label: according to the V and L flags, it contains 455 either: 457 * A 3 octet local label where the 20 rightmost bits are used for 458 encoding the label value. In this case the V and L flags MUST 459 be set. 461 * A 4 octet index defining the offset in the SID/Label space 462 advertised by this router using the encodings defined in 463 Section 3.1. In this case V and L flags MUST be unset. 465 An SR capable router MAY allocate an Adj-SID for each of its 466 adjacencies and SHOULD set the B-Flag when the adjacency is 467 eligible for protection (IP or MPLS). 469 An SR capable router MAY allocate more than one Adj-SID to an 470 adjacency. 472 An SR capable router MAY allocate the same Adj-SID to different 473 adjacencies. 475 When the P-flag is not set, the Adj-SID MAY be persistent. When 476 the P-flag is set, the Adj-SID MUST be persistent. 478 Examples of use of the Adj-SID sub-TLV are described in 479 [I-D.ietf-spring-segment-routing]. 481 The F-flag is used in order for the router to advertise the 482 outgoing encapsulation of the adjacency the Adj-SID is attached 483 to. 485 2.2.2. Adjacency Segment Identifiers in LANs 487 In LAN subnetworks, the Designated Intermediate System (DIS) is 488 elected and originates the Pseudonode-LSP (PN-LSP) including all 489 neighbors of the DIS. 491 When Segment Routing is used, each router in the LAN MAY advertise 492 the Adj-SID of each of its neighbors. Since, on LANs, each router 493 only advertises one adjacency to the DIS (and doesn't advertise any 494 other adjacency), each router advertises the set of Adj-SIDs (for 495 each of its neighbors) inside a newly defined sub-TLV part of the TLV 496 advertising the adjacency to the DIS (e.g.: TLV-22). 498 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 499 suggested value 32) containing the set of Adj-SIDs the router 500 assigned to each of its LAN neighbors. 502 The format of the LAN-Adj-SID sub-TLV is as follows: 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type | Length | Flags | Weight | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | System-ID (6 octets) | 512 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | SID/Label/Index (variable) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 where: 522 Type: TBD, suggested value 32 524 Length: variable. 526 Flags: 1 octet field of following flags: 528 0 1 2 3 4 5 6 7 529 +-+-+-+-+-+-+-+-+ 530 |F|B|V|L|S|P| | 531 +-+-+-+-+-+-+-+-+ 533 where F, B, V, L, S and P flags are defined in Section 2.2.1. 534 Other bits: MUST be zero when originated and ignored when 535 received. 537 Weight: 1 octet. The value represents the weight of the Adj-SID 538 for the purpose of load balancing. The use of the weight is 539 defined in [I-D.ietf-spring-segment-routing]. 541 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 542 defined in [ISO10589]. 544 SID/Index/Label: according to the V and L flags, it contains 545 either: 547 * A 3 octet local label where the 20 rightmost bits are used for 548 encoding the label value. In this case the V and L flags MUST 549 be set. 551 * A 4 octet index defining the offset in the SID/Label space 552 advertised by this router using the encodings defined in 553 Section 3.1. In this case V and L flags MUST be unset. 555 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 556 MUST NOT appear in TLV 141. 558 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 559 the P-flag is set, the LAN-Adj-SID MUST be persistent. 561 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 562 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 563 advertisements of the adjacency to the DIS MUST be used and all 564 advertisements MUST have the same metric. 566 Each router within the level, by receiving the DIS PN LSP as well as 567 the non-PN LSP of each router in the LAN, is capable of 568 reconstructing the LAN topology as well as the set of Adj-SID each 569 router uses for each of its neighbors. 571 A label is encoded in 3 octets (in the 20 rightmost bits). 573 An index is encoded in 4 octets. 575 2.3. SID/Label Sub-TLV 577 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 578 defined in this document: 580 SR-Capabilities Sub-TLV (Section 3.1) 582 SR Local Block Sub-TLV (Section 3.3) 584 SID/Label Binding TLV (Section 2.4) 586 Multi-Topology SID/Label Binding TLV (Section 2.5) 588 Note that the code point used in all of the above cases is the SID/ 589 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 590 149 and 150" registry. 592 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 593 sub-TLV has the following format: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | SID/Label (variable) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 where: 605 Type: TBD, suggested value 1 607 Length: variable 609 SID/Label: if length is set to 3 then the 20 rightmost bits 610 represent a MPLS label. 612 2.4. SID/Label Binding TLV 614 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 615 domain. 617 The SID/Label Binding TLV is used to advertise prefixes to SID/Label 618 mappings. This functionality is called the Segment Routing Mapping 619 Server (SRMS). The behavior of the SRMS is defined in 620 [I-D.ietf-spring-segment-routing-ldp-interop]. 622 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 623 the following format: 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Type | Length | Flags | RESERVED | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Range | Prefix Length | Prefix | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 // Prefix (continued, variable) // 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | SubTLVs (variable) | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 1: SID/Label Binding TLV format 639 o Type: TBD, suggested value 149 641 o Length: variable. 643 o 1 octet of flags 645 o 1 octet of RESERVED 647 o 2 octets of Range 649 o 1 octet of Prefix Length 651 o 0-16 octets of Prefix 653 o sub-TLVs, where each sub-TLV consists of a sequence of: 655 * 1 octet of sub-TLV type 657 * 1 octet of length of the value field of the sub-TLV 659 * 0-243 octets of value 661 2.4.1. Flags 663 Flags: 1 octet field of following flags: 665 0 1 2 3 4 5 6 7 666 +-+-+-+-+-+-+-+-+ 667 |F|M|S|D|A| | 668 +-+-+-+-+-+-+-+-+ 670 where: 672 F-Flag: Address Family flag. If unset, then the Prefix carries an 673 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 675 M-Flag: Mirror Context flag. Set if the advertised SID 676 corresponds to a mirrored context. The use of the M flag is 677 described in [I-D.ietf-spring-segment-routing]. 679 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 680 the entire routing domain. If the S flag is not set, the SID/ 681 Label Binding TLV MUST NOT be leaked between levels. This bit 682 MUST NOT be altered during the TLV leaking. 684 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 685 level-1, the D bit MUST be set. Otherwise, this bit MUST be 686 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 687 leaked from level-1 to level-2. This is to prevent TLV looping 688 across levels. 690 A-Flag: Attached flag. The originator of the SID/Label Binding 691 TLV MAY set the A bit in order to signal that the prefixes and 692 SIDs advertised in the SID/Label Binding TLV are directly 693 connected to their originators. The mechanisms through which the 694 originator of the SID/Label Binding TLV can figure out if a prefix 695 is attached or not are outside the scope of this document (e.g.: 696 through explicit configuration). If the Binding TLV is leaked to 697 other areas/levels the A-flag MUST be cleared. 699 An implementation MAY decide not to honor the S-flag in order not 700 to leak Binding TLV's between levels (for policy reasons). In all 701 cases, the D flag MUST always be set by any router leaking the 702 Binding TLV from level-2 into level-1 and MUST be checked when 703 propagating the Binding TLV from level-1 into level-2. If the D 704 flag is set, the Binding TLV MUST NOT be propagated into level-2. 706 Other bits: MUST be zero when originated and ignored when 707 received. 709 2.4.2. Range 711 The 'Range' field provides the ability to specify a range of 712 addresses and their associated Prefix SIDs. This advertisement 713 supports the SRMS functionality. It is essentially a compression 714 scheme to distribute a continuous Prefix and their continuous, 715 corresponding SID/Label Block. If a single SID is advertised then 716 the range field MUST be set to one. For range advertisements > 1, 717 the number of addresses that need to be mapped into a Prefix-SID and 718 the starting value of the Prefix-SID range. 720 Example 1: if the following router addresses (loopback addresses) 721 need to be mapped into the corresponding Prefix SID indexes. 723 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 724 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 725 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 726 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length |0|0| | RESERVED | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Range = 4 | /32 | 192 | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | .0 | .2 | .1 |Prefix-SID Type| 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | sub-TLV Length| Flags | Algorithm | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | 1 | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Example-2: If the following prefixes need to be mapped into the 742 corresponding Prefix-SID indexes: 744 10.1.1/24, Prefix-SID: Index 51 745 10.1.2/24, Prefix-SID: Index 52 746 10.1.3/24, Prefix-SID: Index 53 747 10.1.4/24, Prefix-SID: Index 54 748 10.1.5/24, Prefix-SID: Index 55 749 10.1.6/24, Prefix-SID: Index 56 750 10.1.7/24, Prefix-SID: Index 57 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Length |0|0| | RESERVED | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Range = 7 | /24 | 10 | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Flags | Algorithm | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | 51 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 It is not expected that a network operator will be able to keep fully 767 continuous Prefix / SID/Index mappings. In order to support 768 noncontinuous mapping ranges an implementation MAY generate several 769 instances of Binding TLVs. 771 For example if a router wants to advertise the following ranges: 773 Range 16: { 192.0.2.1-15, Index 1-15 } 774 Range 6: { 192.0.2.22-27, Index 22-27 } 776 Range 41: { 192.0.2.44-84, Index 80-120 } 778 A router would need to advertise three instances of the Binding TLV. 780 2.4.3. Prefix Length, Prefix 782 The 'Prefix' represents the Forwarding equivalence class at the tail- 783 end of the advertised path. The 'Prefix' does not need to correspond 784 to a routable prefix of the originating node. 786 The 'Prefix Length' field contains the length of the prefix in bits. 787 Only the most significant octets of the Prefix are encoded. (i.e., 1 788 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 789 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 790 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 792 2.4.4. Mapping Server Prefix-SID 794 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 795 and contains the SID/index/label value associated with the prefix and 796 range. The Prefix-SID SubTLV MUST be present in the SID/Label 797 Binding TLV unless the M-flag is set in the Flags field of the parent 798 TLV. 800 A node receiving a MS entry for a prefix MUST check the existence of 801 such prefix in its link-state database prior to consider and use the 802 associated SID. 804 2.4.4.1. Prefix-SID Flags 806 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 807 MAY advertise a mapping with the N flag set when the prefix being 808 mapped is known in the link-state topology with a mask length of 32 809 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 810 mechanisms through which the operator defines that a prefix 811 represents a node are outside the scope of this document (typically 812 it will be through configuration). 814 The other flags defined in Section 2.1 are not used by the Mapping 815 Server and MUST be ignored at reception. 817 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 819 As the mapping server does not specify the originator of a prefix 820 advertisement it is not possible to determine PHP behavior solely 821 based on the Mapping Server Advertisement. However, if additional 822 information is available PHP behavior may safely be done. The 823 required information consists of: 825 o A prefix reachability advertisement for the prefix has been 826 received which includes the Extended Reachability Attribute Flags 827 sub-TLV ([RFC7794]). 829 o X and R flags are both set to 0 in the Extended Reachability 830 Attribute Flags sub-TLV. 832 In the absence of an Extended Reachability Attribute Flags sub-TLV 833 ([RFC7794]) the A flag in the binding TLV indicates that the 834 originator of a prefix reachability advertisement is directly 835 connected to the prefix and thus PHP MUST be done by the neighbors of 836 the router originating the prefix reachability advertisement. Note 837 that A-flag is only valid in the original area in which the Binding 838 TLV is advertised. 840 2.4.4.3. Prefix-SID Algorithm 842 The algorithm field contains the identifier of the algorithm the 843 router MUST use in order to compute reachability to the range of 844 prefixes. Use of the algorithm field is described in Section 2.1. 846 2.4.5. SID/Label Sub-TLV 848 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 849 SID/Label value as defined in Section 2.3. It MUST be present in the 850 SID/Label Binding TLV when the M-flag is set in the Flags field of 851 the parent TLV. 853 2.5. Multi-Topology SID/Label Binding TLV 855 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 856 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 857 has the same format as the SID/Label Binding TLV defined in 858 Section 2.4 with the difference consisting of a Multitopology 859 Identifier (MTID) as defined here below: 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type | Length | MTID | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Flags | RESERVED | Range | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Prefix Length | Prefix (variable) // 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | SubTLVs (variable) | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 2: Multi-Topology SID/Label Binding TLV format 875 where: 877 Type: TBD, suggested value 150 879 Length: variable 881 MTID is the multitopology identifier defined as: 883 0 1 884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | RESVD | MTID | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 RESVD: reserved bits. MUST be reset on transmission and 890 ignored on receive. 892 MTID: a 12-bit field containing the non-zero ID of the topology 893 being announced. The TLV MUST be ignored if the ID is zero. 894 This is to ensure the consistent view of the standard unicast 895 topology. 897 The other fields and SubTLVs are defined in Section 2.4. 899 3. Router Capabilities 901 This section defines sub-TLVs which are inserted into the IS-IS 902 Router Capability TLV-242 that is defined in [RFC7981]. 904 3.1. SR-Capabilities Sub-TLV 906 Segment Routing requires each router to advertise its SR data-plane 907 capability and the range of MPLS label values it uses for Segment 908 Routing in the case where global SIDs are allocated (i.e., global 909 indexes). Data-plane capabilities and label ranges are advertised 910 using the newly defined SR-Capabilities sub-TLV. 912 The Router Capability TLV specifies flags that control its 913 advertisement. The SR Capabilities sub-TLV MUST be propagated 914 throughout the level and MUST NOT be advertised across level 915 boundaries. Therefore Router Capability TLV distribution flags are 916 set accordingly, i.e., the S flag in the Router Capability TLV 917 ([RFC7981]) MUST be unset. 919 The SR Capabilities sub-TLV has following format: 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Type | Length | Flags | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Range | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 // SID/Label Sub-TLV (variable) // 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Type: TBD, suggested value 2 935 Length: variable. 937 Flags: 1 octet of flags. The following are defined: 939 0 1 2 3 4 5 6 7 940 +-+-+-+-+-+-+-+-+ 941 |I|V| | 942 +-+-+-+-+-+-+-+-+ 944 where: 946 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 947 processing SR MPLS encapsulated IPv4 packets on all interfaces. 949 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 950 processing SR MPLS encapsulated IPv6 packets on all interfaces. 952 One or more SRGB Descriptor entries, each of which have the 953 following format: 955 Range: 3 octets. 957 SID/Label sub-TLV (as defined in Section 2.3). 959 SID/Label sub-TLV contains the first value of the SRGB while the 960 range contains the number of SRGB elements. The range value MUST be 961 higher than 0. 963 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 964 but a router MUST NOT advertise more than one SR-Capabilities sub- 965 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 966 same originator, SHOULD select the first advertisement in the lowest 967 numbered LSP. 969 When multiple SRGB Descriptors are advertised the entries define an 970 ordered set of ranges on which a SID index is to be applied. For 971 this reason changing the order in which the descriptors are 972 advertised will have a disruptive effect on forwarding. 974 When a router adds a new SRGB Descriptor to an existing SR- 975 Capabilities sub-TLV the new Descriptor SHOULD add the newly 976 configured block at the end of the sub-TLV and SHOULD NOT change the 977 order of previously advertised blocks. Changing the order of the 978 advertised descriptors will create label churn in the FIB and 979 blackhole / misdirect some traffic during the IGP convergence. In 980 particular, if a range which is not the last is extended it's 981 preferable to add a new range rather than extending the previously 982 advertised range. 984 The originating router MUST ensure the order is same after a graceful 985 restart (using checkpointing, non-volatile storage or any other 986 mechanism) in order to guarantee the same order before and after GR. 988 The originating router MUST NOT advertise overlapping ranges. 990 When a router receives multiple overlapping ranges, it MUST conform 991 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 993 Here follows an example of advertisement of multiple ranges: 995 The originating router advertises following ranges: 996 SR-Cap: range: 100, SID value: 100 997 SR-Cap: range: 100, SID value: 1000 998 SR-Cap: range: 100, SID value: 500 1000 The receiving routers concatenate the ranges in the received 1001 order and build the SRGB as follows: 1003 SRGB = [100, 199] 1004 [1000, 1099] 1005 [500, 599] 1007 The indexes span multiple ranges: 1009 index=0 means label 100 1010 ... 1011 index 99 means label 199 1012 index 100 means label 1000 1013 index 199 means label 1099 1014 ... 1015 index 200 means label 500 1016 ... 1018 3.2. SR-Algorithm Sub-TLV 1020 The router may use various algorithms when calculating reachability 1021 to other nodes or to prefixes attached to these nodes. Examples of 1022 these algorithms are metric based Shortest Path First (SPF), various 1023 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1024 suggested value 19) allows the router to advertise the algorithms 1025 that the router is currently using. Algorithm values are defined in 1026 the "IGP Algorithm Type" registry defined in 1027 [I-D.ietf-ospf-segment-routing-extensions]. The following values 1028 have been defined: 1030 0: Shortest Path First (SPF) algorithm based on link metric. This 1031 is the well-known shortest path algorithm as computed by the IS-IS 1032 Decision process. Consistent with the deployed practice for link- 1033 state protocols, algorithm 0 permits any node to overwrite the SPF 1034 path with a different path based on local policy. 1036 1: Strict Shortest Path First (SPF) algorithm based on link 1037 metric. The algorithm is identical to algorithm 0 but algorithm 1 1038 requires that all nodes along the path will honor the SPF routing 1039 decision. Local policy MUST NOT alter the forwarding decision 1040 computed by algorithm 1 at the node claiming to support algorithm 1041 1. 1043 The Router Capability TLV specifies flags that control its 1044 advertisement. The SR-Algorithm MUST be propagated throughout the 1045 level and MUST NOT be advertised across level boundaries. Therefore 1046 Router Capability TLV distribution flags are set accordingly, i.e., 1047 the S flag MUST be unset. 1049 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1050 time inside the Router Capability TLV. 1052 When the originating router does not advertise the SR-Algorithm sub- 1053 TLV, then all the Prefix-SIDs advertised by the router MUST have 1054 algorithm field set to 0. Any receiving router MUST assume SPF 1055 algorithm (i.e., Shortest Path First). 1057 When the originating router does advertise the SR-Algorithm sub-TLV, 1058 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1060 The SR-Algorithm sub-TLV has following format: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type | Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 where: 1072 Type: TBD, suggested value 19 1074 Length: variable. 1076 Algorithm: 1 octet of algorithm Section 2.1 1078 3.3. SR Local Block Sub-TLV 1080 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1081 node has reserved for local SIDs. Local SIDs are used, e.g., for 1082 Adjacency-SIDs, and may also be allocated by other components than 1083 IS-IS protocol. As an example, an application or a controller may 1084 instruct the router to allocate a specific local SID. Therefore, in 1085 order for such applications or controllers to know what are the local 1086 SIDs available in the router, it is required that the router 1087 advertises its SRLB. 1089 The SRLB Sub-TLV is used for that purpose and has following format: 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Type | Length | Flags | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Range | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 // SID/Label Sub-TLV (variable) // 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Type: TBD, suggested value 22. 1105 Length: variable. 1107 Flags: 1 octet of flags. None are defined at this stage. 1109 One or more SRLB Descriptor entries, each of which have the 1110 following format: 1112 Range: 3 octets. 1114 SID/Label sub-TLV (as defined in Section 2.3). 1116 SID/Label sub-TLV contains the first value of the SRLB while the 1117 range contains the number of SRLB elements. The range value MUST be 1118 higher than 0. 1120 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1121 router MUST NOT advertise more than one SRLB sub-TLV. A router 1122 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1123 select the first advertisement in the lowest numbered LSP. 1125 The originating router MUST NOT advertise overlapping ranges. 1127 It is important to note that each time a SID from the SRLB is 1128 allocated, it SHOULD also be reported to all components (e.g.: 1129 controller or applications) in order for these components to have an 1130 up-to-date view of the current SRLB allocation and in order to avoid 1131 collision between allocation instructions. 1133 Within the context of IS-IS, the reporting of local SIDs is done 1134 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1135 reporting of allocated local SIDs may also be done through other 1136 means and protocols which mechanisms are outside the scope of this 1137 document. 1139 A router advertising the SRLB TLV may also have other label ranges, 1140 outside the SRLB, for its local allocation purposes which are NOT 1141 advertised in the SRLB. For example, it is possible that an 1142 Adjacency-SID is allocated using a local label not part of the SRLB. 1144 3.4. SRMS Preference Sub-TLV 1146 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1147 in order to associate a preference with SRMS advertisements from a 1148 particular source. 1150 The SRMS Preference sub-TLV has following format: 1152 0 1 2 3 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Type | Length | Preference | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 Type: TBD, suggested value 24. 1160 Length: 1. 1162 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1164 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1165 but a router MUST NOT advertise more than one SRMS Preference sub- 1166 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1167 same originator, SHOULD select the first advertisement in the lowest 1168 numbered LSP. 1170 The use of the SRMS Preference during the SID selection process is 1171 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1173 4. Non backward compatible changes with prior versions of this document 1175 This section describes the changes that have been applied to this 1176 document that are not backward compatible with previous versions. 1178 4.1. Encoding of Multiple SRGBs 1180 Version -04 of this document introduced a change in Section 3.1 1181 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1182 and made the support of multiple SRGBs REQUIRED. 1184 The modified method consists of having a single SR-Cap Sub-TLV where 1185 all SRGBs are encoded. In previous versions (prior to version -04) 1186 of this document it was allowed to have multiple occurrences of the 1187 SR-Cap Sub-TLV. 1189 At the time of writing this document, no existing implementations are 1190 affected by the change since no implementations actually (i.e., at 1191 the time of updating this document) encode multiple SRGBs anyway. 1193 5. IANA Considerations 1195 This documents request allocation for the following TLVs and subTLVs. 1197 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1199 This document makes the following registrations in the "sub-TLVs for 1200 TLV 22, 23, 25, 141, 222 and 223" registry. 1202 Type: TBD (suggested value 31) 1204 Description: Adjacency Segment Identifier 1206 TLV 22: yes 1208 TLV 23: yes 1210 TLV 25: no 1212 TLV 141: yes 1214 TLV 222: yes 1216 TLV 223: yes 1218 Reference: This document (Section 2.2.1) 1220 Type: TBD (suggested value 32) 1222 Description: LAN Adjacency Segment Identifier 1224 TLV 22: yes 1226 TLV 23: yes 1228 TLV 25: no 1229 TLV 141: yes 1231 TLV 222: yes 1233 TLV 223: yes 1235 Reference: This document (Section 2.2.2) 1237 5.2. Sub TLVs for Type 135,235,236 and 237 1239 This document makes the following registrations in the "sub-TLVs for 1240 TLV 135,235,236 and 237" registry. 1242 Type: TBD (suggested value 3) 1244 Description: Prefix Segment Identifier 1246 TLV 135: yes 1248 TLV 235: yes 1250 TLV 236: yes 1252 TLV 237: yes 1254 Reference: This document (Section 2.1) 1256 5.3. Sub TLVs for Type 242 1258 This document makes the following registrations in the "sub-TLVs for 1259 TLV 242" registry. 1261 Type: TBD (suggested value 2) 1263 Description: Segment Routing Capability 1265 Reference: This document (Section 3.1) 1267 Type: TBD (suggested value 19) 1269 Description: Segment Routing Algorithm 1271 Reference: This document (Section 3.2) 1272 Type: TBD (suggested value 22) 1274 Description: Segment Routing Local Block (SRLB) 1276 Reference: This document (Section 3.3) 1278 Type: TBD (suggested value 24) 1280 Description: Segment Routing Mapping Server Preference (SRMS 1281 Preference) 1283 Reference: This document (Section 3.4) 1285 5.4. New TLV Codepoint and Sub-TLV registry 1287 This document registers the following TLV: 1289 Type: TBD (suggested value 149) 1291 name: Segment Identifier / Label Binding 1293 IIH: no 1295 LSP: yes 1297 SNP: no 1299 Purge: no 1301 Reference: This document (Section 2.4) 1303 Type: TBD (suggested value 150) 1305 name: Multi-Topology Segment Identifier / Label Binding 1307 IIH: no 1309 LSP: yes 1311 SNP: no 1313 Purge: no 1315 Reference: This document (Section 2.5) 1317 This document creates the following sub-TLV Registry: 1319 Registry: sub-TLVs for TLV 149 and 150 1321 Registration Procedure: Expert review 1323 Reference: This document (Section 2.4) 1325 Type: TBD, suggested value 1 1327 Description: SID/Label 1329 Reference: This document (Section 2.4.5) 1331 Type: TBD, suggested value 3 1333 Description: Prefix-SID 1335 Reference: This document (Section 2.1) 1337 6. Security Considerations 1339 With the use of the extensions defined in this document, IS-IS 1340 carries information which will be used to program the MPLS data plane 1341 [RFC3031]. In general, the same types of attacks that can be carried 1342 out on the IP/IPv6 control plane can be carried out on the MPLS 1343 control plane resulting in traffic being misrouted in the respective 1344 data planes. However, the latter may be more difficult to detect and 1345 isolate. Existing security extensions as described in [RFC5304] and 1346 [RFC5310] apply to these segment routing extensions. 1348 7. Acknowledgements 1350 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1351 Francois and Jesper Skrivers for their contribution to the content of 1352 this document. 1354 8. Contributors 1356 The following people gave a substantial contribution to the content 1357 of this document and should be considered as co-authors: 1359 Peter Psenak 1360 Cisco Systems Inc. 1361 US 1363 Email: ppsenak@cisco.com 1364 Martin Horneffer 1365 Deutsche Telekom 1366 DE 1368 Email: Martin.Horneffer@telekom.de 1370 Wim Henderickx 1371 Nokia 1372 BE 1374 Email: wim.henderickx@nokia.com 1376 Edward Crabbe 1377 Individual 1378 US 1380 Email: edward.crabbe@gmail.com 1382 Rob Shakir 1383 Google 1384 UK 1386 Email: robjs@google.com 1388 Igor Milojevic 1389 Individual 1390 RS 1392 Email: milojevicigor@gmail.com 1394 Saku Ytti 1395 TDC 1396 FI 1398 Email: saku@ytti.fi 1400 Steven Luong 1401 Cisco Systems Inc. 1402 US 1404 Email: sluong@cisco.com 1406 9. References 1408 9.1. Normative References 1410 [I-D.ietf-ospf-segment-routing-extensions] 1411 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1412 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1413 Extensions for Segment Routing", draft-ietf-ospf-segment- 1414 routing-extensions-24 (work in progress), December 2017. 1416 [I-D.ietf-spring-segment-routing] 1417 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1418 Litkowski, S., and R. Shakir, "Segment Routing 1419 Architecture", draft-ietf-spring-segment-routing-15 (work 1420 in progress), January 2018. 1422 [I-D.ietf-spring-segment-routing-ldp-interop] 1423 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1424 S. Litkowski, "Segment Routing interworking with LDP", 1425 draft-ietf-spring-segment-routing-ldp-interop-11 (work in 1426 progress), April 2018. 1428 [I-D.ietf-spring-segment-routing-mpls] 1429 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1430 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1431 data plane", draft-ietf-spring-segment-routing-mpls-13 1432 (work in progress), April 2018. 1434 [ISO10589] 1435 International Organization for Standardization, 1436 "Intermediate system to Intermediate system intra-domain 1437 routeing information exchange protocol for use in 1438 conjunction with the protocol for providing the 1439 connectionless-mode Network Service (ISO 8473)", ISO/ 1440 IEC 10589:2002, Second Edition, Nov 2002. 1442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1443 Requirement Levels", BCP 14, RFC 2119, 1444 DOI 10.17487/RFC2119, March 1997, 1445 . 1447 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1448 Label Switching Architecture", RFC 3031, 1449 DOI 10.17487/RFC3031, January 2001, 1450 . 1452 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1453 Topology (MT) Routing in Intermediate System to 1454 Intermediate Systems (IS-ISs)", RFC 5120, 1455 DOI 10.17487/RFC5120, February 2008, 1456 . 1458 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1459 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1460 2008, . 1462 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1463 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1464 2008, . 1466 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1467 DOI 10.17487/RFC5308, October 2008, 1468 . 1470 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1471 and M. Fanto, "IS-IS Generic Cryptographic 1472 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1473 2009, . 1475 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1476 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1477 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1478 March 2016, . 1480 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1481 for Advertising Router Information", RFC 7981, 1482 DOI 10.17487/RFC7981, October 2016, 1483 . 1485 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1486 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1487 May 2017, . 1489 9.2. Informative References 1491 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1492 Shand, "Simplified Extension of Link State PDU (LSP) Space 1493 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1494 . 1496 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1497 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1498 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1499 December 2008, . 1501 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1502 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1503 Packet Routing in Networking (SPRING) Problem Statement 1504 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1505 2016, . 1507 [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. 1508 Shakir, "Resiliency Use Cases in Source Packet Routing in 1509 Networking (SPRING) Networks", RFC 8355, 1510 DOI 10.17487/RFC8355, March 2018, 1511 . 1513 Authors' Addresses 1515 Stefano Previdi (editor) 1516 Cisco Systems, Inc. 1517 IT 1519 Email: stefano@previdi.net 1521 Les Ginsberg (editor) 1522 Cisco Systems, Inc. 1523 IT 1525 Email: ginsberg@cisco.com 1527 Clarence Filsfils 1528 Cisco Systems, Inc. 1529 Brussels 1530 BE 1532 Email: cfilsfil@cisco.com 1534 Ahmed Bashandy 1535 Cisco Systems, Inc. 1536 170, West Tasman Drive 1537 San Jose, CA 95134 1538 US 1540 Email: bashandy@cisco.com 1541 Hannes Gredler 1542 RtBrick Inc. 1544 Email: hannes@rtbrick.com 1546 Stephane Litkowski 1547 Orange 1548 FR 1550 Email: stephane.litkowski@orange.com 1552 Bruno Decraene 1553 Orange 1554 FR 1556 Email: bruno.decraene@orange.com 1558 Jeff Tantsura 1559 Individual 1561 Email: jefftant@gmail.com