idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-21.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 3, 2018) is 1965 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 1004 -- Looks like a reference, but probably isn't: '199' on line 1004 -- Looks like a reference, but probably isn't: '1000' on line 1005 -- Looks like a reference, but probably isn't: '1099' on line 1005 -- Looks like a reference, but probably isn't: '500' on line 1006 -- Looks like a reference, but probably isn't: '599' on line 1006 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-26 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets S. Previdi, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track L. Ginsberg, Ed. 5 Expires: June 6, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 A. Bashandy 8 Individual 9 H. Gredler 10 RtBrick Inc. 11 B. Decraene 12 Orange 13 December 3, 2018 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-21 18 Abstract 20 Segment Routing (SR) allows for a flexible definition of end-to-end 21 paths within IGP topologies by encoding paths as sequences of 22 topological sub-paths, called "segments". These segments are 23 advertised by the link-state routing protocols (IS-IS and OSPF). 25 This draft describes the necessary IS-IS extensions that need to be 26 introduced for Segment Routing operating on an MPLS data-plane. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 6, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 72 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 73 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 75 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 9 76 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 77 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 78 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 79 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 80 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 81 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 82 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 83 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 84 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 85 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 86 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 87 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 88 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 89 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 90 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 91 4. Non backward compatible changes with prior versions of this 92 document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 96 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 97 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27 98 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 101 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 104 9.2. Informative References . . . . . . . . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 107 1. Introduction 109 Segment Routing (SR) allows for a flexible definition of end-to-end 110 paths within IGP topologies by encoding paths as sequences of 111 topological sub-paths, called "segments". These segments are 112 advertised by the link-state routing protocols (IS-IS and OSPF). 113 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 114 a node), as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 do not require any additional signaling (other than the regular IGP). 120 For example, when used in MPLS networks, SR paths do not require any 121 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 122 of LSPs established with RSVP or LDP. 124 There are additional segment types, e.g., Binding SID defined in 125 [I-D.ietf-spring-segment-routing]. This draft also defines an 126 advertisement for one type of BindingSID: the Mirror Context segment. 128 This draft describes the necessary IS-IS extensions that need to be 129 introduced for Segment Routing operating on an MPLS data-plane. 131 Segment Routing architecture is described in 132 [I-D.ietf-spring-segment-routing]. 134 Segment Routing use cases are described in [RFC7855]. 136 2. Segment Routing Identifiers 138 Segment Routing architecture ([I-D.ietf-spring-segment-routing]) 139 defines different types of Segment Identifiers (SID). This document 140 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 141 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 143 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 145 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 146 (Prefix-SID sub-TLV). 148 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 149 defined in [I-D.ietf-spring-segment-routing]. The 'Prefix SID' MUST 150 be unique within a given IGP domain (when the L-flag is not set). 151 The 'Prefix SID' MUST carry an index (when the V-flag is not set) 152 that determines the actual SID/label value inside the set of all 153 advertised SID/label ranges of a given router. A receiving router 154 uses the index to determine the actual SID/label value in order to 155 construct forwarding state to a particular destination router. 157 In many use-cases a 'stable transport' IP Address is overloaded as an 158 identifier of a given node. Because the IP Prefixes may be re- 159 advertised into other levels there may be some ambiguity (e.g. 160 Originating router vs. L1L2 router) for which node a particular IP 161 prefix serves as identifier. The Prefix-SID sub-TLV contains the 162 necessary flags to disambiguate IP Prefix to node mappings. 163 Furthermore if a given node has several 'stable transport' IP 164 addresses there are flags to differentiate those among other IP 165 Prefixes advertised from a given node. 167 A Prefix-SID sub-TLV is associated to a prefix advertised by a node 168 and MAY be present in any of the following TLVs: 170 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 172 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 174 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 176 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 178 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 179 and Section 2.5 respectively. 181 When the IP Reachability TLV is propagated across level boundaries, 182 the Prefix-SID sub-TLV SHOULD be kept. 184 The Prefix-SID sub-TLV has the following format: 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | Flags | Algorithm | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SID/Index/Label (variable) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 Type: TBD, suggested value 3 198 Length: variable. 200 Flags: 1 octet field of following flags: 202 0 1 2 3 4 5 6 7 203 +-+-+-+-+-+-+-+-+ 204 |R|N|P|E|V|L| | 205 +-+-+-+-+-+-+-+-+ 207 where: 209 R-Flag: Re-advertisement flag. If set, then the prefix to 210 which this Prefix-SID is attached, has been propagated by the 211 router either from another level (i.e., from level-1 to level-2 212 or the opposite) or from redistribution (e.g.: from another 213 protocol). 215 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 216 the router identified by the prefix. Typically, the N-Flag is 217 set on Prefix-SIDs attached to a router loopback address. The 218 N-Flag is set when the Prefix-SID is a Node-SID as described in 219 [I-D.ietf-spring-segment-routing]. 221 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 222 pop the Prefix-SID before delivering the packet to the node 223 that advertised the Prefix-SID. 225 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 226 the Prefix-SID originator MUST replace the Prefix-SID with a 227 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 228 IPv6) before forwarding the packet. 230 V-Flag: Value flag. If set, then the Prefix-SID carries a 231 value (instead of an index). By default the flag is UNSET. 233 L-Flag: Local Flag. If set, then the value/index carried by 234 the Prefix-SID has local significance. By default the flag is 235 UNSET. 237 Other bits: MUST be zero when originated and ignored when 238 received. 240 Algorithm: the router may use various algorithms when calculating 241 reachability to other nodes or to prefixes attached to these 242 nodes. Algorithms identifiers are defined in Section 3.2. 243 Examples of these algorithms are metric based Shortest Path First 244 (SPF), various sorts of Constrained SPF, etc. The algorithm field 245 of the Prefix-SID contains the identifier of the algorithm the 246 router has used in order to compute the reachability of the prefix 247 to which the Prefix-SID is associated. 249 At origination, the Prefix-SID algorithm field MUST be set to 0 or 250 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). 252 A router receiving a Prefix-SID from a remote node and with an 253 algorithm value that such remote node has not advertised in the 254 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 255 TLV. 257 SID/Index/Label as defined in Section 2.1.1.1. 259 2.1.1. Flags 261 2.1.1.1. V and L Flags 263 The V-flag indicates whether the SID/Index/Label field is a value or 264 an index. 266 The L-Flag indicates whether the value/index in the SID/Index/Label 267 field has local or global significance. 269 The following settings for V and L flags are valid: 271 V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field 272 is a 4 octet index defining the offset in the SID/Label space 273 advertised by this router using the encodings defined in Section 3.1. 275 V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field 276 is a 3 octet local label where the 20 rightmost bits are used for 277 encoding the label value. 279 All other combinations of V-flag and L-flag are invalid and any SID 280 advertisement received with an invalid setting for V and L flags MUST 281 be ignored. 283 2.1.1.2. R and N Flags 285 The R-Flag MUST be set for prefixes that are not local to the router 286 and either: 288 advertised because of propagation (Level-1 into Level-2); 290 advertised because of leaking (Level-2 into Level-1); 292 advertised because of redistribution (e.g.: from another 293 protocol). 295 In the case where a Level-1-2 router has local interface addresses 296 configured in one level, it may also propagate these addresses into 297 the other level. In such case, the Level-1-2 router MUST NOT set the 298 R bit. The R-bit MUST be set only for prefixes that are not local to 299 the router and advertised by the router because of propagation and/or 300 leaking. 302 The N-Flag is used in order to define a Node-SID. A router MAY set 303 the N-Flag only if all of the following conditions are met: 305 The prefix to which the Prefix-SID is attached is local to the 306 router (i.e., the prefix is configured on one of the local 307 interfaces, e.g., a 'stable transport' loopback). 309 The prefix to which the Prefix-SID is attached MUST have a Prefix 310 length of either /32 (IPv4) or /128 (IPv6). 312 The router MUST ignore the N-Flag on a received Prefix-SID if the 313 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 315 [RFC7794] also defines the N and R flags and with the same semantics 316 of the equivalent flags defined in this document. There will be a 317 transition period where both sets of flags will be used and 318 eventually only the flags of the Prefix Attributes will remain. 319 During the transition period implementations supporting the N and R 320 flags defined in this document and the N and R flags defined in 321 [RFC7794] MUST advertise and parse all flags. In case the received 322 flags have different values, the value of the flags defined in 323 [RFC7794] prevails. 325 2.1.1.3. E and P Flags 327 When calculating the outgoing label for the prefix, the router MUST 328 take into account E and P flags advertised by the next-hop router, if 329 next-hop router advertised the SID for the prefix. This MUST be done 330 regardless of next-hop router contributing to the best path to the 331 prefix or not. 333 When propagating (either from Level-1 to Level-2 or vice versa) a 334 reachability advertisement originated by another IS-IS speaker, the 335 router MUST set the P-flag and MUST clear the E-flag of the related 336 Prefix-SIDs. 338 The following behavior is associated with the settings of the E and P 339 flags: 341 o If the P-flag is not set then any upstream neighbor of the Prefix- 342 SID originator MUST pop the Prefix-SID. This is equivalent to the 343 penultimate hop popping mechanism used in the MPLS dataplane which 344 improves performance of the ultimate hop. MPLS EXP bits of the 345 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 346 being removed). If the P-flag is unset the received E-flag is 347 ignored. 349 o If the P-flag is set then: 351 * If the E-flag is not set then any upstream neighbor of the 352 Prefix-SID originator MUST keep the Prefix-SID on top of the 353 stack. This is useful when, e.g., the originator of the 354 Prefix-SID must stitch the incoming packet into a continuing 355 MPLS LSP to the final destination. This could occur at an 356 inter-area border router (prefix propagation from one area to 357 another) or at an inter-domain border router (prefix 358 propagation from one domain to another). 360 * If the E-flag is set then any upstream neighbor of the Prefix- 361 SID originator MUST replace the PrefixSID with a Prefix-SID 362 having an Explicit-NULL value. This is useful, e.g., when the 363 originator of the Prefix-SID is the final destination for the 364 related prefix and the originator wishes to receive the packet 365 with the original EXP bits. 367 2.1.2. Prefix-SID Propagation 369 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 370 gets propagated across level boundaries. 372 The level-1-2 router that propagates the Prefix-SID sub-TLV between 373 levels MUST set the R-flag. 375 If the Prefix-SID contains a global index (L and V flags unset) and 376 it is propagated as such (with L and V flags unset), the value of the 377 index MUST be preserved when propagated between levels. 379 The level-1-2 router that propagates the Prefix-SID sub-TLV between 380 levels MAY change the setting of the L and V flags in case a local 381 label value is encoded in the Prefix-SID instead of the received 382 value. 384 2.2. Adjacency Segment Identifier 386 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 387 TLV (Adj-SID sub-TLV). 389 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 390 Routing IGP-Adjacency-SID as defined in 391 [I-D.ietf-spring-segment-routing] with flags and fields that may be 392 used, in future extensions of Segment Routing, for carrying other 393 types of SIDs. 395 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 396 below: 398 TLV-22 (Extended IS reachability)[RFC5305] 400 TLV-222 (Multitopology IS)[RFC5120] 402 TLV-23 (IS Neighbor Attribute)[RFC5311] 404 TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] 406 TLV-141 (inter-AS reachability information)[RFC5316] 408 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 409 neighbor. 411 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 413 The following format is defined for the Adj-SID sub-TLV: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length | Flags | Weight | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | SID/Label/Index (variable) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 where: 425 Type: TBD, suggested value 31 427 Length: variable. 429 Flags: 1 octet field of following flags: 431 0 1 2 3 4 5 6 7 432 +-+-+-+-+-+-+-+-+ 433 |F|B|V|L|S|P| | 434 +-+-+-+-+-+-+-+-+ 436 where: 438 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 439 to an adjacency with outgoing IPv4 encapsulation. If set then 440 the Adj-SID refers to an adjacency with outgoing IPv6 441 encapsulation. 443 B-Flag: Backup flag. If set, the Adj-SID is eligible for 444 protection (e.g.: using IPFRR or MPLS-FRR) as described in 445 [RFC8355]. 447 V-Flag: Value flag. If set, then the Adj-SID carries a value. 448 By default the flag is SET. 450 L-Flag: Local Flag. If set, then the value/index carried by 451 the Adj-SID has local significance. By default the flag is 452 SET. 454 S-Flag. Set flag. When set, the S-Flag indicates that the 455 Adj-SID refers to a set of adjacencies (and therefore MAY be 456 assigned to other adjacencies as well). 458 P-Flag. Persistent flag. When set, the P-Flag indicates that 459 the Adj-SID is persistently allocated, i.e., the Adj-SID value 460 remains consistent across router restart and/or interface flap. 462 Other bits: MUST be zero when originated and ignored when 463 received. 465 Weight: 1 octet. The value represents the weight of the Adj-SID 466 for the purpose of load balancing. The use of the weight is 467 defined in [I-D.ietf-spring-segment-routing]. 469 SID/Index/Label as defined in Section 2.1.1.1. 471 An SR capable router MAY allocate an Adj-SID for each of its 472 adjacencies and SHOULD set the B-Flag when the adjacency is 473 eligible for protection (IP or MPLS). 475 An SR capable router MAY allocate more than one Adj-SID to an 476 adjacency. 478 An SR capable router MAY allocate the same Adj-SID to different 479 adjacencies. 481 When the P-flag is not set, the Adj-SID MAY be persistent. When 482 the P-flag is set, the Adj-SID MUST be persistent. 484 Examples of use of the Adj-SID sub-TLV are described in 485 [I-D.ietf-spring-segment-routing]. 487 The F-flag is used in order for the router to advertise the 488 outgoing encapsulation of the adjacency the Adj-SID is attached 489 to. 491 2.2.2. Adjacency Segment Identifiers in LANs 493 In LAN subnetworks, the Designated Intermediate System (DIS) is 494 elected and originates the Pseudonode-LSP (PN-LSP) including all 495 neighbors of the DIS. 497 When Segment Routing is used, each router in the LAN MAY advertise 498 the Adj-SID of each of its neighbors. Since, on LANs, each router 499 only advertises one adjacency to the DIS (and doesn't advertise any 500 other adjacency), each router advertises the set of Adj-SIDs (for 501 each of its neighbors) inside a newly defined sub-TLV part of the TLV 502 advertising the adjacency to the DIS (e.g.: TLV-22). 504 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 505 suggested value 32) containing the set of Adj-SIDs the router 506 assigned to each of its LAN neighbors. 508 The format of the LAN-Adj-SID sub-TLV is as follows: 510 0 1 2 3 511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | Flags | Weight | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | System-ID (6 octets) | 518 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | SID/Label/Index (variable) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 where: 528 Type: TBD, suggested value 32 530 Length: variable. 532 Flags: 1 octet field of following flags: 534 0 1 2 3 4 5 6 7 535 +-+-+-+-+-+-+-+-+ 536 |F|B|V|L|S|P| | 537 +-+-+-+-+-+-+-+-+ 539 where F, B, V, L, S and P flags are defined in Section 2.2.1. 540 Other bits: MUST be zero when originated and ignored when 541 received. 543 Weight: 1 octet. The value represents the weight of the Adj-SID 544 for the purpose of load balancing. The use of the weight is 545 defined in [I-D.ietf-spring-segment-routing]. 547 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 548 defined in [ISO10589]. 550 SID/Index/Label as defined in Section 2.1.1.1. 552 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 553 MUST NOT appear in TLV 141. 555 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 556 the P-flag is set, the LAN-Adj-SID MUST be persistent. 558 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 559 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 560 advertisements of the adjacency to the DIS MUST be used and all 561 advertisements MUST have the same metric. 563 Each router within the level, by receiving the DIS PN LSP as well as 564 the non-PN LSP of each router in the LAN, is capable of 565 reconstructing the LAN topology as well as the set of Adj-SID each 566 router uses for each of its neighbors. 568 A label is encoded in 3 octets (in the 20 rightmost bits). 570 An index is encoded in 4 octets. 572 2.3. SID/Label Sub-TLV 574 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 575 defined in this document: 577 SR-Capabilities Sub-TLV (Section 3.1) 579 SR Local Block Sub-TLV (Section 3.3) 581 SID/Label Binding TLV (Section 2.4) 583 Multi-Topology SID/Label Binding TLV (Section 2.5) 585 Note that the code point used in all of the above cases is the SID/ 586 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 587 149 and 150" registry. 589 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 590 sub-TLV has the following format: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | SID/Label (variable) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 where: 602 Type: TBD, suggested value 1 604 Length: variable 605 SID/Label: if length is set to 3 then the 20 rightmost bits 606 represent a MPLS label. 608 2.4. SID/Label Binding TLV 610 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 611 domain. There are multiple uses of the SID/Label Binding TLV. 613 The SID/Label Binding TLV may be used to advertise prefixes to SID/ 614 Label mappings. This functionality is called the Segment Routing 615 Mapping Server (SRMS). The behavior of the SRMS is defined in 616 [I-D.ietf-spring-segment-routing-ldp-interop]. 618 The SID/Label BInding TLV may also be used to advertise a Mirror SID 619 to advertise the ability to process traffic originally destined to 620 another IGP node. This behavior is defined in 621 [I-D.ietf-spring-segment-routing]. 623 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 624 the following format: 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Type | Length | Flags | RESERVED | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Range | Prefix Length | Prefix | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 // Prefix (continued, variable) // 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | SubTLVs (variable) | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 1: SID/Label Binding TLV format 640 o Type: TBD, suggested value 149 642 o Length: variable. 644 o 1 octet of flags 646 o 1 octet of RESERVED 648 o 2 octets of Range 650 o 1 octet of Prefix Length 652 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 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type | Length |0|0| | RESERVED | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Range = 4 | /32 | 192 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | .0 | .2 | .1 |Prefix-SID Type| 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | sub-TLV Length| Flags | Algorithm | | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | 1 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Example-2: If the following prefixes need to be mapped into the 743 corresponding Prefix-SID indexes: 745 10.1.1/24, Prefix-SID: Index 51 746 10.1.2/24, Prefix-SID: Index 52 747 10.1.3/24, Prefix-SID: Index 53 748 10.1.4/24, Prefix-SID: Index 54 749 10.1.5/24, Prefix-SID: Index 55 750 10.1.6/24, Prefix-SID: Index 56 751 10.1.7/24, Prefix-SID: Index 57 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Type | Length |0|0| | RESERVED | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Range = 7 | /24 | 10 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Flags | Algorithm | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 51 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 It is not expected that a network operator will be able to keep fully 768 continuous Prefix / SID/Index mappings. In order to support 769 noncontinuous mapping ranges an implementation MAY generate several 770 instances of Binding TLVs. 772 For example if a router wants to advertise the following ranges: 774 Range 16: { 192.0.2.1-15, Index 1-15 } 776 Range 6: { 192.0.2.22-27, Index 22-27 } 778 Range 41: { 192.0.2.44-84, Index 80-120 } 780 A router would need to advertise three instances of the Binding TLV. 782 2.4.3. Prefix Length, Prefix 784 The 'Prefix' represents the Forwarding equivalence class at the tail- 785 end of the advertised path. The 'Prefix' does not need to correspond 786 to a routable prefix of the originating node. 788 The 'Prefix Length' field contains the length of the prefix in bits. 789 Only the most significant octets of the Prefix are encoded. (i.e., 1 790 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 791 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 792 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 794 2.4.4. Mapping Server Prefix-SID 796 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 797 and contains the SID/index/label value associated with the prefix and 798 range. The Prefix-SID SubTLV MUST be present in the SID/Label 799 Binding TLV unless the M-flag is set in the Flags field of the parent 800 TLV. 802 A node receiving a MS entry for a prefix MUST check the existence of 803 such prefix in its link-state database prior to consider and use the 804 associated SID. 806 2.4.4.1. Prefix-SID Flags 808 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 809 MAY advertise a mapping with the N flag set when the prefix being 810 mapped is known in the link-state topology with a mask length of 32 811 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 812 mechanisms through which the operator defines that a prefix 813 represents a node are outside the scope of this document (typically 814 it will be through configuration). 816 The other flags defined in Section 2.1 are not used by the Mapping 817 Server and MUST be ignored at reception. 819 2.4.4.2. PHP Behavior when using Mapping Server Advertisements 821 As the mapping server does not specify the originator of a prefix 822 advertisement it is not possible to determine PHP behavior solely 823 based on the Mapping Server Advertisement. However, if additional 824 information is available PHP behavior may safely be done. The 825 required information consists of: 827 o A prefix reachability advertisement for the prefix has been 828 received which includes the Extended Reachability Attribute Flags 829 sub-TLV ([RFC7794]). 831 o X and R flags are both set to 0 in the Extended Reachability 832 Attribute Flags sub-TLV. 834 In the absence of an Extended Reachability Attribute Flags sub-TLV 835 ([RFC7794]) the A flag in the binding TLV indicates that the 836 originator of a prefix reachability advertisement is directly 837 connected to the prefix and thus PHP MUST be done by the neighbors of 838 the router originating the prefix reachability advertisement. Note 839 that A-flag is only valid in the original area in which the Binding 840 TLV is advertised. 842 2.4.4.3. Prefix-SID Algorithm 844 The algorithm field contains the identifier of the algorithm the 845 router MUST use in order to compute reachability to the range of 846 prefixes. Use of the algorithm field is described in Section 2.1. 848 2.4.5. SID/Label Sub-TLV 850 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 851 SID/Label value as defined in Section 2.3. It MUST be present in the 852 SID/Label Binding TLV when the M-flag is set in the Flags field of 853 the parent TLV. 855 2.5. Multi-Topology SID/Label Binding TLV 857 The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS 858 as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV 859 has the same format as the SID/Label Binding TLV defined in 860 Section 2.4 with the difference consisting of a Multitopology 861 Identifier (MTID) as defined here below: 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Type | Length | MTID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Flags | RESERVED | Range | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Prefix Length | Prefix (variable) // 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | SubTLVs (variable) | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Figure 2: Multi-Topology SID/Label Binding TLV format 877 where: 879 Type: TBD, suggested value 150 881 Length: variable 883 MTID is the multitopology identifier defined as: 885 0 1 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | RESVD | MTID | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 RESVD: reserved bits. MUST be reset on transmission and 891 ignored on receive. 893 MTID: a 12-bit field containing the non-zero ID of the topology 894 being announced. The TLV MUST be ignored if the ID is zero. 895 This is to ensure the consistent view of the standard unicast 896 topology. 898 The other fields and SubTLVs are defined in Section 2.4. 900 3. Router Capabilities 902 This section defines sub-TLVs which are inserted into the IS-IS 903 Router Capability TLV-242 that is defined in [RFC7981]. 905 3.1. SR-Capabilities Sub-TLV 907 Segment Routing requires each router to advertise its SR data-plane 908 capability and the range of MPLS label values it uses for Segment 909 Routing in the case where global SIDs are allocated (i.e., global 910 indexes). Data-plane capabilities and label ranges are advertised 911 using the newly defined SR-Capabilities sub-TLV. 913 The Router Capability TLV specifies flags that control its 914 advertisement. The SR Capabilities sub-TLV MUST be propagated 915 throughout the level and MUST NOT be advertised across level 916 boundaries. Therefore Router Capability TLV distribution flags are 917 set accordingly, i.e., the S flag in the Router Capability TLV 918 ([RFC7981]) MUST be unset. 920 The SR Capabilities sub-TLV has following format: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Length | Flags | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Range | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 // SID/Label Sub-TLV (variable) // 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Type: TBD, suggested value 2 936 Length: variable. 938 Flags: 1 octet of flags. The following are defined: 940 0 1 2 3 4 5 6 7 941 +-+-+-+-+-+-+-+-+ 942 |I|V| | 943 +-+-+-+-+-+-+-+-+ 945 where: 947 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 948 processing SR MPLS encapsulated IPv4 packets on all interfaces. 950 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 951 processing SR MPLS encapsulated IPv6 packets on all interfaces. 953 One or more SRGB Descriptor entries, each of which have the 954 following format: 956 Range: 3 octets. 958 SID/Label sub-TLV (as defined in Section 2.3). 960 SID/Label sub-TLV contains the first value of the SRGB while the 961 range contains the number of SRGB elements. The range value MUST be 962 higher than 0. 964 The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number 965 but a router MUST NOT advertise more than one SR-Capabilities sub- 966 TLV. A router receiving multiple SR-Capabilities sub-TLVs, from the 967 same originator, SHOULD select the first advertisement in the lowest 968 numbered LSP. 970 When multiple SRGB Descriptors are advertised the entries define an 971 ordered set of ranges on which a SID index is to be applied. For 972 this reason changing the order in which the descriptors are 973 advertised will have a disruptive effect on forwarding. 975 When a router adds a new SRGB Descriptor to an existing SR- 976 Capabilities sub-TLV the new Descriptor SHOULD add the newly 977 configured block at the end of the sub-TLV and SHOULD NOT change the 978 order of previously advertised blocks. Changing the order of the 979 advertised descriptors will create label churn in the FIB and 980 blackhole / misdirect some traffic during the IGP convergence. In 981 particular, if a range which is not the last is extended it's 982 preferable to add a new range rather than extending the previously 983 advertised range. 985 The originating router MUST ensure the order is same after a graceful 986 restart (using checkpointing, non-volatile storage or any other 987 mechanism) in order to guarantee the same order before and after GR. 989 The originating router MUST NOT advertise overlapping ranges. 991 When a router receives multiple overlapping ranges, it MUST conform 992 to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. 994 Here follows an example of advertisement of multiple ranges: 996 The originating router advertises following ranges: 997 SR-Cap: range: 100, SID value: 100 998 SR-Cap: range: 100, SID value: 1000 999 SR-Cap: range: 100, SID value: 500 1001 The receiving routers concatenate the ranges in the received 1002 order and build the SRGB as follows: 1004 SRGB = [100, 199] 1005 [1000, 1099] 1006 [500, 599] 1008 The indexes span multiple ranges: 1010 index=0 means label 100 1011 ... 1012 index 99 means label 199 1013 index 100 means label 1000 1014 index 199 means label 1099 1015 ... 1016 index 200 means label 500 1017 ... 1019 3.2. SR-Algorithm Sub-TLV 1021 The router may use various algorithms when calculating reachability 1022 to other nodes or to prefixes attached to these nodes. Examples of 1023 these algorithms are metric based Shortest Path First (SPF), various 1024 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1025 suggested value 19) allows the router to advertise the algorithms 1026 that the router is currently using. Algorithm values are defined in 1027 the "IGP Algorithm Type" registry defined in 1028 [I-D.ietf-ospf-segment-routing-extensions]. The following values 1029 have been defined: 1031 0: Shortest Path First (SPF) algorithm based on link metric. This 1032 is the well-known shortest path algorithm as computed by the IS-IS 1033 Decision process. Consistent with the deployed practice for link- 1034 state protocols, algorithm 0 permits any node to overwrite the SPF 1035 path with a different path based on local policy. 1037 1: Strict Shortest Path First (SPF) algorithm based on link 1038 metric. The algorithm is identical to algorithm 0 but algorithm 1 1039 requires that all nodes along the path will honor the SPF routing 1040 decision. Local policy MUST NOT alter the forwarding decision 1041 computed by algorithm 1 at the node claiming to support algorithm 1042 1. 1044 The Router Capability TLV specifies flags that control its 1045 advertisement. The SR-Algorithm MUST be propagated throughout the 1046 level and MUST NOT be advertised across level boundaries. Therefore 1047 Router Capability TLV distribution flags are set accordingly, i.e., 1048 the S flag MUST be unset. 1050 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1051 time inside the Router Capability TLV. 1053 When the originating router does not advertise the SR-Algorithm sub- 1054 TLV, then all the Prefix-SIDs advertised by the router MUST have 1055 algorithm field set to 0. Any receiving router MUST assume SPF 1056 algorithm (i.e., Shortest Path First). 1058 When the originating router does advertise the SR-Algorithm sub-TLV, 1059 then algorithm 0 MUST be present while algorithm 1 MAY be present. 1061 The SR-Algorithm sub-TLV has following format: 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type | Length | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 where: 1073 Type: TBD, suggested value 19 1075 Length: variable. 1077 Algorithm: 1 octet of algorithm Section 2.1 1079 3.3. SR Local Block Sub-TLV 1081 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1082 node has reserved for local SIDs. Local SIDs are used, e.g., for 1083 Adjacency-SIDs, and may also be allocated by other components than 1084 IS-IS protocol. As an example, an application or a controller may 1085 instruct the router to allocate a specific local SID. Therefore, in 1086 order for such applications or controllers to know what are the local 1087 SIDs available in the router, it is required that the router 1088 advertises its SRLB. 1090 The SRLB Sub-TLV is used for that purpose and has following format: 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Flags | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Range | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 // SID/Label Sub-TLV (variable) // 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Type: TBD, suggested value 22. 1106 Length: variable. 1108 Flags: 1 octet of flags. None are defined at this stage. 1110 One or more SRLB Descriptor entries, each of which have the 1111 following format: 1113 Range: 3 octets. 1115 SID/Label sub-TLV (as defined in Section 2.3). 1117 SID/Label sub-TLV contains the first value of the SRLB while the 1118 range contains the number of SRLB elements. The range value MUST be 1119 higher than 0. 1121 The SRLB sub-TLV MAY be advertised in an LSP of any number but a 1122 router MUST NOT advertise more than one SRLB sub-TLV. A router 1123 receiving multiple SRLB sub-TLVs, from the same originator, SHOULD 1124 select the first advertisement in the lowest numbered LSP. 1126 The originating router MUST NOT advertise overlapping ranges. 1128 It is important to note that each time a SID from the SRLB is 1129 allocated, it SHOULD also be reported to all components (e.g.: 1130 controller or applications) in order for these components to have an 1131 up-to-date view of the current SRLB allocation and in order to avoid 1132 collision between allocation instructions. 1134 Within the context of IS-IS, the reporting of local SIDs is done 1135 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1136 reporting of allocated local SIDs may also be done through other 1137 means and protocols which mechanisms are outside the scope of this 1138 document. 1140 A router advertising the SRLB TLV may also have other label ranges, 1141 outside the SRLB, for its local allocation purposes which are NOT 1142 advertised in the SRLB. For example, it is possible that an 1143 Adjacency-SID is allocated using a local label not part of the SRLB. 1145 3.4. SRMS Preference Sub-TLV 1147 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 1148 in order to associate a preference with SRMS advertisements from a 1149 particular source. 1151 The SRMS Preference sub-TLV has following format: 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Type | Length | Preference | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Type: TBD, suggested value 24. 1161 Length: 1. 1163 Preference: 1 octet. Unsigned 8 bit SRMS preference. 1165 The SRMS Preference sub-TLV MAY be advertised in an LSP of any number 1166 but a router MUST NOT advertise more than one SRMS Preference sub- 1167 TLV. A router receiving multiple SRMS Preference sub-TLVs, from the 1168 same originator, SHOULD select the first advertisement in the lowest 1169 numbered LSP. 1171 The use of the SRMS Preference during the SID selection process is 1172 described in [I-D.ietf-spring-segment-routing-ldp-interop] 1174 4. Non backward compatible changes with prior versions of this document 1176 This section describes the changes that have been applied to this 1177 document that are not backward compatible with previous versions. 1179 4.1. Encoding of Multiple SRGBs 1181 Version -04 of this document introduced a change in Section 3.1 1182 regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV 1183 and made the support of multiple SRGBs REQUIRED. 1185 The modified method consists of having a single SR-Cap Sub-TLV where 1186 all SRGBs are encoded. In previous versions (prior to version -04) 1187 of this document it was allowed to have multiple occurrences of the 1188 SR-Cap Sub-TLV. 1190 At the time of writing this document, no existing implementations are 1191 affected by the change since no implementations actually (i.e., at 1192 the time of updating this document) encode multiple SRGBs anyway. 1194 5. IANA Considerations 1196 This documents request allocation for the following TLVs and subTLVs. 1198 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 1200 This document makes the following registrations in the "sub-TLVs for 1201 TLV 22, 23, 25, 141, 222 and 223" registry. 1203 Type: TBD (suggested value 31) 1205 Description: Adjacency Segment Identifier 1207 TLV 22: yes 1209 TLV 23: yes 1211 TLV 25: no 1213 TLV 141: yes 1215 TLV 222: yes 1217 TLV 223: yes 1219 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 1230 TLV 141: yes 1232 TLV 222: yes 1234 TLV 223: yes 1236 Reference: This document (Section 2.2.2) 1238 5.2. Sub TLVs for Type 135,235,236 and 237 1240 This document makes the following registrations in the "sub-TLVs for 1241 TLV 135,235,236 and 237" registry. 1243 Type: TBD (suggested value 3) 1245 Description: Prefix Segment Identifier 1247 TLV 135: yes 1249 TLV 235: yes 1251 TLV 236: yes 1253 TLV 237: yes 1255 Reference: This document (Section 2.1) 1257 5.3. Sub TLVs for Type 242 1259 This document makes the following registrations in the "sub-TLVs for 1260 TLV 242" registry. 1262 Type: TBD (suggested value 2) 1264 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) 1273 Type: TBD (suggested value 22) 1275 Description: Segment Routing Local Block (SRLB) 1277 Reference: This document (Section 3.3) 1279 Type: TBD (suggested value 24) 1281 Description: Segment Routing Mapping Server Preference (SRMS 1282 Preference) 1284 Reference: This document (Section 3.4) 1286 5.4. New TLV Codepoint and Sub-TLV registry 1288 This document registers the following TLV: 1290 Type: TBD (suggested value 149) 1292 name: Segment Identifier / Label Binding 1294 IIH: no 1296 LSP: yes 1298 SNP: no 1300 Purge: no 1302 Reference: This document (Section 2.4) 1304 Type: TBD (suggested value 150) 1306 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 Stephane Litkowski 1360 Orange 1361 FR 1363 Email: stephane.litkowski@orange.com 1365 Jeff Tantsura 1366 Apstra, Inc. 1368 Email: jefftant@gmail.com 1370 Peter Psenak 1371 Cisco Systems Inc. 1372 US 1374 Email: ppsenak@cisco.com 1376 Martin Horneffer 1377 Deutsche Telekom 1378 DE 1380 Email: Martin.Horneffer@telekom.de 1382 Wim Henderickx 1383 Nokia 1384 BE 1386 Email: wim.henderickx@nokia.com 1388 Edward Crabbe 1389 Oracle 1390 US 1392 Email: edward.crabbe@oracle.com 1394 Rob Shakir 1395 Google 1396 UK 1398 Email: robjs@google.com 1399 Igor Milojevic 1400 Individual 1401 RS 1403 Email: milojevicigor@gmail.com 1405 Saku Ytti 1406 TDC 1407 FI 1409 Email: saku@ytti.fi 1411 Steven Luong 1412 Cisco Systems Inc. 1413 US 1415 Email: sluong@cisco.com 1417 9. References 1419 9.1. Normative References 1421 [I-D.ietf-ospf-segment-routing-extensions] 1422 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1423 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1424 Extensions for Segment Routing", draft-ietf-ospf-segment- 1425 routing-extensions-26 (work in progress), November 2018. 1427 [I-D.ietf-spring-segment-routing] 1428 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1429 Litkowski, S., and R. Shakir, "Segment Routing 1430 Architecture", draft-ietf-spring-segment-routing-15 (work 1431 in progress), January 2018. 1433 [I-D.ietf-spring-segment-routing-ldp-interop] 1434 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 1435 S. Litkowski, "Segment Routing interworking with LDP", 1436 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 1437 progress), September 2018. 1439 [I-D.ietf-spring-segment-routing-mpls] 1440 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1441 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1442 data plane", draft-ietf-spring-segment-routing-mpls-16 1443 (work in progress), November 2018. 1445 [ISO10589] 1446 International Organization for Standardization, 1447 "Intermediate system to Intermediate system intra-domain 1448 routeing information exchange protocol for use in 1449 conjunction with the protocol for providing the 1450 connectionless-mode Network Service (ISO 8473)", ISO/ 1451 IEC 10589:2002, Second Edition, Nov 2002. 1453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1454 Requirement Levels", BCP 14, RFC 2119, 1455 DOI 10.17487/RFC2119, March 1997, 1456 . 1458 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1459 Label Switching Architecture", RFC 3031, 1460 DOI 10.17487/RFC3031, January 2001, 1461 . 1463 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1464 Topology (MT) Routing in Intermediate System to 1465 Intermediate Systems (IS-ISs)", RFC 5120, 1466 DOI 10.17487/RFC5120, February 2008, 1467 . 1469 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1470 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1471 2008, . 1473 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1474 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1475 2008, . 1477 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1478 DOI 10.17487/RFC5308, October 2008, 1479 . 1481 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1482 and M. Fanto, "IS-IS Generic Cryptographic 1483 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1484 2009, . 1486 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1487 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1488 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1489 March 2016, . 1491 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1492 for Advertising Router Information", RFC 7981, 1493 DOI 10.17487/RFC7981, October 2016, 1494 . 1496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1498 May 2017, . 1500 9.2. Informative References 1502 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1503 Shand, "Simplified Extension of Link State PDU (LSP) Space 1504 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1505 . 1507 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1508 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1509 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1510 December 2008, . 1512 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1513 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1514 Packet Routing in Networking (SPRING) Problem Statement 1515 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1516 2016, . 1518 [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. 1519 Shakir, "Resiliency Use Cases in Source Packet Routing in 1520 Networking (SPRING) Networks", RFC 8355, 1521 DOI 10.17487/RFC8355, March 2018, 1522 . 1524 Authors' Addresses 1526 Stefano Previdi (editor) 1527 Huawei 1528 IT 1530 Email: stefano@previdi.net 1532 Les Ginsberg (editor) 1533 Cisco Systems, Inc. 1534 IT 1536 Email: ginsberg@cisco.com 1537 Clarence Filsfils 1538 Cisco Systems, Inc. 1539 Brussels 1540 BE 1542 Email: cfilsfil@cisco.com 1544 Ahmed Bashandy 1545 Individual 1547 Email: abashandy.ietf@gmail.com 1549 Hannes Gredler 1550 RtBrick Inc. 1552 Email: hannes@rtbrick.com 1554 Bruno Decraene 1555 Orange 1556 FR 1558 Email: bruno.decraene@orange.com