idnits 2.17.1 draft-bashandy-isis-srv6-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 125 has weird spacing: '...pplying such ...' == Line 277 has weird spacing: '...cleared accor...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2017) is 2603 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. '2' ** Obsolete normative reference: RFC 5226 (ref. '3') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5316 (ref. '7') (Obsoleted by RFC 9346) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-05 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy, Ed. 2 Internet Draft C. Filsfils 3 Intended status: Standard Track L. Ginsberg 4 Expires: September 2017 Cisco Systems 5 Bruno Decraene 6 Orange 7 March 10, 2017 9 IS-IS Extensions to Support Segment Routing over IPv6 Dataplane 10 draft-bashandy-isis-srv6-extensions-00 12 Abstract 14 Segment Routing (SR) allows for a flexible definition of end-to-end 15 paths by encoding paths as sequences of topological sub-paths, called 16 "segments". Segment routing architecture can be implemented over an 17 MPLS data plane as well as an IPv6 data plane. This draft describes 18 the IS-IS extensions required to support Segment Routing over an IPv6 19 data plane. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 This document may contain material from IETF Documents or IETF 27 Contributions published or made publicly available before November 28 10, 2008. The person(s) controlling the copyright in some of this 29 material may not have granted the IETF Trust the right to allow 30 modifications of such material outside the IETF Standards Process. 31 Without obtaining an adequate license from the person(s) 32 controlling the copyright in such materials, this document may not 33 be modified outside the IETF Standards Process, and derivative 34 works of it may not be created outside the IETF Standards Process, 35 except to format it for publication as an RFC or to translate it 36 into languages other than English. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other 45 documents at any time. It is inappropriate to use Internet-Drafts 46 as reference material or to cite them other than as "work in 47 progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on September 10, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction...................................................3 74 1.1. Conventions used in this document.........................3 75 2. SRv6-Capabilities sub-TLV......................................4 76 3. SRv6-function Descriptor.......................................6 77 4. SRv6-SID TLV...................................................7 78 5. Function Code points...........................................8 79 6. Advertising SRv6 SIDs associated with a Neighbor...............8 80 6.1. P2P SRv6 X-SID sub-TLV....................................9 81 6.2. LAN SRv6 X-SID sub-TLV...................................10 82 7. IANA Considerations...........................................11 83 7.1. SRv6 SID TLV and sub-TLVs................................11 84 7.2. IS-IS SRv6-functions Codepoints Registry.................12 85 7.3. SRv6 Capabilities sub-TLV................................12 86 7.4. P2P SRv6 X-SID and LAN SRv6 X-SID sub-TLVs...............12 87 7.5. IS-IS SRv6 X-SID sub-sub-TLV Codepoints Registry.........13 88 8. Security Considerations.......................................13 89 9. Contributors..................................................13 90 10. References...................................................14 91 10.1. Normative References....................................14 92 10.2. Informative References..................................15 93 11. Acknowledgments..............................................16 95 1. Introduction 97 With Segment Routing (SR)[9], a node steers a packet through an 98 ordered list of instructions, called segments. 100 Segments are identified through Segment Identifiers (SIDs). 102 Segment Routing can be directly instantiated on the IPv6 data plane 103 through the use of the Segment Routing Header defined in [10]. SRv6 104 refers to this SR instantiation on the IPv6 dataplane. 106 The network programming paradigm [11] is central to SRv6. 108 It describes how any function can be bound to a SID and how any 109 network program can be expressed as a combination of SID's. 111 It defines several well-known functions such as End, End.X, 112 T.Insert, T.Encaps, etc. 114 This document specifies IS-IS extensions that allow IS-IS protocol 115 to encode some of these functions. 117 Familiarity with the network programming paradigm [11] is necessary 118 to understand the extensions specified in this document. 120 This document defines one new top level IS-IS_TLV and three new IS- 121 IS sub-TLVs. 123 The SRv6 Capabilities sub-TLV announces the ability to support SRv6 124 and some functions defined in [11] as well as advertising 125 limitations when applying such functions. 127 The SRv6 SID top level TLV, the P2P SRv6 X-SID sub-TLV, and the LAN 128 SRv6 X-SID sub-TLV are used to advertise which SIDs are instantiated 129 at a node and what function is bound to each instantiated SID. 131 Only ISIS-related functions such as End and its variants D and X 132 [11] are defined in this document. 134 1.1. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 137 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 138 in this document are to be interpreted as described in RFC-2119 139 [8]. 141 In this document, these words will appear with that interpretation 142 only when in ALL CAPS. Lower case uses of these words are not to 143 be interpreted as carrying RFC-2119 [8] significance. 145 2. SRv6-Capabilities sub-TLV 147 As described in [10] and [11], the list of Segments is stored in the 148 segment routing header referred hereafter as "SRH". 150 A router that supports SRv6 MUST be able to process the segment 151 routing header as described in [10] and [11] up to the limitations 152 set by the advertised SRv6-capabilities sub-TLV. 154 To announce this ability, a router uses the newly defined SRv6- 155 capabilities sub-TLV of the router capabilities TLV [1]. The SRv6- 156 capabilities sub-TLV may contain optional sub-sub-TLVs in the 157 future. 159 The SRv6 Capabilities sub-TLV has the following format: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | Flags | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | max-SL |Max-End-Pop-SRH| Max-T-Ins-SRH |Max-T-Encap-SRH| 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | max-End-D-SRH | 169 +-+-+-+-+-+-+-+-+ 171 Type: Suggested value 22, to be assigned by IANA 173 Length: 7 + length of sub-sub-TLVs 175 Flags: 2 octets The following flags are defined: 177 0 1 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |E| | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 where: 185 E-flag: If set, then router is able to apply "T.Encap" 186 operation 188 Max-SL: 1 octet. 190 This field specifies the maximum value of the "SL" field [10] in 191 the SRH of a received packet before applying the function 192 associated with a SID. 194 Max-End-Pop-SRH: 1 Octet 196 This field specifies the maximum number of SIDs in the top SRH in 197 an SRH stack that the router can apply "PSP" or USP" [11] flavors 198 to. If the value of this field is zero, then the router cannot 199 apply PSP or USP flavors. 201 Max-T-Ins-SRH: 1 octet 203 This field specifies the maximum number of SIDs that can be 204 inserted as part of the "T.insert" behavior [11]. If the value of 205 this field is zero, then the router cannot apply any variation of 206 the "T.insert" behavior. 208 Max-T-Encap-SRH: 1 octet 210 This field specifies the maximum number of SIDs that can be 211 included as part of the "T.Encap" behavior [11]. If this field is 212 zero and the "E" flag is set, then the router can apply T.Encap 213 by encapsulating the incoming packet in another IPv6 header 214 without SRH the same way IPinIP encapsulation is performed. If 215 the "E" flag is clear, then this field SHOULD be transmitted as 216 zero and MUST be ignored on receipt. 218 max-End-D-SRH: 1 octet 220 This field specifies the maximum number of SIDs in an SRH when 221 applying "End.DX6" and "End.DT6" functions. If this field is 222 zero, then the router cannot apply "End.DX6" or "End.DT6" 223 functions if the extension header right underneath the outer IPv6 224 header is an SRH. 226 3. SRv6-function Descriptor 228 The SRv6 SID TLV defined in Section 4, P2P SRv6 X-SID sub-TLV 229 specified in Section 6.1, and LAN SRv6 X-SID sub-TLV specified in 230 section 6.2 MUST include one SRv6 function Descriptor. 232 When included in the SRv6 SID TLV, the descriptor is encoded as a 233 sub-TLV. When included in a P2P/LAN SRv6 X-SID sub-TLV, the 234 descriptor is encoded as a sub-sub-TLV. 236 The SRv6-function Descriptor encodes the function (and its flavors) 237 bound to the SRv6 SID advertised in the SRv6 SID TLV [11]. 239 The SRv6 SID function Descriptor has the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | Behavior (variable) .. 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Type: See IANA considerations in Section 7. 249 Length: 3 * (number of functions) 251 Behavior: One function (with its associated flavors) encoded in 3 252 octets as shown in the following diagram 254 0 1 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |P|U| Reserved | Function | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 The first octet encodes flags. This document defines two flags to 261 specify the flavor(s) [11] associated with the SRv6 function 262 specified in the "Function" field: 264 P bit: If set, then the PSP flavor [11] is associated with the 265 function encoded in the "function" field 267 U bit: If set, then the USP flavor [11] is associated with the 268 function encoded in the "function" field 270 Reserved Bits SHOULD be transmitted as 0 and MUST be ignored on 271 receipt. 273 The second two octets encode the function. Function code points 274 are defined in Section 5. 276 For a given SRv6 SID function encoded in the "Function" field, 277 the "P" and "U" bits are set/cleared according to the rules of 278 enabling/disabling the PSP and USP flavors, respectively, for 279 that function as specified in [11]. 281 4. SRv6-SID TLV 283 A new top level TLV is introduced to advertise SRv6 Segment 284 Identifiers (SID) and their attributes. 286 The new TLV is used to advertise SRv6 SIDs with any of the functions 287 defined in [11] whose code point is defined in this document except 288 those SIDs which must be associated with a particular neighbor in 289 order to be correctly applied [11]. SRv6 SIDs associated with a 290 neighbor are advertised in the sub-TLVs defined in Section 6. 292 This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 293 and 237. 295 The SRv6 SID TLV has the following format 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | flags | SID-size | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | SID (variable) . . . | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | sub-tlv-len | Sub-TLVs (variable) . . . | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Type: 27 (Suggested value to be assigned by IANA) 309 Length: variable. 311 One or more SID entries, each of which has the following format: 313 Flags: 1 octet. The following flags are defined 315 0 316 0 1 2 3 4 5 6 7 317 +-+-+-+-+-+-+-+-+ 318 |D| Reserved | 319 +-+-+-+-+-+-+-+-+ 321 where: 323 D bit: When the SID is leaked from level-2 to level-1, the D 324 bit MUST be set. Otherwise, this bit MUST be clear. SIDs with 325 the D bit set MUST NOT be leaked from level-1 to level-2. This 326 is to prevent looping. 328 The remaining bits are reserved for future use. They SHOULD be 329 set to zero on transmission and MUST be ignored on receipt. 331 SID-Size: 1 octet. Number of bits in the SID field. 333 SID: 1-16 octets. This field encodes the advertised SRv6 SID. The 334 "SID-size" field can have the values 1-128 and indicates the 335 number of bits in the SID. The SRv6 SID is encoded in the 336 minimal number of octets for the given number of bits. The owning 337 router may associate one or more functions as specified in [11], 338 in other documents, or as locally configured. 340 Sub-TLV-length: 1 octet. Number of octets used by sub-TLVs 342 The function associated with the advertised SID is specified by 343 the SRv6-Function Descriptor sub-TLV specified in Section 3. 345 5. Function Code points. 347 This section defines the code points for supported functions 348 associated with SRv6 SIDs. Functions are defined in [11]. 350 o 0: Reserved 352 o 1: End Function. 354 o 2: End.DX6 Function. 356 o 3: End.DT6 Function. 358 o 4: End.X Function. 360 6. Advertising SRv6 SIDs associated with a Neighbor. 362 Certain SRv6 functions [11] must be associated with a particular 363 neighbor, and in case of multiple layer 3 links to the same 364 neighbor, with a particular link in order to be correctly applied. 366 This document specifies how to advertise two such functions in IS- 367 IS, namely End.X and End.DX6 [11]. 369 SIDs associated with End.X and End.DX6 functions are advertised 370 within neighbor reachability TLVs. 372 This document defines two new sub-TLVs of TLV 22 [4], 23 [6], 222 373 [5], 223[6], and 141 [7] namely "P2P SRv6 X-SID" and "LAN SRv6 X- 374 SID". 376 6.1. P2P SRv6 X-SID sub-TLV 378 This sub-TLV is used to advertise one or more SRv6 SIDs associated 379 with End.X and End.DX6 [11] functions over a point to point 380 adjacency. 382 The "P2P SRv6 X-SID" sub-TLV has the following format 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Length | Flags | SID-size | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | SID (variable) . . . | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |sub-sub-tlv-len| Sub-sub-TLVs (variable) . . . | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Type: 40 (Suggested value to be assigned by IANA) 395 Length: variable. 397 One or more SIDs each of which has the following format: 399 Flags: 1 octet. No flags defined in this document 401 SID-Size: 1 octet. Number of bits in the SID field. 403 SID: 1-16 octets. This field encodes the advertised SRv6 SID. The 404 "SID-size" field can have the values 1-128 and indicates the 405 number of bits in the SID. The SRv6 SID is encoded in the 406 minimal number of octets for the given number of bits. The owning 407 router may associate one or more functions as specified in [11], 408 in other documents, or as locally configured. 410 Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub- 411 TLVs 413 The function associated with the advertised SID is specified by the 414 SRv6-Function Descriptor sub-sub-TLV specified in Section 3. If the 415 SRv6-Function Descriptor is encoded in the P2P SRv6 X-SID sub-TLV, 416 then the encoded SRv6 SID function MUST include only the code points 417 of SRv6 SID functions that require the specification of a neighbor 418 to be correctly applied. This document specifies the code points of 419 two such functions, namely End.X and End.DX6 [11]. 421 6.2. LAN SRv6 X-SID sub-TLV 423 This sub-TLV is used to advertise one or more SRv6 SIDs associated 424 with End.X and End.DX6 [11] functions over a LAN adjacency. The "LAN 425 SRv6 X-SID" sub-TLV has the following format 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | System ID (6 octets) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Flags | SID-size | SID (variable) . . . | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |sub-sub-tlv-len| sub-sub-TLVs (variable) . . . | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Type: 41 (Suggested value to be assigned by IANA) 441 Length: variable. 443 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 444 defined in [2]. 446 One or more SIDs each of which has the following format: 448 Flags 1 Octet. No flags are defined in this document 450 SID-Size: 1 octet. Number of bits in the SID field. 452 SID: 1-16 octets. This field encodes the advertised SRv6 SID. The 453 "SID-size" field can have the values 1-128 and indicates the 454 number of bits in the SID. The SRv6 SID is encoded in the 455 minimal number of octets for the given number of bits. The owning 456 router may associate one or more functions as specified in [11], 457 in other documents, or as locally configured. 459 Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub- 460 TLVs 462 The function associated with the advertised SID is specified by the 463 SRv6-Function Descriptor sub-sub-TLV specified in Section 3. If the 464 SRv6-Function Descriptor is encoded in the P2P SRv6 X-SID sub-TLV, 465 then the encoded SRv6 SID function MUST include only the code points 466 of SRv6 SID functions that require the specification of a neighbor 467 to be correctly applied. This document specifies the code points of 468 two such functions, namely End.X and End.DX6 [11]. 470 7. IANA Considerations 472 This documents request allocation for the following TLVs, sub- 473 TLVs, and sub-sub-TLVs as well updating the ISIS TLV registry and 474 defining a new registry. 476 7.1. SRv6 SID TLV and sub-TLVs 478 This document adds the following new TLV to the IS-IS TLV Codepoints 479 registry. 481 Value: 27 (suggested - to be assigned by IANA) 483 Name: SRv6 SID 485 The name of the "Sub-TLVs for TLVs 135, 235, 236 and 237 registry" 486 needs to be changed to "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 487 registry". 489 This document adds a new sub-TLV to the (renamed) "Sub-TLVs for TLVs 490 27, 135, 235, 236 and 237 registry". 492 Value: 5 (Suggested - to be assigned by IANA) 494 Name: SRv6-function Descriptor 496 The revised table of sub-TLVs in the registry should be: 498 Type 27 135 235 236 237 500 1 n y y y y 502 2 n y y y y 504 3 y y y y y 506 4 y y y y y 508 5(new)y n n n n 510 11 y y y y y 511 12 y y y y y 513 7.2. IS-IS SRv6-functions Codepoints Registry 515 This document requests the creation of a new IANA managed registry 516 to identify SRv6 SID functions. The registration procedure is 517 "Expert Review" as defined in [3]. Suggested registry name is "SRv6 518 SID Function Types". A function identifier is an unsigned 8 bits 519 value. The following values are defined by this document: 521 0 Reserved 523 1 End function. 525 2 End.DX6 function. 527 3 End.DT6 function. 529 4 End.X function. 531 7.3. SRv6 Capabilities sub-TLV 533 This document adds the definition of a new sub-TLV in the "Sub- 534 TLVs for TLV 242 registry". 536 Type: 22 (Suggested - to be assigned by IANA) 538 Description: SRv6 Capabilities 540 7.4. P2P SRv6 X-SID and LAN SRv6 X-SID sub-TLVs 542 This document adds the definition of two new sub-TLVs in the "sub- 543 TLVs for TLV 22, 23, 141, 222 and 223 registry". 545 Type: 40 (suggested - to be assigned by IANA) 547 Description: Point-to-Point SRv6 X-SID 549 Type: 41 (suggested - to be assigned by IANA) 551 Description: LAN SRv6 X-SID 553 Type 22 23 141 222 223 555 40 y y y y y 557 41 y y y y y 558 7.5. IS-IS SRv6 X-SID sub-sub-TLV Codepoints Registry 560 This document requests the creation of a new IANA managed registry 561 to identify SRv6 SID functions encoded in P2P/LAN X-SID sub-TLVs. 562 The registration procedure is "Expert Review" as defined in [3]. 563 Suggested registry name is "SRv6 X-SID sub-sub-TLV Codepoints 564 Registry". The following values are defined by this document: 566 Value: 5 (Suggested - to be assigned by IANA) 568 Name: SRv6-function Descriptor 570 This sub-sub-TLV MAY appear in either the Point-to-Point SRv6 X-SID 571 or the LAN SRv6 X-SID sub-TLVs described in Section 7.4. 573 8. Security Considerations 575 TBD 577 9. Contributors 579 The following people gave a substantial contribution to the content 580 of this document and should be considered as co-authors: 582 Stefano Previdi (editor) 583 Cisco Systems, Inc. 584 Via Del Serafico, 200 585 Rome 00142 586 Italy 588 Email: sprevidi@cisco.com 590 Peter Psenak 591 Cisco Systems 592 Apollo Business Center Mlynske nivy 43 593 Bratislava 821 09 594 Slovakia 596 Email: ppsenak@cisco.com 598 Paul Wells 599 Cisco Systems 600 Saint Paul, 601 Minisota, 602 United States 604 Email: pauwells@cisco.com 605 Daniel Voyer 606 Email: daniel.voyer@bell.ca 608 Satoru Matsushima 609 Email: satoru.matsushima@g.softbank.co.jp 611 Bart Peirens 612 Email: bart.peirens@proximus.com 614 Hani Elmalky 615 Email: hani.elmalky@ericsson.com 617 Prem Jonnalagadda 618 Email: prem@barefootnetworks.com 620 Milad Sharif 621 Email: msharif@barefootnetworks.com> 623 Robert Hanzl 624 Cisco Systems 625 Millenium Plaza Building, V Celnici 10, Prague 1, 626 Prague, Czech Republic 627 Email rhanzl@cisco.com 629 10. References 631 10.1. Normative References 633 [1] Previdi, S., Ginsberg, L., Chen, M., IS-IS Extensions for 634 Advertising Router Information", RFC7981, October 2016 636 [2] International Organization for Standardization, "Intermediate 637 system to Intermediate system intra-domain routeing information 638 exchange protocol for use inconjunction with the protocol for 639 providing theconnectionless-mode Network Service (ISO 8473)", 640 ISO/IEC 10589:2002, Second Edition, Nov 2002. 642 [3] T Narten and H. Alvestrand, "Guidelines for Writing an IANA 643 Considerations Section in RFCs", RFC5226, May 2008 645 [4] T. Li, "IS-IS Extensions for Traffic Engineering", RFC5305, 646 October 2008 648 [5] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: MultiTopology 649 (MT) Routing in Intermediate System to Intermediate Systems 650 (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, 651 . 653 [6] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, 654 "Simplified Extension of Link State PDU (LSP) Space for IS-IS", 655 RFC 5311, DOI 10.17487/RFC5311, February 2009, . 658 [7] M. Chen, R. Zhang, X. Duan, "ISIS Extensions in Support of 659 Inter-Autonomous System (AS) MPLS and GMPLS Traffic 660 Engineering", RFC 5316, December 2008 662 [8] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 664 March 1997, . 666 10.2. Informative References 668 [9] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 669 Shakir, "Segment Routing Architecture", draft-ietf-spring- 670 segment-routing-11 (work in progress), Feb 2017. 672 [10] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., 673 Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 674 Routing Header (SRH)", draft-ietf-6man-segment-routing-header- 675 05 (work in progress), Feb 2017. 677 [11] C. Fisfils, D. Voyer, D. Bernier, Bell Canada, D. Steinberg, R. 678 Raszuk, S. Matsushima, D. Lebrun, B. Decraene, B. Peirens, S. 679 Salsano, G. Naik, H. Elmalky, P. Jonnalagadda, M. Sharif, A. 680 Ayyangar, Force10 Networks, A. Bashandy, K. Raza, D. Dukes, F. 681 Clad, P. Camarillo, "SRv6 Network Programming", draft-filsfils- 682 spring-srv6-network-programming-00 (work in progress), May 2017 684 11. Acknowledgments 686 This document was prepared using 2-Word-v2.0.template.dot. 688 Authors' Addresses 690 Ahmed Bashandy 691 Cisco Systems 692 170 West Tasman Dr, San Jose, CA 95134, USA 694 Email: bashandy@cisco.com 696 Clarence Filsfils 697 Cisco Systems 698 Brussels, Belgium 700 Email: cfilsfil@cisco.com 702 Les Ginsberg 703 Cisco Systems, Inc. 704 US 706 Email: ginsberg@cisco.com 708 Bruno Decraene 709 Orange 710 Issy-les-Moulineaux 711 FR 713 Email: bruno.decraene@orange.com