idnits 2.17.1 draft-previdi-isis-segment-routing-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2013) is 3945 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) -- 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 (-03) exists of draft-minto-rsvp-lsp-egress-fast-protection-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 30, 2013 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Geib 10 Deutsche Telekom 11 I. Milojevic 12 Telekom Srbija 13 R. Shakir 14 British Telecom 15 S. Ytti 16 TDC Oy 17 W. Henderickx 18 Alcatel-Lucent 19 J. Tantsura 20 Ericsson 21 June 28, 2013 23 IS-IS Extensions for Segment Routing 24 draft-previdi-isis-segment-routing-extensions-00 26 Abstract 28 Segment Routing (SR) allows for a flexible definition of end-to-end 29 paths within IGP topologies by encoding paths as sequences of 30 topological sub-paths, called "segments". These segments are 31 advertised by the link-state routing protocols (IS-IS and OSPF). 33 This draft describes the necessary IS-IS extensions that need to be 34 introduced for Segment Routing. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on December 30, 2013. 59 Copyright Notice 61 Copyright (c) 2013 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 78 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . . 4 79 2.2. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . 6 80 2.2.1. Adj-SID and Interface Address . . . . . . . . . . . . 7 81 2.2.2. Adj-SID and Forwarding Adjacencies . . . . . . . . . . 7 82 2.2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . . 7 83 2.2.4. Adjacency Segment Identifiers in LANs . . . . . . . . 10 84 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . . 12 85 3.1. Segment Routing Capability Sub-TLV (SR-Cap) . . . . . . . 12 86 3.2. Segment Routing Mapping Server . . . . . . . . . . . . . . 14 87 3.2.1. SR Mapping Server Sub-TLV . . . . . . . . . . . . . . 14 88 3.3. Segment Routing Mirroring Context Sub-TLV (SRMC) . . . . . 17 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 5. Manageability Considerations . . . . . . . . . . . . . . . . . 18 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Segment Routing (SR) allows for a flexible definition of end-to-end 101 paths within IGP topologies by encoding paths as sequences of 102 topological sub-paths, called "segments". These segments are 103 advertised by the link-state routing protocols (IS-IS and OSPF). Two 104 types of segments are defined, Prefix segments and Adjacency 105 segments. Prefix segments represent an ecmp-aware shortest-path to a 106 prefix, as per the state of the IGP topology. Adjacency segments 107 represent a hop over a specific adjacency between two nodes in the 108 IGP. A prefix segment is typically a multi-hop path while an 109 adjacency segment, in most of the cases, is a one-hop path. SR's 110 control-plane can be applied to both IPv6 and MPLS data-planes, and 111 do not require any additional signaling (other than the regular IGP). 112 For example, when used in MPLS networks, SR paths do not require any 113 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 114 of LSPs established with RSVP or LDP . 116 This draft describes the necessary IS-IS extensions that need to be 117 introduced for Segment Routing. 119 This draft replaces [I-D.previdi-filsfils-isis-segment-routing]. 121 Segment Routing architecture is described in 122 [draft-filsfils-rtgwg-segment-routing-00]. 124 Segment Routing use cases are described in 125 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 127 2. Segment Routing Identifiers 129 Segment Routing architecture defines different types of Segment 130 Identifiers (SID). This document defines the IS-IS encodings for the 131 IGP-Prefix-SID and IGP-Adjacency-SID. 133 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 135 A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV 136 (Prefix-SID Sub-TLV). 138 The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID and 139 has flags and fields that may be used, in future extensions of 140 Segment Routing, for carrying other types of SIDs. 142 A Prefix-SID Sub-TLV is associated to a prefix advertised by a node 143 and MAY be present in any of the following TLVs: 145 TLV-135 (IPv4) defined in [RFC5305]. 147 TLV-235 (MT-ipv4) defined in [RFC5120]. 149 TLV-236 (IPv6) defined in [RFC5308]. 151 TLV-237 (MT-IPv6) defined in [RFC5120]. 153 The Prefix-SID Sub-TLV has the following format: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | Length | Flags | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Prefix Segment Identifier (SID) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 where: 164 Type: TBA 166 Length: multiple of 6 octets. 168 Flags: 2 octets field of following flags: 169 0 1 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |R|N|P|G| | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 where: 177 R-Flag: Re-advertisement flag. If set, then the prefix to 178 which this Prefix-SID is attached, has been propagated by the 179 router either from another level (i.e.: from level-1 to level-2 180 or the opposite) or from redistribution (e.g.: from another 181 protocol). 183 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 184 the router identified by the prefix. Typically, the N-Flag is 185 set on Prefix-SIDs attached to a router loopback address. The 186 N-Flag is set when the Prefix-SID is a Node-SID as described in 187 [draft-filsfils-rtgwg-segment-routing-00]. This flag is 188 optional. 190 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 191 pop the Prefix-SID before delivering the packet to the node 192 that advertised the Prefix-SID. 194 G-Flag: Global flag. When set, the SID value has global 195 significance which means the SID has been allocated from the 196 Global Segment Routing Block (SRGB) as described in 197 [draft-filsfils-rtgwg-segment-routing-00]. When unset, the SID 198 value has local (within the router) significance which means 199 the SID has NOT been allocated from the SRGB. When the IS-IS 200 Prefix-SID Sub-TLV carries an IGP Prefix SID, then the G-flag 201 MUST be set. 203 Other bits: MUST be zero when originated and ignored when 204 received. 206 Prefix Segment Identifier (SID): 32 bits of Prefix-SID. 208 Multiple Prefix-SIDs MAY appear on the same prefix in which case each 209 SID is encoded as a tuple . When multiple Prefix- 210 SIDs are present, the receiving router MUST use the first encoded SID 211 and MAY use the subsequent ones. 213 The No-PHP flag MUST be set on the Prefix-SIDs allocated to Level-2 214 prefixes that are originated by the router based on Level-1 215 reachability (i.e.: prefixes that are propagated from Level-1 into 216 Level-2). 218 The No-PHP flag MUST be set on Prefix-SIDs allocated to Level-1 219 prefixes that are originated by the router based on Level-2 220 reachability (i.e.: prefixes that are leaked from Level-2 into 221 Level-1). 223 The R-Flag MUST be set for prefixes that are advertised because of 224 propagation (Level-1 into Level-2), leaking (Level-2 into Level-1) 225 and redistribution (e.g.: from another protocol). 227 2.2. Adjacency Segment Identifier (Adj-SID) 229 A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub- 230 TLV (Adj-SID Sub-TLV). 232 The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment 233 Routing IGP-Adjacency-SID with flags and fields that may be used, in 234 future extensions of Segment Routing, for carrying other types of 235 SIDs. 237 IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs 238 below: 240 TLV-22 [RFC5305] 242 TLV-222 [RFC5120] 244 TLV-23 [RFC5311] 246 TLV-223 [RFC5311] 248 TLV-141 [RFC5316] 250 Currently, [RFC5316] defines TLV-141 with the purpose of inter-AS 251 connectivity. In the Segment Routing context, we relax the 252 constraint and we allow TLV-141 to be used for advertising any link 253 that is external to the IS-IS domain no matter if it connects another 254 AS or not. 256 Multiple Adj-SID Sub-TLVs MAY be associated with a single IS- 257 neighbor. Examples where more than one Adj-SID may be used per IS- 258 neighbor are described in 259 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 261 2.2.1. Adj-SID and Interface Address 263 When advertising one or more Adj-SID Sub-TLVs, the router MUST also 264 advertise Interface Address and Neighbor Address Sub-TLVs (IPv4 or 265 IPv6). The encoding is defined in [RFC5305] for IPv4 and in 266 [RFC6119] for IPv6. 268 2.2.2. Adj-SID and Forwarding Adjacencies 270 Forwarding Adjacencies are defined in [RFC4206] and allow a router to 271 advertise an MPLS RSVP-TE LSP as if it was a regular IS-IS adjacency. 273 Segment Routing supports FAs and Adj-SIDs can be assigned to FA 274 advertisements. A new sub-TLV (defined below) is introduced in order 275 to give the optional ability to advertise the explicit path 276 represented by a FA. 278 2.2.3. Adjacency Segment Identifier (Adj-SID) Sub-TLV 280 The following format is defined for the Adj-SID Sub-TLV: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Flags | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Adj-SID | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | ERO (optional and variable) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 where: 294 Type: TBA 296 Length: variable. 298 Flags: 2 octets field of following flags: 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |F|I|V|E|G|T| | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 where: 306 F-Flag: FA flag. Optional and, if set, then Adj-SID refers to 307 a Forwarding Adjacency. 309 I-Flag: IPv4 flag. Optional and, if set, then the Adj-SID 310 refers to an adjacency with outgoing IPv4 encapsulation. 312 V-Flag: IPv6 flag. Optional and, if set, then the Adj-SID 313 refers to an adjacency with outgoing IPv6 encapsulation. 315 E-Flag: ERO presence flag. Optional and, If set, it indicates 316 presence of the ERO object. 318 G-Flag: Global flag. When set, the SID value has global 319 significance which means the SID has been allocated from the 320 Segment Routing Global Block (SRGB) as described in 321 [draft-filsfils-rtgwg-segment-routing-00]. When unset, the SID 322 value has local (within the router) significance which means 323 the SID has NOT been allocated from the SRGB. When the IS-IS 324 Adj-SID Sub-TLV carries the IGP Adjacency SID, then the G-Flag 325 MUST be unset. 327 T-Flag: Protected-flag. Optional and, if set, the Adj-SID 328 refers to an adjacency being protected (e.g.: using IPFRR or 329 MPLS-FRR) as described in 330 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 332 Other bits: MUST be zero when originated and ignored when 333 received. 335 Adj-SID: 32 bits of Adjacency Segment Identifier (Adj-SID). 337 An SR capable router SHOULD allocate an Adj-SID for each of its 338 adjacencies and set the T-Flag when the adjacency is protected by 339 a FRR mechanism (IP or MPLS) as described in 340 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 342 If both the I and V flag are set, then the encapsulation MUST be 343 determined by the inspection of the first 4 bits of the IP packet 344 (IPv4 or IPv6). 346 Both the I and V flags are optional. When the I or V flags are 347 set, they take precedence over the I or V flags defined in 348 Section 3.1. 350 If the E-flag is set, then the explicit path taken by the Forwarding 351 Adjacency MUST be encoded using the following format: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Length | Flags | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Explicit Route Hop #1 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Explicit Route Hop #... | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | .... | 363 where: 365 Length: 1 octet of length of the ERO object. 367 Flags: 1 octet flag field where following flags are defined: 368 0 1 2 3 4 5 6 7 369 +-+-+-+-+-+-+-+-+ 370 |I|V|R| | 371 +-+-+-+-+-+-+-+-+ 373 where: 375 I-Flag is the IPv4 flag. When set the content of the Explicit 376 Route Object contains IPv4 addresses. 378 V-Flag is the IPv6 flag. When set the content of the Explicit 379 Route Object contains IPv6 addresses. 381 R-Flag is the Segment Routing flag. When set the content of 382 the Explicit Route Object contains SIDs. 384 Explicit Route Hop: addresses of the explicit route. IPv4 and SR 385 hops are encoded using a 32 bit value while IPv6 hops are encoded 386 as 128 bit values. 388 Only one flag MUST be set among the I, V and R flags. If more 389 than one are set , the receiving router MUST ignore the ERO object 390 and SHOULD log an error. 392 2.2.4. Adjacency Segment Identifiers in LANs 394 In LAN subnetworks, the Designated Intermediate System (DIS) is 395 elected and originates the Pseudonode-LSP (PN-LSP) including all 396 neighbors of the DIS. 398 When Segment Routing is used, each router in the LAN MUST advertise 399 the Adj-SID of each of its neighbors. Since, on LANs, each router 400 only advertises one adjacency to the DIS (and doesn't advertise any 401 other adjacency), each router advertises the set of Adj-SIDs (for 402 each of its neighbors) inside a newly defined Sub-TLV part of the TLV 403 advertising the adjacency to the DIS (e.g.: TLV-22). 405 Inside the Adj-SID Sub-TLV described in Section 2.2.3 the following 406 new Sub-TLV is defined: LAN-Adj-SID which contains the set of Adj- 407 SIDs the router assigned to each of its LAN neighbors. The format of 408 the LAN-Adj-SID Sub-TLV is as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Length | Flags | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Adj-SID #1 (4 octets) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | System-ID #1 (6 octets) | 418 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | .... 423 | .... | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Adj-SID #n (4 octets) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | System-ID #n | 428 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 where: 434 Type: TBA. 436 Length: is 2 + multiple of 10 octets. 438 Flags: 2 octets field of following flags: 439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |I|V|T| | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 where: 446 I-Flag: IPv4 flag. If set, then the Adj-SID refers to an 447 adjacency with outgoing SR IPv4 encapsulation. 449 V-Flag: IPv6 flag. If set, then the Adj-SID refers to an 450 adjacency with outgoing SR IPv6 encapsulation. 452 T-Flag: Protected-flag: set if the LAN interface is being 453 protected (e.g.: using IPFRR or MPLS-FRR) as described in 454 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 456 Other bits: MUST be zero when originated and ignored when 457 received. 459 Adj-SID: 32 bits of SID. 461 System-ID: IS-IS System-ID of length "ID Length" as defined in 462 [ISO10589]. 464 Multiple tuples SHOULD be encoded in one Sub- 465 TLV. 467 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 468 can't contain the whole set of Adj-SID Sub-TLVs, multiple 469 advertisement of the adjacency to the DIS MUST be used. 471 Each router within the level, by receiving the DIS PN LSP as well as 472 the non-PN LSP of each router in the LAN, is capable of 473 reconstructing the LAN topology as well as the set of Adj-SID each 474 router uses for each of its neighbors. 476 3. Segment Routing Capabilities 478 Segment Routing requires each router to advertise its capabilities to 479 the rest of the routing domain. IS-IS Router Capability TLV-242 is 480 defined in [RFC4971] and describes the router capabilities. For the 481 purposes of Segment Routing we define following additional Sub-TLVs: 483 Segment Routing Capability Sub-TLV (SR-Cap) 485 Segment Routing Mapping Server Sub-TLV (SRMS) 487 Segment Routing Mirroring Context SID Sub-TLV (SRMC) 489 The Router Capability TLV specifies flags that control its 490 advertisement. The SR-Cap, SRMS and SRMC Sub-TLVs MUST be propagated 491 throughout the entire routing domain and therefore the Router 492 Capability TLV distribution flags MUST be set accordingly, i.e.: the 493 S flag must be set and the D flag MUST be set when the Capability TLV 494 is leaked into level-1. 496 3.1. Segment Routing Capability Sub-TLV (SR-Cap) 498 The SR-Cap Sub-TLV is advertised by the SR-capable router in order to 499 advertise its support of SR signaling. 501 The SR-Cap Sub-TLV MUST appear only once and has following format: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length | Flags | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | First SID Value | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Last SID Value | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 where: 515 Type: TBA. 517 Length: 2 octets + 8 octets if SID Values are advertised. 519 Flags: 2 octets field of following flags: 520 0 1 521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |X|M|I|V| | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 where: 528 X-Flag: Index flag. If set, then each SID with the G-Flag set 529 that is advertised by this router represents an index in the 530 label space also advertised by this router (using the encodings 531 defined below). Indexed SID values are described in 532 [draft-filsfils-rtgwg-segment-routing-00]. If the X-Flag is 533 not set, then SID values 0-63 are reserved and MUST NOT be used 534 by the SR control plane for either node or adjacency segments. 535 Any SID which is received with a value 0-63 and the X-Flag 536 unset MUST be ignored and the router SHOULD log an error. 538 M-Flag: SID space flag. If set, the router advertises SID 539 space. 541 I-Flag: IPv4 flag. If set, then the router is capable of 542 outgoing IPv4 encapsulation on all interfaces. 544 V-Flag: IPv6 flag. If set, then the router is capable of 545 outgoing IPv6 encapsulation on all interfaces. 547 Other bits: MUST be zero when originated and ignored when 548 received. 550 First SID Value and Last SID Value represent the local SID range 551 of the router. The semantic and procedures of these values are 552 described in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 554 I-Flag and V-Flag define the outgoing encapsulations the router is 555 capable of on all its interfaces. The equivalent flags are defined 556 in Section 2.2.3 and allow to advertise interface-specific outgoing 557 encapsulation overriding the one advertised in the SR-Cap Sub-TLV. 559 3.2. Segment Routing Mapping Server 561 One or more SR capable routers may act as a Segment Routing Mapping 562 Server (SRMS). 564 One example (but not limited to) of SR Mapping Server use is when 565 some of the routers in the network do not support Segment Routing and 566 therefore they won't advertise any Prefix-SID. In such case the SRMS 567 advertises the mappings on behalf of the non-SR capable routers. 569 The details on the Segment Routing Mapping Server capability are 570 described in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 572 3.2.1. SR Mapping Server Sub-TLV 574 The SR Mapping Server Sub-TLV (SRMS Sub-TLV) is used in order to 575 advertise Prefix-SID mappings on behalf of routers. The SRMS Sub-TLV 576 is optional and MAY appear more than once in the Router Capability 577 TLV. 579 The SRMS Sub-TLV has the following format: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type | Length | Flags | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | ... | 587 where: 589 Type: TBD. 591 Length: variable. 593 Flags. Following flags are defined: 595 0 1 596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |I|V|R| | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 where: 603 I-flag: IPv4 flag. If set then the carried mappings refer to 604 an IPv4 prefix. 606 V-flag: IPv6 flag. If set then the carried mappings refer to 607 an IPv6 prefix. 609 R-Flag: Range flag. When set, the mappings are expressed using 610 range values. 612 The combination of the I, V flags with the R flag tells the Address 613 Family and type of encodings. When the R-flag is not set, the 614 following encoding format is used: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type | Length | Flags | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Masklength and Prefix #1 (variable length) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Prefix-SID #1 (4 octet length) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | ... | 626 | ... | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Masklength and Prefix #n (variable length) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Prefix-SID #n (4 octet length) | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 where: 635 Masklength and Prefix: the prefix to be mapped into a Prefix-SID 636 consisting of 1 octet of prefix length followed by 0 to 16 octets 637 of IPv4 or IPv6 prefix (determined by the I and V flags). 639 Prefix-SID: 4 octet Node Segment Identifier mapped to the prefix. 641 The 8 bits of prefix length can have the values 0-128 and indicate 642 the number of significant bits in the prefix. The prefix is encoded 643 in the minimal number of octets for the given number of significant 644 bits as follows: 646 Prefix octets = integer of ((prefix length + 7) / 8) 648 The range option (the R bit) provides the ability to specify a range 649 of addresses and the associated Prefix-SIDs. In fact, then the R bit 650 allows to specify the first address, the number of addresses that 651 need to be mapped into a Prefix-SID and the starting value of the 652 Prefix-SID range. 654 Therefore, with the R bit set, the following encoding is used: 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Type | Length | Flags | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | First Masklength and Prefix #1 (variable length) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | First Prefix-SID #1 (4 octets) | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Range Size #1 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | ... | 667 ... 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | First Masklength and Prefix #n (variable length) | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | First Prefix-SID #n (4 octets) | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Range Size #n | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 For example, if the following router addresses (loopback addresses) 678 need to be mapped into the corresponding Prefix-SIDs: 679 Router-A: 192.0.2.1/32, Prefix-SID: 1001 680 Router-B: 192.0.2.2/32, Prefix-SID: 1002 681 Router-C: 192.0.2.3/32, Prefix-SID: 1003 682 Router-D: 192.0.2.4/32, Prefix-SID: 1004 684 The R-bit allows the following encoding: 686 First Masklength and Prefix: 687 1 octet of length with value: 32 688 4 octets of prefix with value: 192.0.2.1 690 First Prefix-SID: 691 4 octets of Prefix-SID with value: 1001 693 Range Size: 694 2 octets with value: 4 696 The Segment Routing Mapping Server MUST NOT advertise overlapping 697 ranges or Prefix-SID mappings. In case of overlap, the receiver 698 SHOULD log an error and ignore the smaller range or the specific 699 Prefix-SID mapping which is part of a range. 701 3.3. Segment Routing Mirroring Context Sub-TLV (SRMC) 703 The SRMC Sub-TLV allows a node (called the mirroring node) to 704 advertise its capability to mirror another node (called the mirrored 705 node). The mirroring node is identified by its IPv4/IPv6 address or 706 its related Prefix-SID. The mirroring node advertises in the SRMC 707 Sub-TLV the context segment that needs to be used in order to invoke 708 its mirroring service for the mirrored node. 710 Examples of mirroring services use cases are defined in 711 [draft-filsfils-segment-routing-use-cases] and 712 [I-D.minto-rsvp-lsp-egress-fast-protection]. 714 The SRMC Sub-TLV is optional and MAY be present in the Router 715 Capability TLV (TLV-242), MAY appear more than once and has following 716 format: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | SRMC Flags | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Mirrored Address (variable) | 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Context-SID (4 octets) | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 where: 731 Type: TBA. 733 Length: variable. 735 SRMC Flags: 2 octets field of flags. Following flags are defined: 736 0 1 737 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |I|V|R| | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 where: 744 I-flag: IPv4 flag. If set, the Mirrored Address is an IPv4 745 address. 747 V-flag: IPv6 flag. If set, the Mirrored Address is an IPv6 748 address. 750 R-flag: Segment Routing Identifier. If set, the Mirrored 751 Address is a SID. 753 Other bits: MUST be zero when originated and ignored when 754 received. 756 Mirrored Address: the IPv4 or IPv6 or SID value representing the 757 mirrored element. 759 Context-SID: 32 bit value of Segment Identifier for the Mirroring 760 Service. 762 4. IANA Considerations 764 TBD 766 5. Manageability Considerations 768 TBD 770 6. Security Considerations 772 TBD 774 7. Acknowledgements 776 We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart 777 Bryant, Hannes Gredler, Pierre Francois and Martin Horneffer for 778 their contribution to the content of this document. 780 8. References 782 8.1. Normative References 784 [ISO10589] 785 International Organization for Standardization, 786 "Intermediate system to Intermediate system intra-domain 787 routeing information exchange protocol for use in 788 conjunction with the protocol for providing the 789 connectionless-mode Network Service (ISO 8473)", ISO/ 790 IEC 10589:2002, Second Edition, Nov 2002. 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 796 Hierarchy with Generalized Multi-Protocol Label Switching 797 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 799 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 800 System to Intermediate System (IS-IS) Extensions for 801 Advertising Router Information", RFC 4971, July 2007. 803 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 804 Topology (MT) Routing in Intermediate System to 805 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 807 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 808 Engineering", RFC 5305, October 2008. 810 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 811 October 2008. 813 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 814 "Simplified Extension of Link State PDU (LSP) Space for 815 IS-IS", RFC 5311, February 2009. 817 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 818 Support of Inter-Autonomous System (AS) MPLS and GMPLS 819 Traffic Engineering", RFC 5316, December 2008. 821 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 822 Engineering in IS-IS", RFC 6119, February 2011. 824 8.2. Informative References 826 [I-D.minto-rsvp-lsp-egress-fast-protection] 827 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 828 egress fast-protection", 829 draft-minto-rsvp-lsp-egress-fast-protection-02 (work in 830 progress), April 2013. 832 [I-D.previdi-filsfils-isis-segment-routing] 833 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 834 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 835 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 836 Routing with IS-IS Routing Protocol", 837 draft-previdi-filsfils-isis-segment-routing-02 (work in 838 progress), March 2013. 840 [draft-filsfils-rtgwg-segment-routing-00] 841 Previdi, S. and C. Filsfils, "Segment Routing", May 2013. 843 [draft-filsfils-rtgwg-segment-routing-use-cases-00] 844 Filsfils, C., "Segment Routing Use Cases", May 2013. 846 Authors' Addresses 848 Stefano Previdi (editor) 849 Cisco Systems, Inc. 850 Via Del Serafico, 200 851 Rome 00142 852 Italy 854 Email: sprevidi@cisco.com 856 Clarence Filsfils 857 Cisco Systems, Inc. 858 Brussels, 859 BE 861 Email: cfilsfil@cisco.com 862 Ahmed Bashandy 863 Cisco Systems, Inc. 864 170, West Tasman Drive 865 San Jose, CA 95134 866 US 868 Email: bashandy@cisco.com 870 Bruno Decraene 871 Orange 872 FR 874 Email: bruno.decraene@orange.com 876 Stephane Litkowski 877 Orange 878 FR 880 Email: stephane.litkowski@orange.com 882 Rudiger Geib 883 Deutsche Telekom 884 DE 886 Email: Rudiger.Geib@telekom.de 888 Igor Milojevic 889 Telekom Srbija 890 Takovska 2 891 Belgrade 892 RS 894 Email: igormilojevic@telekom.rs 896 Rob Shakir 897 British Telecom 898 London 899 UK 901 Email: rob.shakir@bt.com 902 Saku Ytti 903 TDC Oy 904 Mechelininkatu 1a 905 TDC 00094 906 FI 908 Email: saku@ytti.fi 910 Wim Henderickx 911 Alcatel-Lucent 912 Copernicuslaan 50 913 Antwerp 2018 914 BE 916 Email: wim.henderickx@alcatel-lucent.com 918 Jeff Tantsura 919 Ericsson 920 300 Holger Way 921 San Jose, CA 95134 922 US 924 Email: Jeff.Tantsura@ericsson.com