idnits 2.17.1 draft-ietf-isis-segment-routing-extensions-02.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 (June 18, 2014) is 3593 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 1091 -- Looks like a reference, but probably isn't: '199' on line 1091 -- Looks like a reference, but probably isn't: '1000' on line 1092 -- Looks like a reference, but probably isn't: '1099' on line 1092 -- Looks like a reference, but probably isn't: '500' on line 1093 -- Looks like a reference, but probably isn't: '599' on line 1093 -- 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 (-04) exists of draft-filsfils-spring-segment-routing-03 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-01 Summary: 2 errors (**), 0 flaws (~~), 5 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: December 20, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 S. Litkowski 9 B. Decraene 10 Orange 11 J. Tantsura 12 Ericsson 13 June 18, 2014 15 IS-IS Extensions for Segment Routing 16 draft-ietf-isis-segment-routing-extensions-02 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 December 20, 2014. 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. E and P Flags . . . . . . . . . . . . . . . . . . . . 7 71 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 72 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 73 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 74 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 75 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 76 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 77 2.4.2. Weight . . . . . . . . . . . . . . . . . . . . . . . 15 78 2.4.3. Range . . . . . . . . . . . . . . . . . . . . . . . . 15 79 2.4.4. Prefix Length, Prefix . . . . . . . . . . . . . . . . 16 80 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 17 81 2.4.6. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 17 82 2.4.7. IPv4 ERO subTLV . . . . . . . . . . . . . . . . . . . 18 83 2.4.8. IPv6 ERO subTLV . . . . . . . . . . . . . . . . . . . 18 84 2.4.9. Unnumbered Interface ID ERO subTLV . . . . . . . . . 19 85 2.4.10. IPv4 Backup ERO subTLV . . . . . . . . . . . . . . . 20 86 2.4.11. IPv6 Backup ERO subTLV . . . . . . . . . . . . . . . 20 87 2.4.12. Unnumbered Interface ID Backup ERO subTLV . . . . . . 21 88 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path 89 semantics . . . . . . . . . . . . . . . . . . . . . . 22 90 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 22 91 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 22 92 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 24 93 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 4.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 25 95 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26 96 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26 97 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 27 98 5. Manageability Considerations . . . . . . . . . . . . . . . . 29 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 100 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 104 9.2. Informative References . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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). Two 113 types of segments are defined, Prefix segments and Adjacency 114 segments. Prefix segments represent an ecmp-aware shortest-path to a 115 prefix, as per the state of the IGP topology. Adjacency segments 116 represent a hop over a specific adjacency between two nodes in the 117 IGP. A prefix segment is typically a multi-hop path while an 118 adjacency segment, in most of the cases, is a one-hop path. SR's 119 control-plane can be applied to both IPv6 and MPLS data-planes, and 120 do not require any additional signaling (other than the regular IGP). 121 For example, when used in MPLS networks, SR paths do not require any 122 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 123 of LSPs established with RSVP or LDP. 125 This draft describes the necessary IS-IS extensions that need to be 126 introduced for Segment Routing. 128 Segment Routing architecture is described in 129 [I-D.filsfils-spring-segment-routing]. 131 Segment Routing use cases are described in 132 [I-D.filsfils-spring-segment-routing-use-cases]. 134 2. Segment Routing Identifiers 136 Segment Routing architecture ([I-D.filsfils-spring-segment-routing]) 137 defines different types of Segment Identifiers (SID). This document 138 defines the IS-IS encodings for the IGP-Prefix-SID, the IGP- 139 Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID. 141 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 143 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 144 (Prefix-SID Sub-TLV). 146 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as 147 defined in [I-D.filsfils-spring-segment-routing]. The 'Prefix SID' 148 MUST be unique within a given IGP domain (when the L-flag is not 149 set). The 'Prefix SID' MUST carry an index (when the V-flag is not 150 set) that determines the actual SID/label value inside the set of all 151 advertised SID/label ranges of a given router. A receiving router 152 uses the index to determine the actual SID/label value in order to 153 construct forwarding state to a particular destination router. 155 In many use-cases a 'stable transport' IP Address is overloaded as an 156 identifier of a given node. Because the IP Prefixes may be re- 157 advertised into other levels there may be some ambiguity (e.g. 158 Originating router vs. L1L2 router) for which node a particular IP 159 prefix serves as identifier. The Prefix-SID Sub-TLV contains the 160 necessary flags to disambiguate IP Prefix to node mappings. 161 Furthermore if a given node has several 'stable transport' IP 162 addresses there are flags to differentiate those among other IP 163 Prefixes advertised from a given node. 165 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 166 and MAY be present in any of the following TLVs: 168 TLV-135 (IPv4) defined in [RFC5305]. 170 TLV-235 (MT-IPv4) defined in [RFC5120]. 172 TLV-236 (IPv6) defined in [RFC5308]. 174 TLV-237 (MT-IPv6) defined in [RFC5120]. 176 Binding-TLV defined in Section 2.4. 178 The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP 179 Reachability TLV gets propagated across level boundaries. 181 The Prefix-SID Sub-TLV has the following format: 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | Flags | Algorithm | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SID/Index/Label (variable) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 where: 193 Type: TBD, suggested value 3 195 Length: variable. 197 Flags: 1 octet field of following flags: 199 0 1 2 3 4 5 6 7 200 +-+-+-+-+-+-+-+-+ 201 |R|N|P|E|V|L| | 202 +-+-+-+-+-+-+-+-+ 204 where: 206 R-Flag: Re-advertisement flag. If set, then the prefix to 207 which this Prefix-SID is attached, has been propagated by the 208 router either from another level (i.e.: from level-1 to level-2 209 or the opposite) or from redistribution (e.g.: from another 210 protocol). 212 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 213 the router identified by the prefix. Typically, the N-Flag is 214 set on Prefix-SIDs attached to a router loopback address. The 215 N-Flag is set when the Prefix-SID is a Node-SID as described in 216 [I-D.filsfils-spring-segment-routing]. 218 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 219 pop the Prefix-SID before delivering the packet to the node 220 that advertised the Prefix-SID. 222 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 223 the Prefix-SID originator MUST replace the Prefix-SID with a 224 Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for 225 IPv6) before forwarding the packet. 227 V-Flag: Value flag. If set, then the Prefix-SID carries a 228 value (instead of an index). By default the flag is UNSET. 230 L-Flag: Local Flag. If set, then the value/index carried by 231 the Prefix-SID has local significance. By default the flag is 232 UNSET. 234 Other bits: MUST be zero when originated and ignored when 235 received. 237 Algorithm: the router may use various algorithms when calculating 238 reachability to other nodes or to prefixes attached to these 239 nodes. Examples of these algorithms are metric based Shortest 240 Path First (SPF), various sorts of Constrained SPF, etc. The 241 Algorithm field allows a router to advertise algorithms that 242 router is currently using. SR-Algorithm TLV has following 243 structure: one octet identifying the algorithm to which the 244 Prefix-SID is associated. Currently, the following value has been 245 defined: 247 0: Shortest Path First (SPF) algorithm based on link metric. 249 Definitions and use of algorithms in Segment Routing are 250 described in [I-D.filsfils-spring-segment-routing] 252 SID/Index/Label: according to the V and L flags, it contains 253 either: 255 A 32 bit index defining the offset in the SID/Label space 256 advertised by this router using the encodings defined in 257 Section 3.1. 259 A 24 bit label where the 20 rightmost bits are used for 260 encoding the label value. 262 Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which 263 case each SID is encoded as a separate Sub-TLV. When multiple 264 Prefix-SID Sub-TLVs are present, the receiving router MUST use the 265 first encoded SID and MAY use the subsequent ones. 267 When propagating TLVs that contain multiple Prefix-SIDs between 268 levels, an implementation SHOULD preserve the ordering such that the 269 first Prefix-SID remains the first, so that implementations that only 270 recognize a single Prefix-SID will have a consistent view across 271 levels. 273 The R-Flag MUST be set for prefixes that are not local to the router 274 and either: 276 advertised because of propagation (Level-1 into Level-2); 277 advertised because of leaking (Level-2 into Level-1); 279 advertised because redistribution (e.g.: from another protocol). 281 In the case where a Level-1-2 router has local interface addresses 282 configured in one level, it may also propagate these addresses into 283 the other level. In such case, the Level-1-2 router MUST NOT set the 284 R bit. The R-bit MUST be set only for prefixes that are not local to 285 the router and advertised by the router because of propagation and/or 286 leaking. 288 The N-Flag is used in order to define a Node-SID. A router MAY set 289 the N-Flag only if all of the following conditions are met: 291 The prefix to which the Prefix-SID is attached is local to the 292 router. I.e.: the prefix is configured on one of the local 293 interfaces. (e.g.: 'stable transport' loopback). 295 The prefix to which the Prefix-SID is attached MUST have a Prefix 296 length of either /32 (IPv4) or /128 (IPv6). 298 The router MUST ignore the N-Flag on a received Prefix-SID if the 299 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 301 2.1.1. E and P Flags 303 When calculating the outgoing label for the prefix, the router MUST 304 take into account E and P flags advertised by the next-hop router, if 305 next-hop router advertised the SID for the prefix. This MUST be done 306 regardless of next-hop router contributing to the best path to the 307 prefix or not. 309 When propagating (either from Level-1 to Level-2 or vice versa) a 310 reachability advertisement originated by another IS-IS speaker, the 311 router MUST set the P-flag and MUST clear the E-flag of the related 312 Prefix-SIDs. 314 The following behavior is associated with the settings of the E and P 315 flags: 317 o If the P-flag is not set then any upstream neighbor of the Prefix- 318 SID originator MUST pop the Prefix-SID. This is equivalent to the 319 penultimate hop popping mechanism used in the MPLS dataplane which 320 improves performance of the ultimate hop. MPLS EXP bits of the 321 Prefix-SID are not preserved to the ultimate hop (the Prefix-SID 322 being removed). If the P-flag is unset the received E-flag is 323 ignored. 325 o If the P-flag is set then: 327 * If the E-flag is not set then any upstream neighbor of the 328 Prefix-SID originator MUST keep the Prefix-SID on top of the 329 stack. This is useful when, e.g., the originator of the 330 Prefix-SID must stitch the incoming packet into a continuing 331 MPLS LSP to the final destination. This could occur at an 332 inter-area border router (prefix propagation from one area to 333 another) or at an inter-domain border router (prefix 334 propagation from one domain to another). 336 * If the E-flag is set then any upstream neighbor of the Prefix- 337 SID originator MUST replace the PrefixSID with a Prefix-SID 338 having an Explicit-NULL value. This is useful, e.g., when the 339 originator of the Prefix-SID is the final destination for the 340 related prefix and the originator wishes to receive the packet 341 with the original EXP bits. 343 2.2. Adjacency Segment Identifier 345 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 346 TLV (Adj-SID Sub-TLV). 348 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 349 Routing IGP-Adjacency-SID as defined in 350 [I-D.filsfils-spring-segment-routing] with flags and fields that may 351 be used, in future extensions of Segment Routing, for carrying other 352 types of SIDs. 354 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 355 below: 357 TLV-22 [RFC5305] 359 TLV-222 [RFC5120] 361 TLV-23 [RFC5311] 363 TLV-223 [RFC5311] 365 TLV-141 [RFC5316] 367 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 368 neighbor. Examples where more than one Adj-SID may be used per IS- 369 neighbor are described in 370 [I-D.filsfils-spring-segment-routing-use-cases]. 372 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 374 The following format is defined for the Adj-SID Sub-TLV: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Length | Flags | Weight | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | SID/Label/Index (variable) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 where: 386 Type: TBD, suggested value 31 388 Length: variable. 390 Flags: 1 octet field of following flags: 392 0 1 2 3 4 5 6 7 393 +-+-+-+-+-+-+-+-+ 394 |F|B|V|L|S| | 395 +-+-+-+-+-+-+-+-+ 397 where: 399 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 400 to an adjacency with outgoing IPv4 encapsulation. If set then 401 the Adj-SID refers to an adjacency with outgoing IPv6 402 encapsulation. 404 B-Flag: Backup flag. If set, the Adj-SID refers to an 405 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 406 described in [I-D.filsfils-spring-segment-routing-use-cases]. 408 V-Flag: Value flag. If set, then the Adj-SID carries a value. 409 By default the flag is SET. 411 L-Flag: Local Flag. If set, then the value/index carried by 412 the Adj-SID has local significance. By default the flag is 413 SET. 415 S-Flag. Set Flag. When set, the S-Flag indicates that the 416 Adj-SID refers to a set of adjacencies (and therefore MAY be 417 assigned to other adjacencies as well). 419 Other bits: MUST be zero when originated and ignored when 420 received. 422 Weight: 1 octet. The value represents the weight of the Adj-SID 423 for the purpose of load balancing. The use of the weight is 424 defined in [I-D.filsfils-spring-segment-routing]. 426 SID/Index/Label: according to the V and L flags, it contains 427 either: 429 A 24 bit label where the 20 rightmost bits are used for 430 encoding the label value. 432 A 32 bit index defining the offset in the SID/Label space 433 advertised by this router using the encodings defined in 434 Section 3.1. 436 A variable length SID (e.g.: an IPv6 address SID). 438 An SR capable router MAY allocate an Adj-SID for each of its 439 adjacencies and SHOULD set the B-Flag when the adjacency is 440 protected by a FRR mechanism (IP or MPLS) as described in 441 [I-D.filsfils-spring-segment-routing-use-cases]. 443 A label is encoded in 3 octets (in the 20 rightmost bits). 445 An index is encoded in 4 octets. 447 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is 448 defined in [I-D.previdi-6man-segment-routing-header]). 450 An SR capable router MAY allocate more than one Adj-SID to an 451 adjacency. 453 An SR capable router MAY allocate the same Adj-SID to different 454 adjacencies. 456 Examples of use of the Adj-SID Sub-TLV are described in 457 [I-D.filsfils-spring-segment-routing]. 459 The F-flag is used in order for the router to advertise the 460 outgoing encapsulation of the adjacency the Adj-SID is attached 461 to. Use cases of the use of the F-flag are described in 462 [I-D.filsfils-spring-segment-routing-use-cases]. 464 2.2.2. Adjacency Segment Identifiers in LANs 466 In LAN subnetworks, the Designated Intermediate System (DIS) is 467 elected and originates the Pseudonode-LSP (PN-LSP) including all 468 neighbors of the DIS. 470 When Segment Routing is used, each router in the LAN MAY advertise 471 the Adj-SID of each of its neighbors. Since, on LANs, each router 472 only advertises one adjacency to the DIS (and doesn't advertise any 473 other adjacency), each router advertises the set of Adj-SIDs (for 474 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 475 advertising the adjacency to the DIS (e.g.: TLV-22). 477 The following new Sub-TLV is defined: LAN-Adj-SID (Type: TBD, 478 suggested value 32) containing the set of Adj-SIDs the router 479 assigned to each of its LAN neighbors. 481 The format of the LAN-Adj-SID Sub-TLV is as follows: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | Flags | Weight | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | System-ID (6 octets) | 491 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | SID/Label/Index (variable) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 where: 501 Type: TBD, suggested value 32 503 Length: variable. 505 Flags: 1 octet field of following flags: 507 0 1 2 3 4 5 6 7 508 +-+-+-+-+-+-+-+-+ 509 |F|B|V|L|S| | 510 +-+-+-+-+-+-+-+-+ 512 where F, B, V, L and S flags are defined in Section 2.2.1. Other 513 bits: MUST be zero when originated and ignored when received. 515 Weight: 1 octet. The value represents the weight of the Adj-SID 516 for the purpose of load balancing. The use of the weight is 517 defined in [I-D.filsfils-spring-segment-routing]. 519 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 520 defined in [ISO10589]. 522 SID/Index/Label: according to the I and G flags, it contains 523 either: 525 A 24 bit label where the 20 rightmost bits are used for 526 encoding the label value. 528 A 32 bit index defining the offset in the SID/Label space 529 advertised by this router using the encodings defined in 530 Section 3.1. 532 A variable length SID (e.g.: an IPv6 address SID). 534 Multiple LAN-Adj-SID Sub-TLVs MAY be encoded. 536 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 537 can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple 538 advertisements of the adjacency to the DIS MUST be used, MUST have 539 the same metric and SHOULD be inserted within the same LSP fragment. 541 Each router within the level, by receiving the DIS PN LSP as well as 542 the non-PN LSP of each router in the LAN, is capable of 543 reconstructing the LAN topology as well as the set of Adj-SID each 544 router uses for each of its neighbors. 546 A label is encoded in 3 octets (in the 20 rightmost bits). 548 An index is encoded in 4 octets. 550 An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined 551 in [I-D.previdi-6man-segment-routing-header]). 553 2.3. SID/Label Sub-TLV 555 The SID/Label Sub-TLV is present in the following Sub-TLVs defined in 556 this document: 558 Binding TLV Section 2.4. 560 SR Capability Sub-TLV Section 3.1. 562 The SID/Label Sub-TLV contains a SID or a MPLS Label. The SID/Label 563 Sub-TLV has the following format: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | SID/Label (variable) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 where: 575 Type: TBD, suggested value 1 577 Length: variable 579 SID/Label: if length is set to 3 then the 20 rightmost bits 580 represent a MPLS label. 582 2.4. SID/Label Binding TLV 584 The SID/Label Binding TLV MAY be originated by any router in an IS-IS 585 domain. The router may advertise a SID/Label binding to a FEC along 586 with at least a single 'nexthop style' anchor. The protocol supports 587 more than one 'nexthop style' anchor to be attached to a SID/Label 588 binding, which results into a simple path description language. In 589 analogy to RSVP the terminology for this is called an 'Explicit Route 590 Object' (ERO). Since ERO style path notation allows to anchor SID/ 591 label bindings to both link and node IP addresses any label switched 592 path, can be described. Furthermore also SID/Label Bindings from 593 external protocols can get easily re-advertised. 595 The SID/Label Binding TLV may be used for advertising SID/Label 596 Bindings and their associated Primary and Backup paths. In one 597 single TLV either a primary ERO Path, a backup ERO Path or both are 598 advertised. If a router wants to advertise multiple parallel paths 599 then it can generate several TLVs for the same Prefix/FEC. Each 600 occurrence of a Binding TLV with respect with a given FEC Prefix has 601 accumulating and not canceling semantics. Due the space constraints 602 in the 8-Bit IS-IS TLVs an originating router MAY encode a primary 603 ERO path in one SID/Label Binding TLV and the backup ERO path in a 604 second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label 605 Sub-TLV MUST be identical in both TLVs. 607 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 608 the following format: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type | Length | Flags | Weight | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Range | Prefix Length | FEC Prefix | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 // FEC Prefix (continued, variable) // 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | SubTLVs (variable) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Figure 1: SID/Label Binding TLV format 624 o Type: TBD, suggested value 149 626 o Length: variable. 628 o 1 octet of flags 630 o 1 octet of Weight 632 o 2 octets of Range 634 o 1 octet of Prefix Length 636 o 0-16 octets of FEC Prefix 638 o sub-TLVs, where each sub-TLV consists of a sequence of: 640 * 1 octet of sub-TLV type 642 * 1 octet of length of the value field of the sub-TLV 644 * 0-243 octets of value 646 2.4.1. Flags 648 Flags: 1 octet field of following flags: 650 0 1 2 3 4 5 6 7 651 +-+-+-+-+-+-+-+-+ 652 |F|M| | 653 +-+-+-+-+-+-+-+-+ 654 where: 656 F-Flag: Address Family flag. If unset, then the Prefix FEC 657 carries an IPv4 Prefix. If set then the Prefix FEC carries an 658 IPv6 Prefix. 660 M-Flag: Mirror Context flag. Set if the advertised SID/path 661 corresponds to a mirrored context. The use of the M flag is 662 described in [I-D.filsfils-spring-segment-routing]. 664 Other bits: MUST be zero when originated and ignored when 665 received. 667 2.4.2. Weight 669 Weight: 1 octet: The value represents the weight of the path for the 670 purpose of load balancing. The use of the weight is defined in 671 [I-D.filsfils-spring-segment-routing]. 673 2.4.3. Range 675 The 'Range' field provides the ability to specify a range of 676 addresses and their associated Prefix SIDs. It is essentially a 677 compression scheme to distribute a continuous Prefix and their 678 continuous, corresponding SID/Label Block. If a single SID is 679 advertised then the range field MUST be set to one. For range 680 advertisements > 1, the number of addresses that need to be mapped 681 into a Prefix-SID and the starting value of the Prefix-SID range. 683 Example 1: if the following router addresses (loopback addresses) 684 need to be mapped into the corresponding Prefix SID indexes. 686 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 687 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 688 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 689 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length |0|0| | Weight | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Range = 4 | /32 | 192 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | .0 | .2 | .1 | Sub-TLV Type | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Sub-TLV Length| 1 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Example-2: If the following prefixes need to be mapped into the 704 corresponding Prefix-SID indexes: 706 10.1.1/24, Prefix-SID: Index 51 707 10.1.2/24, Prefix-SID: Index 52 708 10.1.3/24, Prefix-SID: Index 53 709 10.1.4/24, Prefix-SID: Index 54 710 10.1.5/24, Prefix-SID: Index 55 711 10.1.6/24, Prefix-SID: Index 56 712 10.1.7/24, Prefix-SID: Index 57 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Type | Length |0|0| | Weight | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Range = 7 | /24 | 10 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | .1 | .1 | Sub-TLV Type | Sub-TLV Length| 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | 51 | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 It is not expected that a network operator will be able to keep fully 727 continuous FEC Prefix / SID/Index mappings. In order to support 728 noncontinuous mapping ranges an implementation MAY generate several 729 instances of Binding TLVs. 731 For example if a router wants to advertise the following ranges: 733 Range 16: { 192.168.1.1-15, Index 1-15 } 735 Range 6: { 192.168.1.22-27, Index 22-27 } 737 Range 41: { 192.168.1.44-84, Index 80-120 } 739 A router would need to advertise three instances of the Binding TLV. 741 When "Range" is present, the encoding of the SID/Index/Label MUST be 742 done through the insertion of the Prefix-SID Sub-TLV as defined in 743 Section 2.1. 745 2.4.4. Prefix Length, Prefix 747 The 'FEC Prefix' represents the Forwarding equivalence class at the 748 tail-end of the advertised path. The 'FEC Prefix' does not need to 749 correspond to a routable prefix of the originating node. 751 The 'Prefix Length' field contains the length of the prefix in bits. 752 Only the most significant octets of the Prefix FEC are encoded. I.e. 753 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix 754 length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 755 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC 756 prefix length 113 up to 128. 758 2.4.5. SID/Label Sub-TLV 760 The SID/Label Sub-TLV (Type: TBD, suggested value 1) contains the 761 SID/Label value as defined in Section 2.3. It MAY be present in the 762 SID/Label Binding TLV. 764 2.4.6. ERO Metric sub-TLV 766 ERO Metric sub-TLV (Type: TBD, suggested value 2) is a Sub-TLV of the 767 SID/Label Binding TLV. 769 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 770 to compare the cost of a given source/destination path. A router MAY 771 advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV 772 SHOULD be set to the cumulative IGP or TE path cost of the advertised 773 ERO. Since manipulation of the Metric field may attract or distract 774 traffic from and to the advertised segment it MAY be manually 775 overridden. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Length | Metric | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Metric (continued) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 ERO Metric sub-TLV format 787 where: 789 Type: TBD, suggested value 2 791 Length: 4 793 Metric: 4 bytes 795 2.4.7. IPv4 ERO subTLV 797 The IPv4 ERO subTLV (Type: TBD, suggested value 3) describes a path 798 segment using IPv4 address style of encoding. Its semantics have 799 been borrowed from [RFC3209]. 801 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 802 set, then the value of the attribute is 'loose.' Otherwise, the 803 value of the attribute is 'strict.' 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Type | Length |L| Reserved | IPv4 address | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | IPv4 address (continued) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 2: IPv4 ERO subTLV format 815 2.4.8. IPv6 ERO subTLV 817 The IPv6 ERO subTLV (Type: TBD, suggested value 4) describes a path 818 segment using IPv6 Address style of encoding. Its semantics have 819 been borrowed from [RFC3209]. 821 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 822 set, then the value of the attribute is 'loose.' Otherwise, the 823 value of the attribute is 'strict.' 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Type | Length |L| Reserved | IPv6 address | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | IPv6 Address (continued) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | IPv6 Address (continued) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | IPv6 Address (continued) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | IPv6 Address (continued) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 3: IPv6 ERO subTLV format 841 2.4.9. Unnumbered Interface ID ERO subTLV 843 The appearance and semantics of the 'Unnumbered Interface ID' have 844 been borrowed from Section 4 [RFC3477]. 846 The Unnumbered Interface-ID ERO subTLV (Type: TBD, suggested value 5) 847 describes a path segment that spans over an unnumbered interface. 848 Unnumbered interfaces are referenced using the interface index. 849 Interface indices are assigned local to the router and therefore not 850 unique within a domain. All elements in an ERO path need to be 851 unique within a domain and hence need to be disambiguated using a 852 domain unique Router-ID. 854 The 'Router-ID' field contains the router ID of the router which has 855 assigned the 'Interface ID' field. Its purpose is to disambiguate 856 the 'Interface ID' field from other routers in the domain. 858 IS-IS supports two Router-ID formats: 860 o (TLV 134, 32-Bit format) [RFC5305] 862 o (TLV 140, 128-Bit format) [RFC6119] 864 The actual Router-ID format gets derived from the 'Length' field. 866 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 868 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 870 The 'Interface ID' is the identifier assigned to the link by the 871 router specified by the router ID. 873 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 874 set, then the value of the attribute is 'loose.' Otherwise, the 875 value of the attribute is 'strict.' 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type | Length |L| Reserved | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 // Router ID (32 or 128 bits) // 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Interface ID (32 bits) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 4: Unnumbered Interface ID ERO subTLV format 889 2.4.10. IPv4 Backup ERO subTLV 891 The IPv4 Backup ERO subTLV (Type: TBD, suggested value 6) describes a 892 Backup path segment using IPv4 Address style of encoding. Its 893 appearance and semantics have been borrowed from [RFC3209]. 895 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 896 set, then the value of the attribute is 'loose.' Otherwise, the 897 value of the attribute is 'strict.' 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type | Length |L| Reserved | IPv4 address | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | IPv4 address (continued) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Figure 5: IPv4 Backup ERO subTLV format 909 2.4.11. IPv6 Backup ERO subTLV 911 The IPv6 Backup ERO subTLV (Type: TBD, suggested value 7) describes a 912 Backup path segment using IPv6 Address style of encoding. Its 913 appearance and semantics have been borrowed from [RFC3209]. 915 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 916 set, then the value of the attribute is 'loose.' Otherwise, the 917 value of the attribute is 'strict.' 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Type | Length |L| Reserved | IPv6 address | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | IPv6 Address (continued) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | IPv6 Address (continued) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | IPv6 Address (continued) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | IPv6 Address (continued) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Figure 6: IPv6 Backup ERO subTLV format 935 2.4.12. Unnumbered Interface ID Backup ERO subTLV 937 The appearance and semantics of the 'Unnumbered Interface ID' have 938 been borrowed from Section 4 [RFC3477]. 940 The Unnumbered Interface-ID Backup ERO subTLV (Type: TBD, suggested 941 value 8) describes a Backup LSP path segment that spans over an 942 unnumbered interface. Unnumbered interfaces are referenced using the 943 interface index. Interface indices are assigned local to the router 944 and therefore not unique within a domain. All elements in an ERO 945 path need to be unique within a domain and hence need to be 946 disambiguated using a domain unique Router-ID. 948 The 'Router-ID' field contains the router ID of the router which has 949 assigned the 'Interface ID' field. Its purpose is to disambiguate 950 the 'Interface ID' field from other routers in the domain. 952 IS-IS supports two Router-ID formats: 954 o (TLV 134, 32-Bit format) [RFC5305] 956 o (TLV 140, 128-Bit format) [RFC6119] 958 The actual Router-ID format gets derived from the 'Length' field. 960 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 962 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 964 The 'Interface ID' is the identifier assigned to the link by the 965 router specified by the router ID. 967 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 968 set, then the value of the attribute is 'loose.' Otherwise, the 969 value of the attribute is 'strict.' 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Length |L| Reserved | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 // Router ID (32 or 128 bits) // 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Interface ID (32 bits) | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 Figure 7: Unnumbered Interface ID Backup ERO subTLV format 983 2.4.13. Prefix ERO and Prefix Backup ERO subTLV path semantics 985 All 'ERO' and 'Backup ERO' information represents an ordered set 986 which describes the segments of a path. The last ERO subTLV 987 describes the segment closest to the egress point of the path. 988 Contrary the first ERO subTLV describes the first segment of a path. 989 If a router extends or stitches a label switched path it MUST prepend 990 the new segments path information to the ERO list. The same ordering 991 applies for the Backup ERO labels. An implementation SHOULD first 992 encode all primary path EROs followed by the bypass EROs. 994 3. Router Capabilities 996 3.1. SR-Capabilities Sub-TLV 998 Segment Routing requires each router to advertise its SR data-plane 999 capability and the range of SID/Label values it uses for Segment 1000 Routing. Data-plane capabilities and SID/Label ranges are advertised 1001 using the newly defined SR-Capabilities Sub-TLV inserted into the IS- 1002 IS Router Capability TLV-242 that is defined in [RFC4971]. 1004 The Router Capability TLV specifies flags that control its 1005 advertisement. The SR Capabilities Sub-TLV MUST be propagated 1006 throughout the level and need not to be advertised across level 1007 boundaries. Therefore Router Capability TLV distribution flags MUST 1008 be set accordingly, i.e.: the S flag MUST be unset. 1010 The SR Capabilities Sub-TLV (Type: TBD, suggested value 2) is 1011 optional, MAY appear multiple times inside the Router Capability TLV 1012 and has following format: 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Type | Length | Flags | Range | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Range (cont.) | SID/Label Sub-TLV (variable) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 where: 1024 Type: TBD, suggested value 2 1026 Length: variable. 1028 Flags: 1 octet of flags. The following are defined: 1030 0 1031 0 1 2 3 4 5 6 7 1032 +-+-+-+-+-+-+-+-+ 1033 |I|V| | 1034 +-+-+-+-+-+-+-+-+ 1036 where: 1038 I-Flag: IPv4 flag. If set, then the router is capable of 1039 outgoing IPv4 encapsulation on all interfaces. 1041 V-Flag: IPv6 flag. If set, then the router is capable of 1042 outgoing IPv6 encapsulation on all interfaces. 1044 Range: 3 octets value defining the number of values of the range 1045 from the starting value defined in the SID/Label Sub-TLV. 1047 SID/Label Sub-TLV: SID/Label value as defined in Section 2.3. 1049 Multiple occurrence of the SR-Capabilities Sub-TLV MAY be advertised, 1050 in order to advertise multiple ranges. In such case: 1052 o Only the Flags in the first occurrence of the Sub-TLV are to be 1053 taken into account. 1055 o The originating router MUST encode ranges each into a different 1056 SR-Capability Sub-TLV and all SR-Capability TLVs MUST be encoded 1057 within the same LSP fragment. 1059 o The order of the ranges (i.e.: SR-Capability Sub-TLVs) in the LSP 1060 fragment is decided by the originating router and hence the 1061 receiving routers MUST NOT re-order the received ranges. This is 1062 required for avoiding label churn when for example a numerical 1063 lower Segment/Label Block gets added to an already advertised 1064 Segment/Label Block. 1066 o An originator router SHOULD add newly configured block at the end, 1067 and SHOULD NOT change the order of previously advertised block. 1068 Indeed, changing the order to block being used will create label 1069 churn in the FIB and blackhole / misdirect some traffic during the 1070 IGP convergence. In particular, if a range, which is not the 1071 last, is extended it's preferable to add a new range rather than 1072 extending the previously advertised range. 1074 o The originating router decides the order of the set of originated 1075 SR-Capability Sub-TLV (sorted or not). In all cases, the 1076 originating router MUST ensure the order is same after a graceful 1077 restart (using checkpointing, non-volatile storage or any other 1078 mechanism) in order to guarantee the same order before and after 1079 GR. 1081 Here follows an example of advertisement of multiple ranges: 1083 The originating router advertises following ranges: 1084 Range 1: [100, 199] 1085 Range 2: [1000, 1099] 1086 Range 3: [500, 599] 1088 The receiving routers concatenate the ranges and build the SRGB 1089 is as follows: 1091 SRGB = [100, 199] 1092 [1000, 1099] 1093 [500, 599] 1095 The indexes span multiple ranges: 1097 index=0 means label 100 1098 ... 1099 index 99 means label 199 1100 index 100 means label 1000 1101 index 199 means label 1099 1102 ... 1103 index 200 means label 500 1104 ... 1106 3.2. SR-Algorithm Sub-TLV 1108 The router may use various algorithms when calculating reachability 1109 to other nodes or to prefixes attached to these nodes. Examples of 1110 these algorithms are metric based Shortest Path First (SPF), various 1111 sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV (Type: TBD, 1112 suggested value 19) allows the router to advertise the algorithms 1113 that the router is currently using. The following value has been 1114 defined: 1116 0: Shortest Path First (SPF) algorithm based on link metric. 1118 The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability 1119 TLV-242 that is defined in [RFC4971]. 1121 The Router Capability TLV specifies flags that control its 1122 advertisement. The SR-Algorithm MUST be propagated throughout the 1123 level and need not to be advertised across level boundaries. 1124 Therefore Router Capability TLV distribution flags MUST be set 1125 accordingly, i.e.: the S flag MUST be unset. 1127 The SR-Algorithm Sub-TLV is optional, it MAY only appear a single 1128 time inside the Router Capability TLV. If the SID-Label Capability 1129 Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be 1130 advertised. 1132 It has following format: 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Type | Length | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 where: 1144 Type: TBD, suggested value 19 1146 Length: variable. 1148 Algorithm: 1 octet of algorithm Section 2.1 1150 4. IANA Considerations 1152 This documents request allocation for the following TLVs and subTLVs. 1154 4.1. Sub TLVs for Type 22,23,222 and 223 1156 This document makes the following registrations in the "Sub-TLVs for 1157 TLV 22, 23, 222 and 223" registry. 1159 Type: TBD (suggested value 31) 1161 Description: Adjacency Segment Identifier 1163 TLV 22: yes 1165 TLV 23: yes 1167 TLV 222: yes 1169 TLV 223: yes 1171 Reference: This document (Section 2.2.1) 1172 Type: TBD (suggested value 32) 1174 Description: LAN Adjacency Segment Identifier 1176 TLV 22: yes 1178 TLV 23: yes 1180 TLV 222: yes 1182 TLV 223: yes 1184 Reference: This document (Section 2.2.2) 1186 4.2. Sub TLVs for Type 135,235,236 and 237 1188 This document makes the following registrations in the "Sub-TLVs for 1189 TLV 135,235,236 and 237" registry. 1191 Type: TBD (suggested value 3) 1193 Description: Prefix Segment Identifier 1195 TLV 135: yes 1197 TLV 235: yes 1199 TLV 236: yes 1201 TLV 237: yes 1203 Reference: This document (Section 2.1) 1205 4.3. Sub TLVs for Type 242 1207 This document makes the following registrations in the "Sub-TLVs for 1208 TLV 242" registry. 1210 Type: TBD (suggested value 2) 1212 Description: Segment Routing Capability 1214 Reference: This document (Section 3.1) 1215 Type: TBD (suggested value 19) 1217 Description: Segment Routing Algorithm 1219 Reference: This document (Section 3.2) 1221 4.4. New TLV Codepoint and Sub-TLV registry 1223 This document registers the following TLV: 1225 Type: TBD (suggested value 149) 1227 name: Segment Identifier / Label Binding 1229 IIH: no 1231 LSP: yes 1233 SNP: no 1235 Purge: no 1237 Reference: This document (Section 2.4) 1239 This document creates the following Sub-TLV Registry: 1241 Registry: Sub-TLVs for TLV 149 1243 Registration Procedure: Expert review 1245 Reference: This document (Section 2.4) 1247 Type: TBD, suggested value 1 1249 Description: SID/Label 1251 Reference: This document (Section 2.3) 1253 Type: TBD, suggested value 2 1255 Description: ERO Metric 1257 Reference: This document (Section 2.4.6) 1258 Type: TBD, suggested value 3 1260 Description: IPv4 ERO 1262 Reference: This document (Section 2.4.7) 1264 Type: TBD, suggested value 4 1266 Description: IPv6 ERO 1268 Reference: This document (Section 2.4.8) 1270 Type: TBD, suggested value 5 1272 Description: Unnumbered Interface-ID ERO 1274 Reference: This document (Section 2.4.9) 1276 Type: TBD, suggested value 6 1278 Description: IPv4 Backup ERO 1280 Reference: This document (Section 2.4.10) 1282 Type: TBD, suggested value 7 1284 Description: IPv6 Backup ERO 1286 Reference: This document (Section 2.4.11) 1288 Type: TBD, suggested value 8 1290 Description: Unnumbered Interface-ID Backup ERO 1292 Reference: This document (Section 2.4.12) 1294 5. Manageability Considerations 1296 TBD 1298 6. Security Considerations 1300 TBD 1302 7. Contributors 1304 The following people gave a substantial contribution to the content 1305 of this document: Martin Horneffer, Igor Milojevic, Rob Shakir, Saku 1306 Ytti, Wim Henderickx, Les Ginsberg, Steven Luong and Jesper Skriver. 1308 8. Acknowledgements 1310 We would like to thank Dave Ward, Dan Frost, Stewart Bryant and 1311 Pierre Francois for their contribution to the content of this 1312 document. 1314 Many thanks to Yakov Rekhter and Ina Minei for their contribution on 1315 earlier incarnations of the "Binding / MPLS Label TLV". 1317 9. References 1319 9.1. Normative References 1321 [ISO10589] 1322 International Organization for Standardization, 1323 "Intermediate system to Intermediate system intra-domain 1324 routeing information exchange protocol for use in 1325 conjunction with the protocol for providing the 1326 connectionless-mode Network Service (ISO 8473)", ISO/IEC 1327 10589:2002, Second Edition, Nov 2002. 1329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1330 Requirement Levels", BCP 14, RFC 2119, March 1997. 1332 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1333 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1334 Tunnels", RFC 3209, December 2001. 1336 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1337 in Resource ReSerVation Protocol - Traffic Engineering 1338 (RSVP-TE)", RFC 3477, January 2003. 1340 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 1341 System to Intermediate System (IS-IS) Extensions for 1342 Advertising Router Information", RFC 4971, July 2007. 1344 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1345 Topology (MT) Routing in Intermediate System to 1346 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1348 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1349 Engineering", RFC 5305, October 2008. 1351 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1352 2008. 1354 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1355 "Simplified Extension of Link State PDU (LSP) Space for 1356 IS-IS", RFC 5311, February 2009. 1358 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1359 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1360 Traffic Engineering", RFC 5316, December 2008. 1362 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1363 Engineering in IS-IS", RFC 6119, February 2011. 1365 9.2. Informative References 1367 [I-D.filsfils-spring-segment-routing] 1368 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1369 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1370 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1371 "Segment Routing Architecture", draft-filsfils-spring- 1372 segment-routing-03 (work in progress), June 2014. 1374 [I-D.filsfils-spring-segment-routing-use-cases] 1375 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1376 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1377 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1378 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1379 spring-segment-routing-use-cases-00 (work in progress), 1380 March 2014. 1382 [I-D.previdi-6man-segment-routing-header] 1383 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 1384 Segment Routing Header (SRH)", draft-previdi-6man-segment- 1385 routing-header-01 (work in progress), June 2014. 1387 Authors' Addresses 1389 Stefano Previdi (editor) 1390 Cisco Systems, Inc. 1391 Via Del Serafico, 200 1392 Rome 00142 1393 Italy 1395 Email: sprevidi@cisco.com 1397 Clarence Filsfils 1398 Cisco Systems, Inc. 1399 Brussels 1400 BE 1402 Email: cfilsfil@cisco.com 1404 Ahmed Bashandy 1405 Cisco Systems, Inc. 1406 170, West Tasman Drive 1407 San Jose, CA 95134 1408 US 1410 Email: bashandy@cisco.com 1412 Hannes Gredler 1413 Juniper Networks, Inc. 1414 1194 N. Mathilda Ave. 1415 Sunnyvale, CA 94089 1416 US 1418 Email: hannes@juniper.net 1420 Stephane Litkowski 1421 Orange 1422 FR 1424 Email: stephane.litkowski@orange.com 1425 Bruno Decraene 1426 Orange 1427 FR 1429 Email: bruno.decraene@orange.com 1431 Jeff Tantsura 1432 Ericsson 1433 300 Holger Way 1434 San Jose, CA 95134 1435 US 1437 Email: Jeff.Tantsura@ericsson.com