idnits 2.17.1 draft-wu-idr-bgp-segment-allocation-ext-04.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 -- The document date (October 30, 2019) is 1633 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) == Unused Reference: 'I-D.ietf-idr-flowspec-path-redirect' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-bgp-routing-large-dc' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-ldp-interop' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'I-D.li-ospf-ospfv3-srv6-extensions' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'I-D.gredler-idr-bgp-ls-segment-routing-extension' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgpls-segment-routing-epe' is defined on line 651, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-flowspec-path-redirect-10 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-03 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-bgp-routing-large-dc (ref. 'I-D.ietf-rtgwg-bgp-routing-large-dc') == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-05 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-03 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track Z. Li 5 Expires: May 2, 2020 Huawei 6 Z. Li 7 China Mobile 8 Y. Fan 9 Casa Systems 10 M. Toy 11 Verizon 12 L. Liu 13 Fujitsu 14 October 30, 2019 16 BGP Extensions for IDs Allocation 17 draft-wu-idr-bgp-segment-allocation-ext-04 19 Abstract 21 This document describes extensions to the BGP for IDs allocation. 22 The IDs are SIDs for segment routing (SR), including SR for IPv6 23 (SRv6). They are distributed to their domains if needed. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 2, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Node SID NLRI TLV . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Link SID NLRI TLV . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Prefix SID NLRI TLV . . . . . . . . . . . . . . . . . . . 10 71 3.4. Capability Negotiation . . . . . . . . . . . . . . . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 7.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 In a network with a central controller, the controller has the link 83 state information of the network, including the resource such as 84 traffic enginerring and SIDs information. It is valuable for the 85 controller to allocate and manage the resources including SIDs of the 86 network in a centralized way, especially for the SIDs representing 87 network resources [I-D.ietf-teas-enhanced-vpn]. 89 When BGP as a controller allocates an ID, it is natural and 90 beneficial to extend BGP to send it to its corresponding network 91 elements. 93 PCE may be extended to send IDs to their corresponding network 94 elements after the IDs are allocated by a controller. However, when 95 BGP is already deployed in a network, using PCE for IDs will need to 96 deploy an extra protocol PCE in the network. This will increase the 97 CapEx and OpEx. 99 Yang may be extended to send IDs to their corresponding network 100 elements after the IDs are allocated by a controller. However, Yang 101 progress may be slow. Some people may not like this. 103 There may not be these issues when BGP is used to send IDs. In 104 addition, BGP may be used to distribute IDs into their domains easily 105 when needed. It is also fit for the dynamic and static allocation of 106 IDs. 108 This document proposes extensions to the BGP for sending Segment 109 Identifiers (SIDs) for segment routing (SR) including SRv6 to their 110 corresponding network elements after SIDs are allocated by the 111 controller. If needed, they will be distributed into their network 112 domains. 114 2. Terminology 116 The following terminology is used in this document. 118 SR: Segment Routing. 120 SRv6: SR for IPv6 122 SID: Segment Identifier. 124 IID: Indirection Identifier. 126 SR-Path: Segment Routing Path. 128 SR-Tunnel: Segment Routing Tunnel. 130 RR: Route Reflector. 132 MPP: MPLS Path Programming. 134 NAI: Node or Adjacency Identifier. 136 TED: Traffic Engineering Database. 138 3. Protocol Extensions 140 A new AFI and SAFI are defined: the Identifier AFI and the SID SAFI 141 whose codepoints are to be assigned by IANA. A few new NLRI TLVs are 142 defined for the new AFI/SAFI, which are Node, Link and Prefix SID 143 NLRI TLVs. When a SID for a node, link or prefix is allocated by the 144 controller, it may be sent to a network element in a UPDATE message 145 containing a MP_REACH NLRI with the new AFI/SAFI and the SID NLRI 146 TLV. When the SID is withdrawn by the controller, a UPDATE message 147 containing a MP_UNREACH NLRI with the new AFI/SAFI and the SID NLRI 148 TLV may be sent to the network element. 150 3.1. Node SID NLRI TLV 152 The Node SID NLRI TLV is used to represent the IDs such as SID 153 associated with a node. Its format is illustrated in the 154 Figure below, which is similar to the corresponding one defined in 155 [RFC7752]. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type (TBDa for Node SID) | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Protocol ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Identifier | 165 | (8 octets) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Peer IP (4/16 bytes for IPv4/IPv6 Address) ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 ~ Local Node Descriptors TLV ~ 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ~ Sub-TLVs ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Where: 176 Type (TBDa): It is to be assigned by IANA. 178 Length: It is the length of the value field in bytes. 180 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. When 181 receiving a UPDATE message, a BGP speaker processes it only if the 182 peer IP is the IP address of the BGP speaker or 0. 184 Protocol-ID, Identifier, and Local Node Descriptor: defined in 185 [RFC7752], can be reused. 187 Sub-TLVs may be some of the followings: 189 SR-Capabilities TLV (1034): It contains the Segment Routing Global 190 Base (SRGB) range(s) allocated for the node. 192 SR Local Block TLV (1036): The SR Local Block (SRLB) TLV contains 193 the range(s) of SIDs/labels allocated to the node for local SIDs. 195 SRv6 SID Node TLV (TBD1): A new TLV, called SRv6 Node SID TLV, 196 contains an SRv6 SID and related information. 198 SRv6 Locator TLV (TBD2): A new TLV, called SRv6 Locator TLV, 199 contains an SRv6 locator and related information. 201 The format of SRv6 SID Node TLV is illustrated below. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type (TBD1) | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Reserved | Flags | SRv6 Endpoint Function | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | SRv6 Identifier | 211 | (128 bits) | 212 | | 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 ~ Optional sub-TLVs ~ 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 SRv6 Node SID TLV 222 Type: TBD1 for SRv6 Node SID TLV is to be assigned by IANA. 224 Length: Variable. 226 Flags: 1 octet. No flags are defined now. 228 SRv6 Endpoint Function: 2 octets. The function associated with SRv6 229 SID. 231 SRv6 Identifier: 16 octets. IPv6 address representing SRv6 SID. 233 Reserved: MUST be set to 0 while sending and ignored on receipt. 235 SRv6 node SID inherits the topology and algorithm from its locator. 237 The format of SRv6 locator TLV is illustrated below. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type (TBD2) | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |R|R|R|R| MT-ID | Algorithm | Flags | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Metric | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Locator-Size | Locator (variable)... 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ Optional sub-TLVs ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 SRv6 Locator TLV 257 Type: TBD2 for SRv6 Locator TLV is to be assigned by IANA. 259 Length: Variable. 261 MT-ID: Multitopology Identifier as defined in [RFC5120]. 263 Algorithm: 1 octet. Associated algorithm. 265 Flags: 1 octet. As described in 266 [I-D.ietf-lsr-isis-srv6-extensions]. 268 Metric: 4 octets. As described in [RFC5305]. 270 Locator-Size: 1 octet. Number of bits in the Locator field (1 to 271 128). 273 Locator: 1 to 16 octets. SRv6 Locator encoded in the minimum number 274 of octets for the given Locator-Size. 276 Reserved: MUST be set to 0 while sending and ignored on receipt. 278 3.2. Link SID NLRI TLV 280 The Link SID NLRI TLV is used to represent the IDs such as SID 281 associated with a link. Its format is illustrated in the 282 Figure below, which is similar to the corresponding one defined in 283 [RFC7752]. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type (TBDb for Link SID) | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Protocol ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 ~ Identifier (8 octets) ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Peer IP (4/16 bytes for IPv4/IPv6 Address) ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ~ Local Node Descriptors TLV ~ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 ~ Remote Node Descriptors TLV ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ Link Descriptors TLV ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ Sub-TLVs ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Where: 307 Type (TBDb): It is to be assigned by IANA. 309 Length: It is the length of the value field in bytes. 311 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 313 Protocol-ID, Identifier, Local Node Descriptors, Remote Node 314 Descriptors and Link Descriptors: 315 defined in [RFC7752], can be reused. 317 The Sub-TLVs may be some of the followings: 319 Adj-SID TLV (1099): It contains the Segment Identifier (SID) 320 allocated for the link/adjacency. 322 LAN Adj-SID TLV (1100): It contains the Segment Identifier (SID) 323 allocated for the adjacency/link to a non-DR router on a 324 broadcast, NBMA, or hybrid link. 326 SRv6 Adj-SID TLV (TBD3): A new TLV, called SRv6 Adj-SID TLV, 327 contains an SRv6 Adj-SID and related information. 329 SRv6 LAN Adj-SID TLV (TBD4): A new TLV, called SRv6 LAN Adj-SID 330 TLV, contains an SRv6 LAN Adj-SID and related information. 332 The format of an SRv6 Adj-SID TLV is illustrated below. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type (TBD3) | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Weight | Algorithm |B|S|P| Flags | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Reserved | SRv6 Endpoint Function | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | SRv6 Identifier | 344 | (128 bits) | 345 | | 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 ~ Optional sub-TLVs ~ 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 SRv6 Adj-SID TLV 355 Type: TBD3 for SRv6 Adj-SID TLV is to be assigned by IANA. 357 Length: Variable. 359 Weight: 1 octet. The value represents the weight of the SID for the 360 purpose of load balancing. 362 Algorithm: 1 octet. Associated algorithm. 364 Flags: 2 octets. Three flags are defined in 365 [I-D.ietf-lsr-isis-srv6-extensions]. 367 SRv6 Endpoint Function: 2 octets. The function associated with SRv6 368 SID. 370 SRv6 Identifier: 16 octets. IPv6 address representing SRv6 SID. 372 Reserved: MUST be set to 0 while sending and ignored on receipt. 374 The format of an SRv6 LAN Adj-SID TLV is illustrated below. 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 (TBD4) | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Weight | Algorithm |B|S|P| Flags |O| 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Reserved | SRv6 Endpoint Function | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | neighbor Router ID (4 octets) / System ID (6 octets) ~ 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | SRv6 Identifier | 388 | (128 bits) | 389 | | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 ~ Optional sub-TLVs ~ 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 SRv6 LAN Adj-SID TLV 399 Type: TBD4 for SRv6 LAN Adj-SID TLV is to be assigned by IANA. 401 Length: Variable. 403 Weight: 1 octet. The value represents the weight of the SID for the 404 purpose of load balancing. 406 Algorithm: 1 octet. Associated algorithm. 408 Flags: 2 octets. Three flags B, S and P are defined in 409 [I-D.ietf-lsr-isis-srv6-extensions]. Flag O set to 1 indicating 410 OSPF neighbor Router ID of 4 octets, set to 0 indicating IS-IS 411 neighbor System ID of 6 octets. 413 SRv6 Endpoint Function: 2 octets. The function associated with SRv6 414 SID. 416 SRv6 Identifier: 16 octets. IPv6 address representing SRv6 SID. 418 Reserved: MUST be set to 0 while sending and ignored on receipt. 420 3.3. Prefix SID NLRI TLV 422 The Prefix SID NLRI TLV is used to represent the IDs such as SID 423 associated with a prefix. Its format is illustrated in the 424 Figure below, which is similar to the corresponding one defined in 425 [RFC7752]. 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 (TBDc for Prefix SID) | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Protocol ID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ~ Identifier (8 octets) ~ 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Peer IP (4/16 bytes for IPv4/IPv6 Address) ~ 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 ~ Local Node Descriptors TLV ~ 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 ~ Prefix Descriptors TLV ~ 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 ~ Sub-TLVs ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Where: 447 Type (TBDc): It is to be assigned by IANA. 449 Length: It is the length of the value field in bytes. 451 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 453 Protocol-ID, Identifier, Local Node Descriptors and Prefix 454 Descriptors: 455 defined in [RFC7752], can be reused. 457 Sub-TLVs may be some of the followings: 459 Prefix-SID TLV (1158): It contains the Segment Identifier (SID) 460 allocated for the prefix. 462 Prefix Range TLV (1159): It contains a range of prefixes and the 463 Segment Identifier (SID)s allocated for the prefixes. 465 3.4. Capability Negotiation 467 It is necessary to negotiate the capability to support BGP Extensions 468 for sending and receiving Segment Identifiers (SIDs). The BGP SID 469 Capability is a new BGP capability [RFC5492]. The Capability Code 470 for this capability is to be specified by the IANA. The Capability 471 Length field of this capability is variable. The Capability Value 472 field consists of one or more of the following tuples: 474 +--------------------------------------------------+ 475 | Address Family Identifier (2 octets) | 476 +--------------------------------------------------+ 477 | Subsequent Address Family Identifier (1 octet) | 478 +--------------------------------------------------+ 479 | Send/Receive (1 octet) | 480 +--------------------------------------------------+ 482 BGP SID Capability 484 The meaning and use of the fields are as follows: 486 Address Family Identifier (AFI): This field is the same as the one 487 used in [RFC4760]. 489 Subsequent Address Family Identifier (SAFI): This field is the same 490 as the one used in [RFC4760]. 492 Send/Receive: This field indicates whether the sender is (a) willing 493 to receive SID from its peer (value 1), (b) would like to send SID to 494 its peer (value 2), or (c) both (value 3) for the . 496 4. IANA Considerations 498 This document requests assigning a new AFI in the registry "Address 499 Family Numbers" as follows: 501 +-------------+---------------------+-------------+ 502 | Code Point | Description | Reference | 503 +-------------+---------------------+-------------+ 504 | TBDx | Identifier AFI |This document| 505 +-------------+---------------------+-------------+ 507 This document requests assigning a new SAFI in the registry 508 "Subsequent Address Family Identifiers (SAFI) Parameters" as follows: 510 +-------------+----------------------+-------------+ 511 | Code Point | Description | Reference | 512 +-------------+----------------------+-------------+ 513 | TBDy | SID SAFI |This document| 514 +-------------+----------------------+-------------+ 516 This document defines a new registry called "SID NLRI TLVs". The 517 allocation policy of this registry is "First Come First Served 518 (FCFS)" according to [RFC8126]. 520 Following TLV code points are defined: 522 +-------------+-----------------------------------+-------------+ 523 | Code Point | Description | Reference | 524 +-------------+-----------------------------------+-------------+ 525 | 1 (TBDa) | Node SID NLRI |This document| 526 +-------------+-----------------------------------+-------------+ 527 | 2 (TBDb) | Link SID NLRI |This document| 528 +-------------+-----------------------------------+-------------+ 529 | 3 (TBDc) | Prefix SID NLRI |This document| 530 +-------------+-----------------------------------+-------------+ 532 This document requests assigning a code-point from the registry "BGP- 533 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 534 TLVs" as follows: 536 +----------------+-----------------------------------+-------------+ 537 | TLV Code Point | Description | Reference | 538 +----------------+-----------------------------------+-------------+ 539 | TBD1 | SRv6 Node SID |This document| 540 +----------------+-----------------------------------+-------------+ 541 | TBD2 | SRv6 Allocator |This document| 542 +----------------+-----------------------------------+-------------+ 543 | TBD3 | SRv6 Adj-SID |This document| 544 +----------------+-----------------------------------+-------------+ 545 | TBD4 | SRv6 LAN Adj-SID |This document| 546 +----------------+-----------------------------------+-------------+ 548 5. Security Considerations 550 Protocol extensions defined in this document do not affect the BGP 551 security other than those as discussed in the Security Considerations 552 section of [RFC7752]. 554 6. Acknowledgements 556 The authors would like to thank Eric Wu, Robert Raszuk, Zhengquiang 557 Li, and Ketan Talaulikar for their valuable suggestions and comments 558 on this draft. 560 7. References 562 7.1. Normative References 564 [I-D.ietf-idr-flowspec-path-redirect] 565 Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id 566 Redirect", draft-ietf-idr-flowspec-path-redirect-10 (work 567 in progress), October 2019. 569 [I-D.ietf-isis-segment-routing-extensions] 570 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 571 Gredler, H., and B. Decraene, "IS-IS Extensions for 572 Segment Routing", draft-ietf-isis-segment-routing- 573 extensions-25 (work in progress), May 2019. 575 [I-D.ietf-lsr-isis-srv6-extensions] 576 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 577 Z. Hu, "IS-IS Extension to Support Segment Routing over 578 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 579 (work in progress), October 2019. 581 [I-D.ietf-rtgwg-bgp-routing-large-dc] 582 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 583 routing in large-scale data centers", draft-ietf-rtgwg- 584 bgp-routing-large-dc-11 (work in progress), June 2016. 586 [I-D.ietf-spring-segment-routing] 587 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 588 Litkowski, S., and R. Shakir, "Segment Routing 589 Architecture", draft-ietf-spring-segment-routing-15 (work 590 in progress), January 2018. 592 [I-D.ietf-spring-segment-routing-ldp-interop] 593 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 594 S. Litkowski, "Segment Routing interworking with LDP", 595 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 596 progress), September 2018. 598 [I-D.li-ospf-ospfv3-srv6-extensions] 599 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 600 "OSPFv3 Extensions for SRv6", draft-li-ospf- 601 ospfv3-srv6-extensions-05 (work in progress), August 2019. 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, 605 DOI 10.17487/RFC2119, March 1997, 606 . 608 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 609 "Multiprotocol Extensions for BGP-4", RFC 4760, 610 DOI 10.17487/RFC4760, January 2007, 611 . 613 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 614 Topology (MT) Routing in Intermediate System to 615 Intermediate Systems (IS-ISs)", RFC 5120, 616 DOI 10.17487/RFC5120, February 2008, 617 . 619 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 620 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 621 2008, . 623 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 624 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 625 2009, . 627 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 628 and D. McPherson, "Dissemination of Flow Specification 629 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 630 . 632 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 633 S. Ray, "North-Bound Distribution of Link-State and 634 Traffic Engineering (TE) Information Using BGP", RFC 7752, 635 DOI 10.17487/RFC7752, March 2016, 636 . 638 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 639 Writing an IANA Considerations Section in RFCs", BCP 26, 640 RFC 8126, DOI 10.17487/RFC8126, June 2017, 641 . 643 7.2. Informative References 645 [I-D.gredler-idr-bgp-ls-segment-routing-extension] 646 Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M., 647 and J. Tantsura, "BGP Link-State extensions for Segment 648 Routing", draft-gredler-idr-bgp-ls-segment-routing- 649 extension-02 (work in progress), October 2014. 651 [I-D.ietf-idr-bgpls-segment-routing-epe] 652 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 653 S., and J. Dong, "BGP-LS extensions for Segment Routing 654 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 655 segment-routing-epe-19 (work in progress), May 2019. 657 [I-D.ietf-teas-enhanced-vpn] 658 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 659 Framework for Enhanced Virtual Private Networks (VPN+) 660 Service", draft-ietf-teas-enhanced-vpn-03 (work in 661 progress), September 2019. 663 Authors' Addresses 665 Huaimo Chen 666 Futurewei 667 Boston, MA 668 USA 670 Email: Huaimo.chen@futurewei.com 672 Zhenbin Li 673 Huawei 674 Huawei Bld., No.156 Beiqing Rd. 675 Beijing 100095 676 China 678 Email: lizhenbin@huawei.com 680 Zhenqiang Li 681 China Mobile 682 No. 29 Finance Street, Xicheng District 683 Beijing 100029 684 P.R. China 686 Email: li_zhenqiang@hotmail.com 688 Yanhe Fan 689 Casa Systems 690 USA 692 Email: yfan@casa-systems.com 693 Mehmet Toy 694 Verizon 695 USA 697 Email: mehmet.toy@verizon.com 699 Lei Liu 700 Fujitsu 701 USA 703 Email: liulei.kddi@gmail.com