idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2017) is 2313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '100' on line 1000 -- Looks like a reference, but probably isn't: '199' on line 1000 -- Looks like a reference, but probably isn't: '1000' on line 1001 -- Looks like a reference, but probably isn't: '1099' on line 1001 -- Looks like a reference, but probably isn't: '500' on line 1002 -- Looks like a reference, but probably isn't: '599' on line 1002 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-09 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets S. Previdi, Ed. 3 Internet-Draft L. Ginsberg, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: June 22, 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 December 19, 2017 16 IS-IS Extensions for Segment Routing 17 draft-ietf-isis-segment-routing-extensions-15 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", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on June 22, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 70 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 3 71 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 73 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 74 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 75 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 76 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 77 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 78 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 79 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15 80 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 81 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 17 82 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 18 83 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18 84 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19 85 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19 86 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 87 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23 88 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 89 4. Non backward compatible changes with prior versions of this 90 document . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 25 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 94 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 95 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27 96 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 100 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 103 9.2. Informative References . . . . . . . . . . . . . . . . . 32 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 106 1. Introduction 108 Segment Routing (SR) allows for a flexible definition of end-to-end 109 paths within IGP topologies by encoding paths as sequences of 110 topological sub-paths, called "segments". These segments are 111 advertised by the link-state routing protocols (IS-IS and OSPF). Two 112 types of segments are defined, Prefix segments and Adjacency 113 segments. Prefix segments represent an ecmp-aware shortest-path to a 114 prefix, as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 do not require any additional signaling (other than the regular IGP). 120 For example, when used in MPLS networks, SR paths do not require any 121 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 122 of LSPs established with RSVP or LDP. 124 This draft describes the necessary IS-IS extensions that need to be 125 introduced for Segment Routing operating on an MPLS data-plane. 127 Segment Routing architecture is described in 128 [I-D.ietf-spring-segment-routing]. 130 Segment Routing use cases are described in [RFC7855]. 132 2. Segment Routing Identifiers 134 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 135 defines different types of Segment Identifiers (SID). This document 136 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 137 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 139 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 141 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 142 (Prefix-SID sub-TLV). 144 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 145 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 146 be unique within a given IGP domain (when the L-flag is not set). 147 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 148 that determines the actual SID/label value inside the set of all 149 advertised SID/label ranges of a given router. A receiving router 150 uses the index to determine the actual SID/label value in order to 151 construct forwarding state to a particular destination router. 153 In many use-cases a 'stable transport' IP Address is overloaded as an 154 identifier of a given node. Because the IP Prefixes may be re- 155 advertised into other levels there may be some ambiguity (e.g. 156 Originating router vs. L1L2 router) for which node a particular IP 157 prefix serves as identifier. The Prefix-SID sub-TLV contains the 158 necessary flags to disambiguate IP Prefix to node mappings. 159 Furthermore if a given node has several 'stable transport' IP 160 addresses there are flags to differentiate those among other IP 161 Prefixes advertised from a given node. 163 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 164 and MAY be present in any of the following TLVs: 166 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 168 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 170 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 172 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 174 Binding-TLV defined in Section 2.4. 176 When the IP Reachability TLV is propagated across level boundaries, 177 the Prefix-SID sub-TLV SHOULD be kept. 179 The Prefix-SID sub-TLV has the following format: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Flags | Algorithm | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SID/Index/Label (variable) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 where: 191 Type: TBD, suggested value 3 193 Length: variable. 195 Flags: 1 octet field of following flags: 197 0 1 2 3 4 5 6 7 198 +-+-+-+-+-+-+-+-+ 199 |R|N|P|E|V|L| | 200 +-+-+-+-+-+-+-+-+ 202 where: 204 R-Flag: Re-advertisement flag. If set, then the prefix to 205 which this Prefix-SID is attached, has been propagated by the 206 router either from another level (i.e., from level-1 to level-2 207 or the opposite) or from redistribution (e.g.: from another 208 protocol). 210 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 211 the router identified by the prefix. Typically, the N-Flag is 212 set on Prefix-SIDs attached to a router loopback address. The 213 N-Flag is set when the Prefix-SID is a Node-SID as described in 214 [I-D.ietf-spring-segment-routing]. 216 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 217 pop the Prefix-SID before delivering the packet to the node 218 that advertised the Prefix-SID. 220 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 221 the Prefix-SID originator MUST replace the Prefix-SID with a 222 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 223 IPv6) before forwarding the packet. 225 V-Flag: Value flag. If set, then the Prefix-SID carries a 226 value (instead of an index). By default the flag is UNSET. 228 L-Flag: Local Flag. If set, then the value/index carried by 229 the Prefix-SID has local significance. By default the flag is 230 UNSET. 232 Other bits: MUST be zero when originated and ignored when 233 received. 235 Algorithm: the router may use various algorithms when calculating 236 reachability to other nodes or to prefixes attached to these 237 nodes. Algorithms identifiers are defined in Section 3.2. 238 Examples of these algorithms are metric based Shortest Path First 239 (SPF), various sorts of Constrained SPF, etc. The algorithm field 240 of the Prefix-SID contains the identifier of the algorithm the 241 router has used in order to compute the reachability of the prefix 242 the Prefix-SID is associated to. 244 At origination, the Prefix-SID algorithm field MUST be set to 0 or 245 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 247 A router receiving a Prefix-SID from a remote node and with an 248 algorithm value that such remote node has not advertised in the 249 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 250 TLV. 252 SID/Index/Label: according to the V and L flags, it contains 253 either: 255 * A 4 octet index defining the offset in the SID/Label space 256 advertised by this router using the encodings defined in 257 Section 3.1. In this case the V and L flags MUST be unset. 259 * A 3 octet local label where the 20 rightmost bits are used for 260 encoding the label value. In this case the V and L flags MUST 261 be set. 263 2.1.1. Flags 265 2.1.1.1. R and N Flags 267 The R-Flag MUST be set for prefixes that are not local to the router 268 and either: 270 advertised because of propagation (Level-1 into Level-2); 272 advertised because of leaking (Level-2 into Level-1); 274 advertised because of redistribution (e.g.: from another 275 protocol). 277 In the case where a Level-1-2 router has local interface addresses 278 configured in one level, it may also propagate these addresses into 279 the other level. In such case, the Level-1-2 router MUST NOT set the 280 R bit. The R-bit MUST be set only for prefixes that are not local to 281 the router and advertised by the router because of propagation and/or 282 leaking. 284 The N-Flag is used in order to define a Node-SID. A router MAY set 285 the N-Flag only if all of the following conditions are met: 287 The prefix to which the Prefix-SID is attached is local to the 288 router (i.e., the prefix is configured on one of the local 289 interfaces, e.g., a 'stable transport' loopback). 291 The prefix to which the Prefix-SID is attached MUST have a Prefix 292 length of either /32 (IPv4) or /128 (IPv6). 294 The router MUST ignore the N-Flag on a received Prefix-SID if the 295 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 297 [RFC7794] also defines the N and R flags and with the same semantics 298 of the equivalent flags defined in this document. There will be a 299 transition period where both sets of flags will be used and 300 eventually only the flags of the Prefix Attributes will remain. 301 During the transition period implementations supporting the N and R 302 flags defined in this document and the N and R flags defined in 303 [RFC7794] MUST advertise and parse all flags. In case the received 304 flags have different values, the value of the flags defined in 305 [RFC7794] prevails. 307 2.1.1.2. E and P Flags 309 When calculating the outgoing label for the prefix, the router MUST 310 take into account E and P flags advertised by the next-hop router, if 311 next-hop router advertised the SID for the prefix. This MUST be done 312 regardless of next-hop router contributing to the best path to the 313 prefix or not. 315 When propagating (either from Level-1 to Level-2 or vice versa) a 316 reachability advertisement originated by another IS-IS speaker, the 317 router MUST set the P-flag and MUST clear the E-flag of the related 318 Prefix-SIDs. 320 The following behavior is associated with the settings of the E and P 321 flags: 323 o If the P-flag is not set then any upstream neighbor of the Prefix- 324 SID originator MUST pop the Prefix-SID. This is equivalent to the 325 penultimate hop popping mechanism used in the MPLS dataplane which 326 improves performance of the ultimate hop. MPLS EXP bits of the 327 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 328 being removed). If the P-flag is unset the received E-flag is 329 ignored. 331 o If the P-flag is set then: 333 * If the E-flag is not set then any upstream neighbor of the 334 Prefix-SID originator MUST keep the Prefix-SID on top of the 335 stack. This is useful when, e.g., the originator of the 336 Prefix-SID must stitch the incoming packet into a continuing 337 MPLS LSP to the final destination. This could occur at an 338 inter-area border router (prefix propagation from one area to 339 another) or at an inter-domain border router (prefix 340 propagation from one domain to another). 342 * If the E-flag is set then any upstream neighbor of the Prefix- 343 SID originator MUST replace the PrefixSID with a Prefix-SID 344 having an Explicit-NULL value. This is useful, e.g., when the 345 originator of the Prefix-SID is the final destination for the 346 related prefix and the originator wishes to receive the packet 347 with the original EXP bits. 349 2.1.2. Prefix-SID Propagation 351 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 352 gets propagated across level boundaries. 354 The level-1-2 router that propagates the Prefix-SID sub-TLV between 355 levels MUST set the R-flag. 357 If the Prefix-SID contains a global index (L and V flags unset) and 358 it is propagated as such (with L and V flags unset), the value of the 359 index MUST be preserved when propagated between levels. 361 The level-1-2 router that propagates the Prefix-SID sub-TLV between 362 levels MAY change the setting of the L and V flags in case a local 363 label value is encoded in the Prefix-SID instead of the received 364 value. 366 2.2. Adjacency Segment Identifier 368 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 369 TLV (Adj-SID sub-TLV). 371 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 372 Routing IGP-Adjacency-SID as defined in 373 [I-D.ietf-spring-segment-routing] with flags and fields that may be 374 used, in future extensions of Segment Routing, for carrying other 375 types of SIDs. 377 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 378 below: 380 TLV-22 (Extended IS reachability)[RFC5305] 382 TLV-222 (Multitopology IS)[RFC5120] 384 TLV-23 (IS Neighbor Attribute)[RFC5311] 386 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 387 TLV-141 (inter-AS reachability information)[RFC5316] 389 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 390 neighbor. 392 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 394 The following format is defined for the Adj-SID sub-TLV: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | Flags | Weight | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | SID/Label/Index (variable) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 where: 406 Type: TBD, suggested value 31 408 Length: variable. 410 Flags: 1 octet field of following flags: 412 0 1 2 3 4 5 6 7 413 +-+-+-+-+-+-+-+-+ 414 |F|B|V|L|S|P| | 415 +-+-+-+-+-+-+-+-+ 417 where: 419 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 420 to an adjacency with outgoing IPv4 encapsulation. If set then 421 the Adj-SID refers to an adjacency with outgoing IPv6 422 encapsulation. 424 B-Flag: Backup flag. If set, the Adj-SID is eligible for 425 protection (e.g.: using IPFRR or MPLS-FRR) as described in 426 [I-D.ietf-spring-resiliency-use-cases]. 428 V-Flag: Value flag. If set, then the Adj-SID carries a value. 429 By default the flag is SET. 431 L-Flag: Local Flag. If set, then the value/index carried by 432 the Adj-SID has local significance. By default the flag is 433 SET. 435 S-Flag. Set flag. When set, the S-Flag indicates that the 436 Adj-SID refers to a set of adjacencies (and therefore MAY be 437 assigned to other adjacencies as well). 439 P-Flag. Persistent flag. When set, the P-Flag indicates that 440 the Adj-SID is persistently allocated, i.e., the Adj-SID value 441 remains consistent across router restart and/or interface flap. 443 Other bits: MUST be zero when originated and ignored when 444 received. 446 Weight: 1 octet. The value represents the weight of the Adj-SID 447 for the purpose of load balancing. The use of the weight is 448 defined in [I-D.ietf-spring-segment-routing]. 450 SID/Index/Label: according to the V and L flags, it contains 451 either: 453 * A 3 octet local label where the 20 rightmost bits are used for 454 encoding the label value. In this case the V and L flags MUST 455 be set. 457 * A 4 octet index defining the offset in the SID/Label space 458 advertised by this router using the encodings defined in 459 Section 3.1. In this case V and L flags MUST be unset. 461 An SR capable router MAY allocate an Adj-SID for each of its 462 adjacencies and SHOULD set the B-Flag when the adjacency is 463 eligible for protection (IP or MPLS). 465 An SR capable router MAY allocate more than one Adj-SID to an 466 adjacency. 468 An SR capable router MAY allocate the same Adj-SID to different 469 adjacencies. 471 When the P-flag is not set, the Adj-SID MAY be persistent. When 472 the P-flag is set, the Adj-SID MUST be persistent. 474 Examples of use of the Adj-SID sub-TLV are described in 475 [I-D.ietf-spring-segment-routing]. 477 The F-flag is used in order for the router to advertise the 478 outgoing encapsulation of the adjacency the Adj-SID is attached 479 to. 481 2.2.2. Adjacency Segment Identifiers in LANs 483 In LAN subnetworks, the Designated Intermediate System (DIS) is 484 elected and originates the Pseudonode-LSP (PN-LSP) including all 485 neighbors of the DIS. 487 When Segment Routing is used, each router in the LAN MAY advertise 488 the Adj-SID of each of its neighbors. Since, on LANs, each router 489 only advertises one adjacency to the DIS (and doesn't advertise any 490 other adjacency), each router advertises the set of Adj-SIDs (for 491 each of its neighbors) inside a newly defined sub-TLV part of the TLV 492 advertising the adjacency to the DIS (e.g.: TLV-22). 494 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 495 suggested value 32) containing the set of Adj-SIDs the router 496 assigned to each of its LAN neighbors. 498 The format of the LAN-Adj-SID sub-TLV is as follows: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | Flags | Weight | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | System-ID (6 octets) | 508 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | SID/Label/Index (variable) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 where: 518 Type: TBD, suggested value 32 520 Length: variable. 522 Flags: 1 octet field of following flags: 524 0 1 2 3 4 5 6 7 525 +-+-+-+-+-+-+-+-+ 526 |F|B|V|L|S|P| | 527 +-+-+-+-+-+-+-+-+ 529 where F, B, V, L, S and P flags are defined in Section 2.2.1. 530 Other bits: MUST be zero when originated and ignored when 531 received. 533 Weight: 1 octet. The value represents the weight of the Adj-SID 534 for the purpose of load balancing. The use of the weight is 535 defined in [I-D.ietf-spring-segment-routing]. 537 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 538 defined in [ISO10589]. 540 SID/Index/Label: according to the V and L flags, it contains 541 either: 543 * A 3 octet local label where the 20 rightmost bits are used for 544 encoding the label value. In this case the V and L flags MUST 545 be set. 547 * A 4 octet index defining the offset in the SID/Label space 548 advertised by this router using the encodings defined in 549 Section 3.1. In this case V and L flags MUST be unset. 551 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 552 MUST NOT appear in TLV 141. 554 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 555 the P-flag is set, the LAN-Adj-SID MUST be persistent. 557 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 558 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 559 advertisements of the adjacency to the DIS MUST be used and all 560 advertisements MUST have the same metric. 562 Each router within the level, by receiving the DIS PN LSP as well as 563 the non-PN LSP of each router in the LAN, is capable of 564 reconstructing the LAN topology as well as the set of Adj-SID each 565 router uses for each of its neighbors. 567 A label is encoded in 3 octets (in the 20 rightmost bits). 569 An index is encoded in 4 octets. 571 2.3. SID/Label Sub-TLV 573 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 574 defined in this document: 576 SR-Capabilities Sub-TLV (Section 3.1) 577 SR Local Block Sub-TLV (Section 3.3) 579 SID/Label Binding TLV (Section 2.4) 581 Multi-Topology SID/Label Binding TLV (Section 2.5) 583 Note that the code point used in all of the above cases is the SID/ 584 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 585 149 and 150" registry. 587 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 588 sub-TLV has the following format: 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Length | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | SID/Label (variable) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 where: 600 Type: TBD, suggested value 1 602 Length: variable 604 SID/Label: if length is set to 3 then the 20 rightmost bits 605 represent a MPLS label. 607 2.4. SID/Label Binding TLV 609 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 610 domain. 612 The SID/Label Binding TLV is used to advertise prefixes to SID/Label 613 mappings. This functionality is called the Segment Routing Mapping 614 Server (SRMS). The behavior of the SRMS is defined in 615 [I-D.ietf-spring-segment-routing-ldp-interop]. 617 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 618 the following format: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | Flags | RESERVED | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Range | Prefix Length | Prefix | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 // Prefix (continued, variable) // 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | SubTLVs (variable) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 1: SID/Label Binding TLV format 634 o Type: TBD, suggested value 149 636 o Length: variable. 638 o 1 octet of flags 640 o 1 octet of RESERVED 642 o 2 octets of Range 644 o 1 octet of Prefix Length 646 o 0-16 octets of Prefix 648 o sub-TLVs, where each sub-TLV consists of a sequence of: 650 * 1 octet of sub-TLV type 652 * 1 octet of length of the value field of the sub-TLV 654 * 0-243 octets of value 656 2.4.1. Flags 658 Flags: 1 octet field of following flags: 660 0 1 2 3 4 5 6 7 661 +-+-+-+-+-+-+-+-+ 662 |F|M|S|D|A| | 663 +-+-+-+-+-+-+-+-+ 665 where: 667 F-Flag: Address Family flag. If unset, then the Prefix carries an 668 IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 670 M-Flag: Mirror Context flag. Set if the advertised SID 671 corresponds to a mirrored context. The use of the M flag is 672 described in [I-D.ietf-spring-segment-routing]. 674 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 675 the entire routing domain. If the S flag is not set, the SID/ 676 Label Binding TLV MUST NOT be leaked between levels. This bit 677 MUST NOT be altered during the TLV leaking. 679 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 680 level-1, the D bit MUST be set. Otherwise, this bit MUST be 681 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 682 leaked from level-1 to level-2. This is to prevent TLV looping 683 across levels. 685 A-Flag: Attached flag. The originator of the SID/Label Binding 686 TLV MAY set the A bit in order to signal that the prefixes and 687 SIDs advertised in the SID/Label Binding TLV are directly 688 connected to their originators. The mechanisms through which the 689 originator of the SID/Label Binding TLV can figure out if a prefix 690 is attached or not are outside the scope of this document (e.g.: 691 through explicit configuration). If the Binding TLV is leaked to 692 other areas/levels the A-flag MUST be cleared. 694 An implementation MAY decide not to honor the S-flag in order not 695 to leak Binding TLV's between levels (for policy reasons). In all 696 cases, the D flag MUST always be set by any router leaking the 697 Binding TLV from level-2 into level-1 and MUST be checked when 698 propagating the Binding TLV from level-1 into level-2. If the D 699 flag is set, the Binding TLV MUST NOT be propagated into level-2. 701 Other bits: MUST be zero when originated and ignored when 702 received. 704 2.4.2. Range 706 The 'Range' field provides the ability to specify a range of 707 addresses and their associated Prefix SIDs. This advertisement 708 supports the SRMS functionality. It is essentially a compression 709 scheme to distribute a continuous Prefix and their continuous, 710 corresponding SID/Label Block. If a single SID is advertised then 711 the range field MUST be set to one. For range advertisements > 1, 712 the number of addresses that need to be mapped into a Prefix-SID and 713 the starting value of the Prefix-SID range. 715 Example 1: if the following router addresses (loopback addresses) 716 need to be mapped into the corresponding Prefix SID indexes. 718 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 719 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 720 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 721 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Length |0|0| | RESERVED | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Range = 4 | /32 | 192 | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | .0 | .2 | .1 |Prefix-SID Type| 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | sub-TLV Length| Flags | Algorithm | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | 1 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Example-2: If the following prefixes need to be mapped into the 738 corresponding Prefix-SID indexes: 740 10.1.1/24, Prefix-SID: Index 51 741 10.1.2/24, Prefix-SID: Index 52 742 10.1.3/24, Prefix-SID: Index 53 743 10.1.4/24, Prefix-SID: Index 54 744 10.1.5/24, Prefix-SID: Index 55 745 10.1.6/24, Prefix-SID: Index 56 746 10.1.7/24, Prefix-SID: Index 57 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length |0|0| | RESERVED | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Range = 7 | /24 | 10 | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Flags | Algorithm | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | 51 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 It is not expected that a network operator will be able to keep fully 763 continuous Prefix / SID/Index mappings. In order to support 764 noncontinuous mapping ranges an implementation MAY generate several 765 instances of Binding TLVs. 767 For example if a router wants to advertise the following ranges: 769 Range 16: { 192.0.2.1-15, Index 1-15 } 771 Range 6: { 192.0.2.22-27, Index 22-27 } 773 Range 41: { 192.0.2.44-84, Index 80-120 } 775 A router would need to advertise three instances of the Binding TLV. 777 2.4.3. Prefix Length, Prefix 779 The 'Prefix' represents the Forwarding equivalence class at the tail- 780 end of the advertised path. The 'Prefix' does not need to correspond 781 to a routable prefix of the originating node. 783 The 'Prefix Length' field contains the length of the prefix in bits. 784 Only the most significant octets of the Prefix are encoded. (i.e., 1 785 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 786 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 787 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 789 2.4.4. Mapping Server Prefix-SID 791 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 792 and contains the SID/index/label value associated with the prefix and 793 range. The Prefix-SID SubTLV MUST be present in the SID/Label 794 Binding TLV unless the M-flag is set in the Flags field of the parent 795 TLV. 797 A node receiving a MS entry for a prefix MUST check the existence of 798 such prefix in its link-state database prior to consider and use the 799 associated SID. 801 2.4.4.1. Prefix-SID Flags 803 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 804 MAY advertise a mapping with the N flag set when the prefix being 805 mapped is known in the link-state topology with a mask length of 32 806 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 807 mechanisms through which the operator defines that a prefix 808 represents a node are outside the scope of this document (typically 809 it will be through configuration). 811 The other flags defined in Section 2.1 are not used by the Mapping 812 Server and MUST be ignored at reception. 814 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 816 As the mapping server does not specify the originator of a prefix 817 advertisement it is not possible to determine PHP behavior solely 818 based on the Mapping Server Advertisement. However, if additional 819 information is available PHP behavior may safely be done. The 820 required information consists of: 822 o A prefix reachability advertisement for the prefix has been 823 received which includes the Extended Reachability Attribute Flags 824 sub-TLV ([RFC7794]). 826 o X and R flags are both set to 0 in the Extended Reachability 827 Attribute Flags sub-TLV. 829 In the absence of an Extended Reachability Attribute Flags sub-TLV 830 ([RFC7794]) the A flag in the binding TLV indicates that the 831 originator of a prefix reachability advertisement is directly 832 connected to the prefix and thus PHP MUST be done by the neighbors of 833 the router originating the prefix reachability advertisement. Note 834 that A-flag is only valid in the original area in which the Binding 835 TLV is advertised. 837 2.4.4.3. Prefix-SID Algorithm 839 The algorithm field contains the identifier of the algorithm the 840 router MUST use in order to compute reachability to the range of 841 prefixes. Use of the algorithm field is described in Section 2.1. 843 2.4.5. SID/Label Sub-TLV 845 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 846 SID/Label value as defined in Section 2.3. It MUST be present in the 847 SID/Label Binding TLV when the M-flag is set in the Flags field of 848 the parent TLV. 850 2.5. Multi-Topology SID/Label Binding TLV 852 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 853 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 854 has the same format as the SID/Label Binding TLV defined in 855 Section 2.4 with the difference consisting of a Multitopology 856 Identifier (MTID) as defined here below: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Type | Length | MTID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Flags | RESERVED | Range | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Prefix Length | Prefix (variable) // 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | SubTLVs (variable) | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 Figure 2: Multi-Topology SID/Label Binding TLV format 872 where: 874 Type: TBD, suggested value 150 876 Length: variable 878 MTID is the multitopology identifier defined as: 880 0 1 881 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | RESVD | MTID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 RESVD: reserved bits. MUST be reset on transmission and 887 ignored on receive. 889 MTID: a 12-bit field containing the non-zero ID of the topology 890 being announced. The TLV MUST be ignored if the ID is zero. 891 This is to ensure the consistent view of the standard unicast 892 topology. 894 The other fields and SubTLVs are defined in Section 2.4. 896 3. Router Capabilities 898 This section defines sub-TLVs which are inserted into the IS-IS 899 Router Capability TLV-242 that is defined in [RFC7981]. 901 3.1. SR-Capabilities Sub-TLV 903 Segment Routing requires each router to advertise its SR data-plane 904 capability and the range of MPLS label values it uses for Segment 905 Routing in the case where global SIDs are allocated (i.e., global 906 indexes). Data-plane capabilities and label ranges are advertised 907 using the newly defined SR-Capabilities sub-TLV. 909 The Router Capability TLV specifies flags that control its 910 advertisement. The SR Capabilities sub-TLV MUST be propagated 911 throughout the level and MUST NOT be advertised across level 912 boundaries. Therefore Router Capability TLV distribution flags are 913 set accordingly, i.e., the S flag in the Router Capability TLV 914 ([RFC7981]) MUST be unset. 916 The SR Capabilities sub-TLV has following format: 918 0 1 2 3 919 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Type | Length | Flags | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Range | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 // SID/Label Sub-TLV (variable) // 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Type: TBD, suggested value 2 932 Length: variable. 934 Flags: 1 octet of flags. The following are defined: 936 0 1 2 3 4 5 6 7 937 +-+-+-+-+-+-+-+-+ 938 |I|V| | 939 +-+-+-+-+-+-+-+-+ 941 where: 943 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 944 processing SR MPLS encapsulated IPv4 packets on all interfaces. 946 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 947 processing SR MPLS encapsulated IPv6 packets on all interfaces. 949 One or more SRGB Descriptor entries, each of which have the 950 following format: 952 Range: 3 octets. 954 SID/Label sub-TLV (as defined in Section 2.3). 956 SID/Label sub-TLV contains the first value of the SRGB while the 957 range contains the number of SRGB elements. The range value MUST be 958 higher than 0. 960 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 961 but a router MUST NOT advertise more than one SR-Capabilities sub- 962 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 963 same originator, SHOULD select the first advertisement in the lowest 964 numbered LSP. 966 When multiple SRGB Descriptors are advertised the entries define an 967 ordered set of ranges on which a SID index is to be applied. For 968 this reason changing the order in which the descriptors are 969 advertised will have a disruptive effect on forwarding. 971 When a router adds a new SRGB Descriptor to an existing SR- 972 Capabilities sub-TLV the new Descriptor SHOULD add the newly 973 configured block at the end of the sub-TLV and SHOULD NOT change the 974 order of previously advertised blocks. Changing the order of the 975 advertised descriptors will create label churn in the FIB and 976 blackhole / misdirect some traffic during the IGP convergence. In 977 particular, if a range which is not the last is extended it's 978 preferable to add a new range rather than extending the previously 979 advertised range. 981 The originating router MUST ensure the order is same after a graceful 982 restart (using checkpointing, non-volatile storage or any other 983 mechanism) in order to guarantee the same order before and after GR. 985 The originating router MUST NOT advertise overlapping ranges. 987 When a router receives multiple overlapping ranges, it MUST conform 988 to the procedures defined in [I-D.ietf-spring-conflict-resolution]. 990 Here follows an example of advertisement of multiple ranges: 992 The originating router advertises following ranges: 993 SR-Cap: range: 100, SID value: 100 994 SR-Cap: range: 100, SID value: 1000 995 SR-Cap: range: 100, SID value: 500 997 The receiving routers concatenate the ranges in the received 998 order and build the SRGB as follows: 1000 SRGB = [100, 199] 1001 [1000, 1099] 1002 [500, 599] 1004 The indexes span multiple ranges: 1006 index=0 means label 100 1007 ... 1008 index 99 means label 199 1009 index 100 means label 1000 1010 index 199 means label 1099 1011 ... 1012 index 200 means label 500 1013 ... 1015 3.2. SR-Algorithm Sub-TLV 1017 The router may use various algorithms when calculating reachability 1018 to other nodes or to prefixes attached to these nodes. Examples of 1019 these algorithms are metric based Shortest Path First (SPF), various 1020 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1021 suggested value 19) allows the router to advertise the algorithms 1022 that the router is currently using. The following values have been 1023 defined: 1025 0: Shortest Path First (SPF) algorithm based on link metric. This 1026 is the well-known shortest path algorithm as computed by the IS-IS 1027 Decision process. Consistent with the deployed practice for link- 1028 state protocols, algorithm 0 permits any node to overwrite the SPF 1029 path with a different path based on local policy. 1031 1: Strict Shortest Path First (SPF) algorithm based on link 1032 metric. The algorithm is identical to algorithm 0 but algorithm 1 1033 requires that all nodes along the path will honor the SPF routing 1034 decision. Local policy MUST NOT alter the forwarding decision 1035 computed by algorithm 1 at the node claiming to support algorithm 1036 1. 1038 The Router Capability TLV specifies flags that control its 1039 advertisement. The SR-Algorithm MUST be propagated throughout the 1040 level and MUST NOT be advertised across level boundaries. Therefore 1041 Router Capability TLV distribution flags are set accordingly, i.e., 1042 the S flag MUST be unset. 1044 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1045 time inside the Router Capability TLV. 1047 When the originating router does not advertise the SR-Algorithm sub- 1048 TLV, then all the Prefix-SIDs advertised by the router MUST have 1049 algorithm field set to 0. Any receiving router MUST assume SPF 1050 algorithm (i.e., Shortest Path First). 1052 When the originating router does advertise the SR-Algorithm sub-TLV, 1053 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1055 The SR-Algorithm sub-TLV has following format: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Type | Length | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 where: 1067 Type: TBD, suggested value 19 1069 Length: variable. 1071 Algorithm: 1 octet of algorithm Section 2.1 1073 3.3. SR Local Block Sub-TLV 1075 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1076 node has reserved for local SIDs. Local SIDs are used, e.g., for 1077 Adjacency-SIDs, and may also be allocated by other components than 1078 IS-IS protocol. As an example, an application or a controller may 1079 instruct the router to allocate a specific local SID. Therefore, in 1080 order for such applications or controllers to know what are the local 1081 SIDs available in the router, it is required that the router 1082 advertises its SRLB. 1084 The SRLB Sub-TLV is used for that purpose and has following format: 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Type | Length | Flags | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Range | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 // SID/Label Sub-TLV (variable) // 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Type: TBD, suggested value 22. 1100 Length: variable. 1102 Flags: 1 octet of flags. None are defined at this stage. 1104 One or more SRLB Descriptor entries, each of which have the 1105 following format: 1107 Range: 3 octets. 1109 SID/Label sub-TLV (as defined in Section 2.3). 1111 SID/Label sub-TLV contains the first value of the SRLB while the 1112 range contains the number of SRLB elements. The range value MUST be 1113 higher than 0. 1115 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1116 router MUST NOT advertise more than one SRLB sub-TLV. A router 1117 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1118 select the first advertisement in the lowest numbered LSP. 1120 The originating router MUST NOT advertise overlapping ranges. 1122 It is important to note that each time a SID from the SRLB is 1123 allocated, it SHOULD also be reported to all components (e.g.: 1124 controller or applications) in order for these components to have an 1125 up-to-date view of the current SRLB allocation and in order to avoid 1126 collision between allocation instructions. 1128 Within the context of IS-IS, the reporting of local SIDs is done 1129 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1130 reporting of allocated local SIDs may also be done through other 1131 means and protocols which mechanisms are outside the scope of this 1132 document. 1134 A router advertising the SRLB TLV may also have other label ranges, 1135 outside the SRLB, for its local allocation purposes which are NOT 1136 advertised in the SRLB. For example, it is possible that an 1137 Adjacency-SID is allocated using a local label not part of the SRLB. 1139 3.4. SRMS Preference Sub-TLV 1141 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1142 in order to associate a preference with SRMS advertisements from a 1143 particular source. 1145 The SRMS Preference sub-TLV has following format: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type | Length | Preference | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 Type: TBD, suggested value 24. 1155 Length: 1. 1157 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1159 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1160 but a router MUST NOT advertise more than one SRMS Preference sub- 1161 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1162 same originator, SHOULD select the first advertisement in the lowest 1163 numbered LSP. 1165 The use of the SRMS Preference during the SID selection process is 1166 described in [I-D.ietf-spring-conflict-resolution]. 1168 4. Non backward compatible changes with prior versions of this document 1170 This section describes the changes that have been applied to this 1171 document that are not backward compatible with previous versions. 1173 4.1. Encoding of Multiple SRGBs 1175 Version -04 of this document introduced a change in Section 3.1 1176 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1177 and made the support of multiple SRGBs REQUIRED. 1179 The modified method consists of having a single SR-Cap Sub-TLV where 1180 all SRGBs are encoded. In previous versions (prior to version -04) 1181 of this document it was allowed to have multiple occurrences of the 1182 SR-Cap Sub-TLV. 1184 At the time of writing this document, no existing implementations are 1185 affected by the change since no implementations actually (i.e., at 1186 the time of updating this document) encode multiple SRGBs anyway. 1188 5. IANA Considerations 1190 This documents request allocation for the following TLVs and subTLVs. 1192 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1194 This document makes the following registrations in the "sub-TLVs for 1195 TLV 22, 23, 25, 141, 222 and 223" registry. 1197 Type: TBD (suggested value 31) 1199 Description: Adjacency Segment Identifier 1201 TLV 22: yes 1203 TLV 23: yes 1205 TLV 25: no 1207 TLV 141: yes 1209 TLV 222: yes 1211 TLV 223: yes 1213 Reference: This document (Section 2.2.1) 1215 Type: TBD (suggested value 32) 1217 Description: LAN Adjacency Segment Identifier 1219 TLV 22: yes 1221 TLV 23: yes 1223 TLV 25: no 1224 TLV 141: yes 1226 TLV 222: yes 1228 TLV 223: yes 1230 Reference: This document (Section 2.2.2) 1232 5.2. Sub TLVs for Type 135,235,236 and 237 1234 This document makes the following registrations in the "sub-TLVs for 1235 TLV 135,235,236 and 237" registry. 1237 Type: TBD (suggested value 3) 1239 Description: Prefix Segment Identifier 1241 TLV 135: yes 1243 TLV 235: yes 1245 TLV 236: yes 1247 TLV 237: yes 1249 Reference: This document (Section 2.1) 1251 5.3. Sub TLVs for Type 242 1253 This document makes the following registrations in the "sub-TLVs for 1254 TLV 242" registry. 1256 Type: TBD (suggested value 2) 1258 Description: Segment Routing Capability 1260 Reference: This document (Section 3.1) 1262 Type: TBD (suggested value 19) 1264 Description: Segment Routing Algorithm 1266 Reference: This document (Section 3.2) 1267 Type: TBD (suggested value 22) 1269 Description: Segment Routing Local Block (SRLB) 1271 Reference: This document (Section 3.3) 1273 Type: TBD (suggested value 24) 1275 Description: Segment Routing Mapping Server Preference (SRMS 1276 Preference) 1278 Reference: This document (Section 3.4) 1280 5.4. New TLV Codepoint and Sub-TLV registry 1282 This document registers the following TLV: 1284 Type: TBD (suggested value 149) 1286 name: Segment Identifier / Label Binding 1288 IIH: no 1290 LSP: yes 1292 SNP: no 1294 Purge: no 1296 Reference: This document (Section 2.4) 1298 Type: TBD (suggested value 150) 1300 name: Multi-Topology Segment Identifier / Label Binding 1302 IIH: no 1304 LSP: yes 1306 SNP: no 1308 Purge: no 1310 Reference: This document (Section 2.5) 1312 This document creates the following sub-TLV Registry: 1314 Registry: sub-TLVs for TLV 149 and 150 1316 Registration Procedure: Expert review 1318 Reference: This document (Section 2.4) 1320 Type: TBD, suggested value 1 1322 Description: SID/Label 1324 Reference: This document (Section 2.4.5) 1326 Type: TBD, suggested value 3 1328 Description: Prefix-SID 1330 Reference: This document (Section 2.1) 1332 6. Security Considerations 1334 With the use of the extensions defined in this document, IS-IS 1335 carries information which will be used to program the MPLS data plane 1336 [RFC3031]. In general, the same types of attacks that can be carried 1337 out on the IP/IPv6 control plane can be carried out on the MPLS 1338 control plane resulting in traffic being misrouted in the respective 1339 data planes. However, the latter may be more difficult to detect and 1340 isolate. Existing security extensions as described in [RFC5304] and 1341 [RFC5310] apply to these segment routing extensions. 1343 7. Acknowledgements 1345 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1346 Francois and Jesper Skrivers for their contribution to the content of 1347 this document. 1349 8. Contributors 1351 The following people gave a substantial contribution to the content 1352 of this document and should be considered as co-authors: 1354 Peter Psenak 1355 Cisco Systems Inc. 1356 US 1358 Email: ppsenak@cisco.com 1359 Martin Horneffer 1360 Deutsche Telekom 1361 DE 1363 Email: Martin.Horneffer@telekom.de 1365 Wim Henderickx 1366 Nokia 1367 BE 1369 Email: wim.henderickx@nokia.com 1371 Edward Crabbe 1372 Individual 1373 US 1375 Email: edward.crabbe@gmail.com 1377 Rob Shakir 1378 Google 1379 UK 1381 Email: robjs@google.com 1383 Igor Milojevic 1384 Individual 1385 RS 1387 Email: milojevicigor@gmail.com 1389 Saku Ytti 1390 TDC 1391 FI 1393 Email: saku@ytti.fi 1395 Steven Luong 1396 Cisco Systems Inc. 1397 US 1399 Email: sluong@cisco.com 1401 9. References 1403 9.1. Normative References 1405 [I-D.ietf-spring-conflict-resolution] 1406 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1407 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1408 spring-conflict-resolution-05 (work in progress), July 1409 2017. 1411 [I-D.ietf-spring-segment-routing] 1412 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1413 Litkowski, S., and R. Shakir, "Segment Routing 1414 Architecture", draft-ietf-spring-segment-routing-13 (work 1415 in progress), October 2017. 1417 [ISO10589] 1418 International Organization for Standardization, 1419 "Intermediate system to Intermediate system intra-domain 1420 routeing information exchange protocol for use in 1421 conjunction with the protocol for providing the 1422 connectionless-mode Network Service (ISO 8473)", ISO/ 1423 IEC 10589:2002, Second Edition, Nov 2002. 1425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1426 Requirement Levels", BCP 14, RFC 2119, 1427 DOI 10.17487/RFC2119, March 1997, 1428 . 1430 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1431 Label Switching Architecture", RFC 3031, 1432 DOI 10.17487/RFC3031, January 2001, 1433 . 1435 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1436 Topology (MT) Routing in Intermediate System to 1437 Intermediate Systems (IS-ISs)", RFC 5120, 1438 DOI 10.17487/RFC5120, February 2008, 1439 . 1441 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1442 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1443 2008, . 1445 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1446 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1447 2008, . 1449 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1450 DOI 10.17487/RFC5308, October 2008, 1451 . 1453 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1454 and M. Fanto, "IS-IS Generic Cryptographic 1455 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1456 2009, . 1458 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1459 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1460 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1461 March 2016, . 1463 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1464 for Advertising Router Information", RFC 7981, 1465 DOI 10.17487/RFC7981, October 2016, 1466 . 1468 9.2. Informative References 1470 [I-D.ietf-spring-resiliency-use-cases] 1471 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1472 "Resiliency use cases in SPRING networks", draft-ietf- 1473 spring-resiliency-use-cases-12 (work in progress), 1474 December 2017. 1476 [I-D.ietf-spring-segment-routing-ldp-interop] 1477 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1478 S. Litkowski, "Segment Routing interworking with LDP", 1479 draft-ietf-spring-segment-routing-ldp-interop-09 (work in 1480 progress), September 2017. 1482 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1483 Shand, "Simplified Extension of Link State PDU (LSP) Space 1484 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1485 . 1487 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1488 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1489 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1490 December 2008, . 1492 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1493 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1494 Packet Routing in Networking (SPRING) Problem Statement 1495 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1496 2016, . 1498 Authors' Addresses 1500 Stefano Previdi (editor) 1501 Cisco Systems, Inc. 1502 IT 1504 Email: stefano@previdi.net 1506 Les Ginsberg (editor) 1507 Cisco Systems, Inc. 1508 IT 1510 Email: ginsberg@cisco.com 1512 Clarence Filsfils 1513 Cisco Systems, Inc. 1514 Brussels 1515 BE 1517 Email: cfilsfil@cisco.com 1519 Ahmed Bashandy 1520 Cisco Systems, Inc. 1521 170, West Tasman Drive 1522 San Jose, CA 95134 1523 US 1525 Email: bashandy@cisco.com 1527 Hannes Gredler 1528 RtBrick Inc. 1530 Email: hannes@rtbrick.com 1532 Stephane Litkowski 1533 Orange 1534 FR 1536 Email: stephane.litkowski@orange.com 1537 Bruno Decraene 1538 Orange 1539 FR 1541 Email: bruno.decraene@orange.com 1543 Jeff Tantsura 1544 Individual 1546 Email: jefftant@gmail.com