idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-03.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 (October 25, 2014) is 3470 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 1182 -- Looks like a reference, but probably isn't: '199' on line 1182 -- Looks like a reference, but probably isn't: '1000' on line 1183 -- Looks like a reference, but probably isn't: '1099' on line 1183 -- Looks like a reference, but probably isn't: '500' on line 1184 -- Looks like a reference, but probably isn't: '599' on line 1184 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 C. Filsfils 4 Intended status: Standards Track A. Bashandy 5 Expires: April 28, 2015 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 B. Decraene 10 Orange 11 J. Tantsura 12 Ericsson 13 October 25, 2014 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-03 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. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 28, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 69 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 70 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 72 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 73 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 74 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 75 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 76 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 77 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 78 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 16 79 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 80 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 81 2.4.5. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 82 2.4.6. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 18 83 2.4.7. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 18 84 2.4.8. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 19 85 2.4.9. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 19 86 2.4.10. Unnumbered Interface ID ERO subTLV . . . . . . . . . 20 87 2.4.11. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 21 88 2.4.12. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 21 89 2.4.13. Unnumbered Interface ID Backup ERO subTLV . . . . . . 22 90 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path 91 semantics . . . . . . . . . . . . . . . . . . . . . . 23 92 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 23 93 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 23 94 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 26 95 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 4.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 27 97 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 98 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 99 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 100 5. Manageability Considerations . . . . . . . . . . . . . . . . 30 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 102 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 106 9.2. Informative References . . . . . . . . . . . . . . . . . 32 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 109 1. Introduction 111 Segment Routing (SR) allows for a flexible definition of end-to-end 112 paths within IGP topologies by encoding paths as sequences of 113 topological sub-paths, called "segments". These segments are 114 advertised by the link-state routing protocols (IS-IS and OSPF). Two 115 types of segments are defined, Prefix segments and Adjacency 116 segments. Prefix segments represent an ecmp-aware shortest-path to a 117 prefix, as per the state of the IGP topology. Adjacency segments 118 represent a hop over a specific adjacency between two nodes in the 119 IGP. A prefix segment is typically a multi-hop path while an 120 adjacency segment, in most of the cases, is a one-hop path. SR's 121 control-plane can be applied to both IPv6 and MPLS data-planes, and 122 do not require any additional signaling (other than the regular IGP). 123 For example, when used in MPLS networks, SR paths do not require any 124 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 125 of LSPs established with RSVP or LDP. 127 This draft describes the necessary IS-IS extensions that need to be 128 introduced for Segment Routing. 130 Segment Routing architecture is described in 131 [I-D.filsfils-spring-segment-routing]. 133 Segment Routing use cases are described in 134 [I-D.filsfils-spring-segment-routing-use-cases]. 136 2. Segment Routing Identifiers 138 Segment Routing architecture ([I-D.filsfils-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.filsfils-spring-segment-routing]. The 'Prefix SID' 150 MUST be unique within a given IGP domain (when the L-flag is not 151 set). The 'Prefix SID' MUST carry an index (when the V-flag is not 152 set) 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 (IPv4) defined in [RFC5305]. 172 TLV-235 (MT-IPv4) defined in [RFC5120]. 174 TLV-236 (IPv6) defined in [RFC5308]. 176 TLV-237 (MT-IPv6) defined in [RFC5120]. 178 Binding-TLV defined in Section 2.4. 180 When the IP Reachability TLV is propagated across level boundaries, 181 the Prefix-SID sub-TLV SHOULD be kept. 183 The Prefix-SID sub-TLV has the following format: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Flags | Algorithm | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SID/Index/Label (variable) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 where: 195 Type: TBD, suggested value 3 197 Length: variable. 199 Flags: 1 octet field of following flags: 201 0 1 2 3 4 5 6 7 202 +-+-+-+-+-+-+-+-+ 203 |R|N|P|E|V|L| | 204 +-+-+-+-+-+-+-+-+ 206 where: 208 R-Flag: Re-advertisement flag. If set, then the prefix to 209 which this Prefix-SID is attached, has been propagated by the 210 router either from another level (i.e.: from level-1 to level-2 211 or the opposite) or from redistribution (e.g.: from another 212 protocol). 214 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 215 the router identified by the prefix. Typically, the N-Flag is 216 set on Prefix-SIDs attached to a router loopback address. The 217 N-Flag is set when the Prefix-SID is a Node-SID as described in 218 [I-D.filsfils-spring-segment-routing]. 220 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 221 pop the Prefix-SID before delivering the packet to the node 222 that advertised the Prefix-SID. 224 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 225 the Prefix-SID originator MUST replace the Prefix-SID with a 226 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 227 IPv6) before forwarding the packet. 229 V-Flag: Value flag. If set, then the Prefix-SID carries a 230 value (instead of an index). By default the flag is UNSET. 232 L-Flag: Local Flag. If set, then the value/index carried by 233 the Prefix-SID has local significance. By default the flag is 234 UNSET. 236 Other bits: MUST be zero when originated and ignored when 237 received. 239 Algorithm: the router may use various algorithms when calculating 240 reachability to other nodes or to prefixes attached to these 241 nodes. Algorithms identifiers are defined in Section 3.2. 242 Examples of these algorithms are metric based Shortest Path First 243 (SPF), various sorts of Constrained SPF, etc. The algorithm field 244 of the Prefix-SID contains the identifier of the algorithm the 245 router has used in order to compute the reachability of the prefix 246 the Prefix-SID is associated to. 248 At origination, the Prefix-SID algorithm field MUST be set to 0 on 249 all Prefix-SID of prefixes computed using SPF algorithm (Shortest 250 Path First). On reception of the Prefix-SID sub-TLV, any non-zero 251 algorithm value MUST match what advertised in the SR-Algorithm 252 sub-TLV (Section 3.2). 254 A router receiving a Prefix-SID from a remote node and with an 255 algorithm value that such remote node has not advertised in the 256 SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- 257 TLV. 259 SID/Index/Label: according to the V and L flags, it contains 260 either: 262 * A 4 octet index defining the offset in the SID/Label space 263 advertised by this router using the encodings defined in 264 Section 3.1. In this case the V and L flags MUST be unset. 266 * A 3 octet local label where the 20 rightmost bits are used for 267 encoding the label value. In this case the V and L flags MUST 268 be set. 270 2.1.1. Flags 272 2.1.1.1. R and N Flags 274 The R-Flag MUST be set for prefixes that are not local to the router 275 and either: 277 advertised because of propagation (Level-1 into Level-2); 279 advertised because of leaking (Level-2 into Level-1); 280 advertised because of redistribution (e.g.: from another 281 protocol). 283 In the case where a Level-1-2 router has local interface addresses 284 configured in one level, it may also propagate these addresses into 285 the other level. In such case, the Level-1-2 router MUST NOT set the 286 R bit. The R-bit MUST be set only for prefixes that are not local to 287 the router and advertised by the router because of propagation and/or 288 leaking. 290 The N-Flag is used in order to define a Node-SID. A router MAY set 291 the N-Flag only if all of the following conditions are met: 293 The prefix to which the Prefix-SID is attached is local to the 294 router. I.e.: the prefix is configured on one of the local 295 interfaces. (e.g.: 'stable transport' loopback). 297 The prefix to which the Prefix-SID is attached MUST have a Prefix 298 length of either /32 (IPv4) or /128 (IPv6). 300 The router MUST ignore the N-Flag on a received Prefix-SID if the 301 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 303 2.1.1.2. E and P Flags 305 When calculating the outgoing label for the prefix, the router MUST 306 take into account E and P flags advertised by the next-hop router, if 307 next-hop router advertised the SID for the prefix. This MUST be done 308 regardless of next-hop router contributing to the best path to the 309 prefix or not. 311 When propagating (either from Level-1 to Level-2 or vice versa) a 312 reachability advertisement originated by another IS-IS speaker, the 313 router MUST set the P-flag and MUST clear the E-flag of the related 314 Prefix-SIDs. 316 The following behavior is associated with the settings of the E and P 317 flags: 319 o If the P-flag is not set then any upstream neighbor of the Prefix- 320 SID originator MUST pop the Prefix-SID. This is equivalent to the 321 penultimate hop popping mechanism used in the MPLS dataplane which 322 improves performance of the ultimate hop. MPLS EXP bits of the 323 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 324 being removed). If the P-flag is unset the received E-flag is 325 ignored. 327 o If the P-flag is set then: 329 * If the E-flag is not set then any upstream neighbor of the 330 Prefix-SID originator MUST keep the Prefix-SID on top of the 331 stack. This is useful when, e.g., the originator of the 332 Prefix-SID must stitch the incoming packet into a continuing 333 MPLS LSP to the final destination. This could occur at an 334 inter-area border router (prefix propagation from one area to 335 another) or at an inter-domain border router (prefix 336 propagation from one domain to another). 338 * If the E-flag is set then any upstream neighbor of the Prefix- 339 SID originator MUST replace the PrefixSID with a Prefix-SID 340 having an Explicit-NULL value. This is useful, e.g., when the 341 originator of the Prefix-SID is the final destination for the 342 related prefix and the originator wishes to receive the packet 343 with the original EXP bits. 345 2.1.2. Prefix-SID Propagation 347 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 348 gets propagated across level boundaries. 350 The level-1-2 router that propagates the Prefix-SID sub-TLV between 351 levels MUST set the R-flag. 353 If the Prefix-SID contains a global index (L and V flags unset) and 354 it is propagated as such (with L and V flags unset), the value of the 355 index MUST be preserved when propagated between levels. 357 The level-1-2 router that propagates the Prefix-SID sub-TLV between 358 levels MAY change the setting of the L and V flags in case a local 359 label value is encoded in the Prefix-SID instead of the received 360 value. 362 2.2. Adjacency Segment Identifier 364 A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- 365 TLV (Adj-SID sub-TLV). 367 The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment 368 Routing IGP-Adjacency-SID as defined in 369 [I-D.filsfils-spring-segment-routing] with flags and fields that may 370 be used, in future extensions of Segment Routing, for carrying other 371 types of SIDs. 373 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 374 below: 376 TLV-22 [RFC5305] 377 TLV-222 [RFC5120] 379 TLV-23 [RFC5311] 381 TLV-223 [RFC5311] 383 TLV-141 [RFC5316] 385 Multiple Adj-SID sub-TLVs MAY be associated with a single IS- 386 neighbor. Examples where more than one Adj-SID may be used per IS- 387 neighbor are described in 388 [I-D.filsfils-spring-segment-routing-use-cases]. 390 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 392 The following format is defined for the Adj-SID sub-TLV: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | Flags | Weight | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | SID/Label/Index (variable) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 where: 404 Type: TBD, suggested value 31 406 Length: variable. 408 Flags: 1 octet field of following flags: 410 0 1 2 3 4 5 6 7 411 +-+-+-+-+-+-+-+-+ 412 |F|B|V|L|S| | 413 +-+-+-+-+-+-+-+-+ 415 where: 417 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 418 to an adjacency with outgoing IPv4 encapsulation. If set then 419 the Adj-SID refers to an adjacency with outgoing IPv6 420 encapsulation. 422 B-Flag: Backup flag. If set, the Adj-SID refers to an 423 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 424 described in [I-D.filsfils-spring-segment-routing-use-cases]. 426 V-Flag: Value flag. If set, then the Adj-SID carries a value. 427 By default the flag is SET. 429 L-Flag: Local Flag. If set, then the value/index carried by 430 the Adj-SID has local significance. By default the flag is 431 SET. 433 S-Flag. Set Flag. When set, the S-Flag indicates that the 434 Adj-SID refers to a set of adjacencies (and therefore MAY be 435 assigned to other adjacencies as well). 437 Other bits: MUST be zero when originated and ignored when 438 received. 440 Weight: 1 octet. The value represents the weight of the Adj-SID 441 for the purpose of load balancing. The use of the weight is 442 defined in [I-D.filsfils-spring-segment-routing]. 444 SID/Index/Label: according to the V and L flags, it contains 445 either: 447 * A 3 octet local label where the 20 rightmost bits are used for 448 encoding the label value. In this case the V and L flags MUST 449 be set. 451 * A 4 octet index defining the offset in the SID/Label space 452 advertised by this router using the encodings defined in 453 Section 3.1. In this case V and L flags MUST be unset. 455 * A 16 octet IPv6 address. In this case the V flag MUST be set. 456 The L flag MUST be unset if the IPv6 address is globally 457 unique. 459 An SR capable router MAY allocate an Adj-SID for each of its 460 adjacencies and SHOULD set the B-Flag when the adjacency is 461 protected by a FRR mechanism (IP or MPLS) as described in 462 [I-D.filsfils-spring-segment-routing-use-cases]. 464 An SR capable router MAY allocate more than one Adj-SID to an 465 adjacency. 467 An SR capable router MAY allocate the same Adj-SID to different 468 adjacencies. 470 Examples of use of the Adj-SID sub-TLV are described in 471 [I-D.filsfils-spring-segment-routing]. and 472 [I-D.previdi-6man-segment-routing-header]. 474 The F-flag is used in order for the router to advertise the 475 outgoing encapsulation of the adjacency the Adj-SID is attached 476 to. Use cases of the use of the F-flag are described in 477 [I-D.filsfils-spring-segment-routing-use-cases]. 479 2.2.2. Adjacency Segment Identifiers in LANs 481 In LAN subnetworks, the Designated Intermediate System (DIS) is 482 elected and originates the Pseudonode-LSP (PN-LSP) including all 483 neighbors of the DIS. 485 When Segment Routing is used, each router in the LAN MAY advertise 486 the Adj-SID of each of its neighbors. Since, on LANs, each router 487 only advertises one adjacency to the DIS (and doesn't advertise any 488 other adjacency), each router advertises the set of Adj-SIDs (for 489 each of its neighbors) inside a newly defined sub-TLV part of the TLV 490 advertising the adjacency to the DIS (e.g.: TLV-22). 492 The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, 493 suggested value 32) containing the set of Adj-SIDs the router 494 assigned to each of its LAN neighbors. 496 The format of the LAN-Adj-SID sub-TLV is as follows: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | Flags | Weight | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | System-ID (6 octets) | 506 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | SID/Label/Index (variable) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 where: 516 Type: TBD, suggested value 32 518 Length: variable. 520 Flags: 1 octet field of following flags: 522 0 1 2 3 4 5 6 7 523 +-+-+-+-+-+-+-+-+ 524 |F|B|V|L|S| | 525 +-+-+-+-+-+-+-+-+ 527 where F, B, V, L and S flags are defined in Section 2.2.1. Other 528 bits: MUST be zero when originated and ignored when received. 530 Weight: 1 octet. The value represents the weight of the Adj-SID 531 for the purpose of load balancing. The use of the weight is 532 defined in [I-D.filsfils-spring-segment-routing]. 534 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 535 defined in [ISO10589]. 537 SID/Index/Label: according to the V and L flags, it contains 538 either: 540 * A 3 octet local label where the 20 rightmost bits are used for 541 encoding the label value. In this case the V and L flags MUST 542 be set. 544 * A 4 octet index defining the offset in the SID/Label space 545 advertised by this router using the encodings defined in 546 Section 3.1. In this case V and L flags MUST be unset. 548 * A 16 octet IPv6 address. In this case the V flag MUST be set. 549 The L flag MUST be unset if the IPv6 address is globally 550 unique. 552 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 554 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 555 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 556 advertisements of the adjacency to the DIS MUST be used, MUST have 557 the same metric and SHOULD be inserted within the same LSP fragment. 559 Each router within the level, by receiving the DIS PN LSP as well as 560 the non-PN LSP of each router in the LAN, is capable of 561 reconstructing the LAN topology as well as the set of Adj-SID each 562 router uses for each of its neighbors. 564 A label is encoded in 3 octets (in the 20 rightmost bits). 566 An index is encoded in 4 octets. 568 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined 569 in [I-D.previdi-6man-segment-routing-header]). 571 2.3. SID/Label Sub-TLV 573 The SID/Label sub-TLV is present in the following sub-TLVs defined in 574 this document: 576 Binding TLV Section 2.4. 578 SR Capability sub-TLV Section 3.1. 580 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 581 sub-TLV has the following format: 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type | Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | SID/Label (variable) | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 where: 593 Type: TBD, suggested value 1 595 Length: variable 597 SID/Label: if length is set to 3 then the 20 rightmost bits 598 represent a MPLS label. 600 2.4. SID/Label Binding TLV 602 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 603 domain. There are multiple uses of the SID/Label Binding TLV: 605 o The router may advertise a SID/Label binding to a FEC along with 606 at least a single 'nexthop style' anchor. The protocol supports 607 more than one 'nexthop style' anchor to be attached to a SID/Label 608 binding, which results into a simple path description language. 609 In analogy to RSVP the terminology for this is called an 'Explicit 610 Route Object' (ERO). Since ERO style path notation allows to 611 anchor SID/label bindings to both link and node IP addresses any 612 label switched path, can be described. Furthermore also SID/Label 613 Bindings from external protocols can get easily re-advertised. 615 o The SID/Label Binding TLV may be used for advertising SID/Label 616 Bindings and their associated Primary and Backup paths. In one 617 single TLV either a primary ERO Path, a backup ERO Path or both 618 are advertised. If a router wants to advertise multiple parallel 619 paths then it can generate several TLVs for the same Prefix/FEC. 620 Each occurrence of a Binding TLV with respect with a given FEC 621 Prefix has accumulating and not canceling semantics. Due the 622 space constraints in the 8-Bit IS-IS TLVs an originating router 623 MAY encode a primary ERO path in one SID/Label Binding TLV and the 624 backup ERO path in a second SID/Label Binding TLV. Note that the 625 FEC Prefix and SID/Label sub-TLV MUST be identical in both TLVs. 627 o The SID/Label Binding TLV may also be used in order to advertise 628 prefixes to SID/Label mappings. This functionality is called the 629 'Mapping Server' and it's used when, in a heterogeneous network, 630 not all nodes are capable of advertising their own SIDs/Labels. 631 When the SID/Label Binding TLV is used by the Mapping Server in 632 order to advertise prefix to SID/label mappings, the index/label 633 MUST include the Prefix-SID SubTLV (Section 2.1). 635 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 636 the following format: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type | Length | Flags | Weight | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Range | Prefix Length | FEC Prefix | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 // FEC Prefix (continued, variable) // 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | SubTLVs (variable) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 1: SID/Label Binding TLV format 652 o Type: TBD, suggested value 149 654 o Length: variable. 656 o 1 octet of flags 658 o 1 octet of Weight 660 o 2 octets of Range 662 o 1 octet of Prefix Length 664 o 0-16 octets of FEC Prefix 666 o sub-TLVs, where each sub-TLV consists of a sequence of: 668 * 1 octet of sub-TLV type 670 * 1 octet of length of the value field of the sub-TLV 672 * 0-243 octets of value 674 2.4.1. Flags 676 Flags: 1 octet field of following flags: 678 0 1 2 3 4 5 6 7 679 +-+-+-+-+-+-+-+-+ 680 |F|M|S|D|A| | 681 +-+-+-+-+-+-+-+-+ 683 where: 685 F-Flag: Address Family flag. If unset, then the Prefix FEC 686 carries an IPv4 Prefix. If set then the Prefix FEC carries an 687 IPv6 Prefix. 689 M-Flag: Mirror Context flag. Set if the advertised SID/path 690 corresponds to a mirrored context. The use of the M flag is 691 described in [I-D.filsfils-spring-segment-routing]. 693 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 694 the entire routing domain. If the S flag is not set, the SID/ 695 Label Binding TLV MUST NOT be leaked between levels. This bit 696 MUST NOT be altered during the TLV leaking. 698 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 699 level-1, the D bit MUST be set. Otherwise, this bit MUST be 700 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 701 leaked from level-1 to level-2. This is to prevent TLV looping 702 across levels. 704 A-Flag: Attached flag. The originator of the SID/Label Binding 705 TLV MAY set the A bit in order to signal that the prefixes and 706 SIDs advertised in the SID/Label Binding TLV are directly 707 connected to their originators. The mechanisms through which the 708 originator of the SID/Label Binding TLV can figure out if a prefix 709 is attached or not are outside the scope of this document (e.g.: 710 through explicit configuration). 712 An implementation MAY decide not to honor the S-flag in order not 713 to leak Binding TLV's between levels (for policy reasons). In all 714 cases, the D flag MUST always be set by any router leaking the 715 Binding TLV from level-2 into level-1 and MUST be checked when 716 propagating the Binding TLV from level-1 into level-2. If the D 717 flag is set, the Binding TLV MUST NOT be propagated into level-2. 719 Other bits: MUST be zero when originated and ignored when 720 received. 722 2.4.2. Weight 724 Weight: 1 octet: The value represents the weight of the path for the 725 purpose of load balancing. The use of the weight is defined in 726 [I-D.filsfils-spring-segment-routing]. 728 2.4.3. Range 730 The 'Range' field provides the ability to specify a range of 731 addresses and their associated Prefix SIDs. This functionality is 732 called "Mapping Server". It is essentially a compression scheme to 733 distribute a continuous Prefix and their continuous, corresponding 734 SID/Label Block. If a single SID is advertised then the range field 735 MUST be set to one. For range advertisements > 1, the number of 736 addresses that need to be mapped into a Prefix-SID and the starting 737 value of the Prefix-SID range. 739 Example 1: if the following router addresses (loopback addresses) 740 need to be mapped into the corresponding Prefix SID indexes. 742 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 743 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 744 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 745 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Type | Length |0|0| | Weight | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Range = 4 | /32 | 192 | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | .0 | .2 | .1 |Prefix-SID Type| 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | sub-TLV Length| Flags | Algorithm | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | 1 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Example-2: If the following prefixes need to be mapped into the 762 corresponding Prefix-SID indexes: 764 10.1.1/24, Prefix-SID: Index 51 765 10.1.2/24, Prefix-SID: Index 52 766 10.1.3/24, Prefix-SID: Index 53 767 10.1.4/24, Prefix-SID: Index 54 768 10.1.5/24, Prefix-SID: Index 55 769 10.1.6/24, Prefix-SID: Index 56 770 10.1.7/24, Prefix-SID: Index 57 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type | Length |0|0| | Weight | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Range = 7 | /24 | 10 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Flags | Algorithm | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | 51 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 It is not expected that a network operator will be able to keep fully 787 continuous FEC Prefix / SID/Index mappings. In order to support 788 noncontinuous mapping ranges an implementation MAY generate several 789 instances of Binding TLVs. 791 For example if a router wants to advertise the following ranges: 793 Range 16: { 192.168.1.1-15, Index 1-15 } 795 Range 6: { 192.168.1.22-27, Index 22-27 } 797 Range 41: { 192.168.1.44-84, Index 80-120 } 799 A router would need to advertise three instances of the Binding TLV. 801 2.4.4. Prefix Length, Prefix 803 The 'FEC Prefix' represents the Forwarding equivalence class at the 804 tail-end of the advertised path. The 'FEC Prefix' does not need to 805 correspond to a routable prefix of the originating node. 807 The 'Prefix Length' field contains the length of the prefix in bits. 808 Only the most significant octets of the Prefix FEC are encoded. I.e. 809 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 810 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 811 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 812 prefix length 113 up to 128. 814 2.4.5. Mapping Server Prefix-SID 816 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 817 and contains the SID/index/label value associated with the prefix and 818 range. The Prefix-SID SubTLV MUST be used when the SID/Label Binding 819 TLV is used by the Mapping Server (i.e.: advertising one or a range 820 of prefixes and their associated SIDs/Labels). 822 A node receiving a MS entry for a prefix MUST check the existence of 823 such prefix in its link-state database prior to consider and use the 824 associated SID. 826 2.4.5.1. Prefix-SID Flags 828 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 829 MAY advertise a mapping with the N flag set when the prefix being 830 mapped is known in the link-state topology with a mask length of 32 831 and when the prefix represents a node. The mechanisms through which 832 the operator defines that a prefix represents a node are outside the 833 scope of this document (typically it will be through configuration). 835 The other flags defined in Section 2.1 are not used by the Mapping 836 Server and MUST be ignored at reception. 838 2.4.5.2. Prefix-SID Algorithm 840 The algorithm field contains the identifier of the algorithm the 841 router MUST use in order to compute reachability to the range of 842 prefixes. Use of the algorithm field is described in Section 2.1. 844 2.4.6. SID/Label Sub-TLV 846 The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the 847 SID/Label value as defined in Section 2.3. It MAY be present in the 848 SID/Label Binding TLV. 850 2.4.7. ERO Metric sub-TLV 852 ERO Metric sub-TLV (Type: TBD, suggested value 10) is a sub-TLV of 853 the SID/Label Binding TLV. 855 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 856 to compare the cost of a given source/destination path. A router MAY 857 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 858 SHOULD be set to the cumulative IGP or TE path cost of the advertised 859 ERO. Since manipulation of the Metric field may attract or distract 860 traffic from and to the advertised segment it MAY be manually 861 overridden. 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 | Metric | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Metric (continued) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 ERO Metric sub-TLV format 873 where: 875 Type: TBD, suggested value 10 877 Length: 4 879 Metric: 4 bytes 881 2.4.8. IPv4 ERO subTLV 883 The IPv4 ERO subTLV (Type: TBD, suggested value 11) describes a path 884 segment using IPv4 address style of encoding. Its semantics have 885 been borrowed from [RFC3209]. 887 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 888 set, then the value of the attribute is 'loose.' Otherwise, the 889 value of the attribute is 'strict.' 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Type | Length |L| Reserved | IPv4 address | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | IPv4 address (continued) | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Figure 2: IPv4 ERO subTLV format 901 2.4.9. IPv6 ERO subTLV 903 The IPv6 ERO subTLV (Type: TBD, suggested value 12) describes a path 904 segment using IPv6 Address style of encoding. Its semantics have 905 been borrowed from [RFC3209]. 907 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 908 set, then the value of the attribute is 'loose.' Otherwise, the 909 value of the attribute is 'strict.' 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Type | Length |L| Reserved | IPv6 address | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | IPv6 Address (continued) | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | IPv6 Address (continued) | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | IPv6 Address (continued) | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | IPv6 Address (continued) | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 Figure 3: IPv6 ERO subTLV format 927 2.4.10. Unnumbered Interface ID ERO subTLV 929 The appearance and semantics of the 'Unnumbered Interface ID' have 930 been borrowed from Section 4 [RFC3477]. 932 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 933 13) describes a path segment that spans over an unnumbered interface. 934 Unnumbered interfaces are referenced using the interface index. 935 Interface indices are assigned local to the router and therefore not 936 unique within a domain. All elements in an ERO path need to be 937 unique within a domain and hence need to be disambiguated using a 938 domain unique Router-ID. 940 The 'Router-ID' field contains the router ID of the router which has 941 assigned the 'Interface ID' field. Its purpose is to disambiguate 942 the 'Interface ID' field from other routers in the domain. 944 IS-IS supports two Router-ID formats: 946 o (TLV 134, 32-Bit format) [RFC5305] 948 o (TLV 140, 128-Bit format) [RFC6119] 950 The actual Router-ID format gets derived from the 'Length' field. 952 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 954 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 956 The 'Interface ID' is the identifier assigned to the link by the 957 router specified by the router ID. 959 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 960 set, then the value of the attribute is 'loose.' Otherwise, the 961 value of the attribute is 'strict.' 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type | Length |L| Reserved | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 // Router ID (32 or 128 bits) // 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Interface ID (32 bits) | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Figure 4: Unnumbered Interface ID ERO subTLV format 975 2.4.11. IPv4 Backup ERO subTLV 977 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 14) describes 978 a Backup path segment using IPv4 Address style of encoding. Its 979 appearance and semantics have been borrowed from [RFC3209]. 981 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 982 set, then the value of the attribute is 'loose.' Otherwise, the 983 value of the attribute is 'strict.' 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Type | Length |L| Reserved | IPv4 address | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | IPv4 address (continued) | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Figure 5: IPv4 Backup ERO subTLV format 995 2.4.12. IPv6 Backup ERO subTLV 997 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 15) describes 998 a Backup path segment using IPv6 Address style of encoding. Its 999 appearance and semantics have been borrowed from [RFC3209]. 1001 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1002 set, then the value of the attribute is 'loose.' Otherwise, the 1003 value of the attribute is 'strict.' 1004 0 1 2 3 1005 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 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Type | Length |L| Reserved | IPv6 address | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | IPv6 Address (continued) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | IPv6 Address (continued) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | IPv6 Address (continued) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | IPv6 Address (continued) | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 Figure 6: IPv6 Backup ERO subTLV format 1020 2.4.13. Unnumbered Interface ID Backup ERO subTLV 1022 The appearance and semantics of the 'Unnumbered Interface ID' have 1023 been borrowed from Section 4 [RFC3477]. 1025 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 1026 value 16) describes a Backup LSP path segment that spans over an 1027 unnumbered interface. Unnumbered interfaces are referenced using the 1028 interface index. Interface indices are assigned local to the router 1029 and therefore not unique within a domain. All elements in an ERO 1030 path need to be unique within a domain and hence need to be 1031 disambiguated using a domain unique Router-ID. 1033 The 'Router-ID' field contains the router ID of the router which has 1034 assigned the 'Interface ID' field. Its purpose is to disambiguate 1035 the 'Interface ID' field from other routers in the domain. 1037 IS-IS supports two Router-ID formats: 1039 o (TLV 134, 32-Bit format) [RFC5305] 1041 o (TLV 140, 128-Bit format) [RFC6119] 1043 The actual Router-ID format gets derived from the 'Length' field. 1045 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 1047 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 1049 The 'Interface ID' is the identifier assigned to the link by the 1050 router specified by the router ID. 1052 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 1053 set, then the value of the attribute is 'loose.' Otherwise, the 1054 value of the attribute is 'strict.' 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Type | Length |L| Reserved | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 // Router ID (32 or 128 bits) // 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Interface ID (32 bits) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 1068 2.4.14. Prefix ERO and Prefix Backup ERO subTLV path semantics 1070 All 'ERO' and 'Backup ERO' information represents an ordered set 1071 which describes the segments of a path. The last ERO subTLV 1072 describes the segment closest to the egress point of the path. 1073 Contrary the first ERO subTLV describes the first segment of a path. 1074 If a router extends or stitches a label switched path it MUST prepend 1075 the new segments path information to the ERO list. The same ordering 1076 applies for the Backup ERO labels. An implementation SHOULD first 1077 encode all primary path EROs followed by the bypass EROs. 1079 3. Router Capabilities 1081 3.1. SR-Capabilities Sub-TLV 1083 Segment Routing requires each router to advertise its SR data-plane 1084 capability and the range of MPLS label values it uses for Segment 1085 Routing in the case where global SIDs are allocated (i.e.: global 1086 indexes). Data-plane capabilities and label ranges are advertised 1087 using the newly defined SR-Capabilities sub-TLV inserted into the IS- 1088 IS Router Capability TLV-242 that is defined in [RFC4971]. 1090 The Router Capability TLV specifies flags that control its 1091 advertisement. The SR Capabilities sub-TLV MUST be propagated 1092 throughout the level and SHOULD NOT be advertised across level 1093 boundaries. Therefore Router Capability TLV distribution flags 1094 SHOULD be set accordingly, i.e.: the S flag MUST be unset. 1096 The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY appear 1097 multiple times inside the Router Capability TLV and has following 1098 format: 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Type | Length | Flags | Range | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Range (cont.) | SID/Label sub-TLV (variable) | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 where: 1110 Type: TBD, suggested value 2 1112 Length: variable. 1114 Flags: 1 octet of flags. The following are defined: 1116 0 1117 0 1 2 3 4 5 6 7 1118 +-+-+-+-+-+-+-+-+ 1119 |I|V| | 1120 +-+-+-+-+-+-+-+-+ 1122 where: 1124 I-Flag: IPv4 flag. If set, then the router is capable of 1125 outgoing IPv4 encapsulation on all interfaces. 1127 V-Flag: IPv6 flag. If set, then the router is capable of 1128 outgoing IPv6 encapsulation on all interfaces. 1130 Range: 3 octets value defining the number of values of the range 1131 from the starting value defined in the SID/Label sub-TLV. 1133 SID/Label sub-TLV: SID/Label value as defined in Section 2.3. 1135 Multiple occurrence of the SR-Capabilities sub-TLV MAY be advertised, 1136 in order to advertise multiple ranges. In such case: 1138 o Only the Flags in the first occurrence of the sub-TLV are to be 1139 taken into account. 1141 o The originating router MUST encode ranges each into a different 1142 SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded 1143 within the same LSP fragment. 1145 o The order of the ranges (i.e.: SR-Capability sub-TLVs) in the LSP 1146 fragment is decided by the originating router and hence the 1147 receiving routers MUST NOT re-order the received ranges. This is 1148 required for avoiding label churn when for example a numerical 1149 lower Segment/Label Block gets added to an already advertised 1150 Segment/Label Block. 1152 o An originator router SHOULD add newly configured block at the end, 1153 and SHOULD NOT change the order of previously advertised block. 1154 Indeed, changing the order to block being used will create label 1155 churn in the FIB and blackhole / misdirect some traffic during the 1156 IGP convergence. In particular, if a range, which is not the 1157 last, is extended it's preferable to add a new range rather than 1158 extending the previously advertised range. 1160 o The originating router decides the order of the set of originated 1161 SR-Capability sub-TLV. In all cases, the originating router MUST 1162 ensure the order is same after a graceful restart (using 1163 checkpointing, non-volatile storage or any other mechanism) in 1164 order to guarantee the same order before and after GR. 1166 o The originator router MUST NOT advertising overlapping range. 1168 o A router not supporting multiple occurrences of the SR-Capability 1169 sub-TLV MUST take into consideration the first occurrence in the 1170 received set. 1172 Here follows an example of advertisement of multiple ranges: 1174 The originating router advertises following ranges: 1175 SR-Cap: range: 100, SID value: 100 1176 SR-Cap: range: 100, SID value: 1000 1177 SR-Cap: range: 100, SID value: 500 1179 The receiving routers concatenate the ranges and build the SRGB 1180 is as follows: 1182 SRGB = [100, 199] 1183 [1000, 1099] 1184 [500, 599] 1186 The indexes span multiple ranges: 1188 index=0 means label 100 1189 ... 1190 index 99 means label 199 1191 index 100 means label 1000 1192 index 199 means label 1099 1193 ... 1194 index 200 means label 500 1195 ... 1197 3.2. SR-Algorithm Sub-TLV 1199 The router may use various algorithms when calculating reachability 1200 to other nodes or to prefixes attached to these nodes. Examples of 1201 these algorithms are metric based Shortest Path First (SPF), various 1202 sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, 1203 suggested value 19) allows the router to advertise the algorithms 1204 that the router is currently using. The following value has been 1205 defined: 1207 0: Shortest Path First (SPF) algorithm based on link metric. 1209 The SR-Algorithm sub-TLV is inserted into the IS-IS Router Capability 1210 TLV-242 that is defined in [RFC4971]. 1212 The Router Capability TLV specifies flags that control its 1213 advertisement. The SR-Algorithm MUST be propagated throughout the 1214 level and need not to be advertised across level boundaries. 1215 Therefore Router Capability TLV distribution flags MUST be set 1216 accordingly, i.e.: the S flag MUST be unset. 1218 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1219 time inside the Router Capability TLV. 1221 When the originating router does not advertise the SR-Algorithm sub- 1222 TLV, then all the Prefix-SID advertised by the router MUST have 1223 algorithm field set to 0. Any receiving router MUST assume SPF 1224 algorithm (i.e.: Shortest Path First). 1226 The SR-Algorithm sub-TLV has following format: 1228 0 1 2 3 1229 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 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Type | Length | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 where: 1238 Type: TBD, suggested value 19 1240 Length: variable. 1242 Algorithm: 1 octet of algorithm Section 2.1 1244 4. IANA Considerations 1246 This documents request allocation for the following TLVs and subTLVs. 1248 4.1. Sub TLVs for Type 22,23,222 and 223 1250 This document makes the following registrations in the "sub-TLVs for 1251 TLV 22, 23, 222 and 223" registry. 1253 Type: TBD (suggested value 31) 1255 Description: Adjacency Segment Identifier 1257 TLV 22: yes 1259 TLV 23: yes 1261 TLV 222: yes 1263 TLV 223: yes 1265 Reference: This document (Section 2.2.1) 1267 Type: TBD (suggested value 32) 1269 Description: LAN Adjacency Segment Identifier 1271 TLV 22: yes 1273 TLV 23: yes 1275 TLV 222: yes 1277 TLV 223: yes 1279 Reference: This document (Section 2.2.2) 1281 4.2. Sub TLVs for Type 135,235,236 and 237 1283 This document makes the following registrations in the "sub-TLVs for 1284 TLV 135,235,236 and 237" registry. 1286 Type: TBD (suggested value 3) 1287 Description: Prefix Segment Identifier 1289 TLV 135: yes 1291 TLV 235: yes 1293 TLV 236: yes 1295 TLV 237: yes 1297 Reference: This document (Section 2.1) 1299 4.3. Sub TLVs for Type 242 1301 This document makes the following registrations in the "sub-TLVs for 1302 TLV 242" registry. 1304 Type: TBD (suggested value 2) 1306 Description: Segment Routing Capability 1308 Reference: This document (Section 3.1) 1310 Type: TBD (suggested value 19) 1312 Description: Segment Routing Algorithm 1314 Reference: This document (Section 3.2) 1316 4.4. New TLV Codepoint and Sub-TLV registry 1318 This document registers the following TLV: 1320 Type: TBD (suggested value 149) 1322 name: Segment Identifier / Label Binding 1324 IIH: no 1326 LSP: yes 1328 SNP: no 1330 Purge: no 1331 Reference: This document (Section 2.4) 1333 This document creates the following sub-TLV Registry: 1335 Registry: sub-TLVs for TLV 149 1337 Registration Procedure: Expert review 1339 Reference: This document (Section 2.4) 1341 Type: TBD, suggested value 1 1343 Description: SID/Label 1345 Reference: This document (Section 2.3) 1347 Type: TBD, suggested value 3 1349 Description: Prefix-SID 1351 Reference: This document (Section 2.1) 1353 Type: TBD, suggested value 10 1355 Description: ERO Metric 1357 Reference: This document (Section 2.4.7) 1359 Type: TBD, suggested value 11 1361 Description: IPv4 ERO 1363 Reference: This document (Section 2.4.8) 1365 Type: TBD, suggested value 12 1367 Description: IPv6 ERO 1369 Reference: This document (Section 2.4.9) 1370 Type: TBD, suggested value 13 1372 Description: Unnumbered Interface-ID ERO 1374 Reference: This document (Section 2.4.10) 1376 Type: TBD, suggested value 14 1378 Description: IPv4 Backup ERO 1380 Reference: This document (Section 2.4.11) 1382 Type: TBD, suggested value 15 1384 Description: IPv6 Backup ERO 1386 Reference: This document (Section 2.4.12) 1388 Type: TBD, suggested value 16 1390 Description: Unnumbered Interface-ID Backup ERO 1392 Reference: This document (Section 2.4.13) 1394 5. Manageability Considerations 1396 TBD 1398 6. Security Considerations 1400 TBD 1402 7. Contributors 1404 The following people gave a substantial contribution to the content 1405 of this document: Martin Horneffer, Igor Milojevic, Rob Shakir, Saku 1406 Ytti, Wim Henderickx, Les Ginsberg, Steven Luong and Jesper Skriver. 1408 8. Acknowledgements 1410 We would like to thank Dave Ward, Dan Frost, Stewart Bryant and 1411 Pierre Francois for their contribution to the content of this 1412 document. 1414 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1415 earlier incarnations of the "Binding / MPLS Label TLV". 1417 9. References 1419 9.1. Normative References 1421 [ISO10589] 1422 International Organization for Standardization, 1423 "Intermediate system to Intermediate system intra-domain 1424 routeing information exchange protocol for use in 1425 conjunction with the protocol for providing the 1426 connectionless-mode Network Service (ISO 8473)", ISO/IEC 1427 10589:2002, Second Edition, Nov 2002. 1429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1430 Requirement Levels", BCP 14, RFC 2119, March 1997. 1432 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1433 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1434 Tunnels", RFC 3209, December 2001. 1436 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1437 in Resource ReSerVation Protocol - Traffic Engineering 1438 (RSVP-TE)", RFC 3477, January 2003. 1440 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1441 System to Intermediate System (IS-IS) Extensions for 1442 Advertising Router Information", RFC 4971, July 2007. 1444 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1445 Topology (MT) Routing in Intermediate System to 1446 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1448 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1449 Engineering", RFC 5305, October 2008. 1451 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1452 2008. 1454 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1455 "Simplified Extension of Link State PDU (LSP) Space for 1456 IS-IS", RFC 5311, February 2009. 1458 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1459 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1460 Traffic Engineering", RFC 5316, December 2008. 1462 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1463 Engineering in IS-IS", RFC 6119, February 2011. 1465 9.2. Informative References 1467 [I-D.filsfils-spring-segment-routing] 1468 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1469 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1470 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1471 "Segment Routing Architecture", draft-filsfils-spring- 1472 segment-routing-04 (work in progress), July 2014. 1474 [I-D.filsfils-spring-segment-routing-use-cases] 1475 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1476 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1477 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1478 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1479 spring-segment-routing-use-cases-01 (work in progress), 1480 October 2014. 1482 [I-D.previdi-6man-segment-routing-header] 1483 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 1484 Segment Routing Header (SRH)", draft-previdi-6man-segment- 1485 routing-header-02 (work in progress), July 2014. 1487 Authors' Addresses 1489 Stefano Previdi (editor) 1490 Cisco Systems, Inc. 1491 Via Del Serafico, 200 1492 Rome 00142 1493 Italy 1495 Email: sprevidi@cisco.com 1496 Clarence Filsfils 1497 Cisco Systems, Inc. 1498 Brussels 1499 BE 1501 Email: cfilsfil@cisco.com 1503 Ahmed Bashandy 1504 Cisco Systems, Inc. 1505 170, West Tasman Drive 1506 San Jose, CA 95134 1507 US 1509 Email: bashandy@cisco.com 1511 Hannes Gredler 1512 Juniper Networks, Inc. 1513 1194 N. Mathilda Ave. 1514 Sunnyvale, CA 94089 1515 US 1517 Email: hannes@juniper.net 1519 Stephane Litkowski 1520 Orange 1521 FR 1523 Email: stephane.litkowski@orange.com 1525 Bruno Decraene 1526 Orange 1527 FR 1529 Email: bruno.decraene@orange.com 1531 Jeff Tantsura 1532 Ericsson 1533 300 Holger Way 1534 San Jose, CA 95134 1535 US 1537 Email: Jeff.Tantsura@ericsson.com