idnits 2.17.00 (12 Aug 2021) /tmp/idnits6515/draft-mpmz-bess-mup-safi-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 document date (March 7, 2022) is 68 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: 'RFC9012' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC6811' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC8205' is defined on line 890, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-mhkk-dmm-srv6mup-architecture-02 ** Downref: Normative reference to an Informational RFC: RFC 4272 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-18 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS T. Murakami 3 Internet-Draft K. Patel 4 Intended status: Standards Track Arrcus 5 Expires: September 8, 2022 S. Matsushima 6 SoftBank 7 J. Zhang 8 Juniper Networks 9 S. Agrawal 10 Cisco Systems 11 March 7, 2022 13 BGP Extensions for the Mobile User Plane (MUP) SAFI 14 draft-mpmz-bess-mup-safi-00.txt 16 Abstract 18 This document defines a new SAFI known as a BGP Mobile User Plane 19 (BGP-MUP) SAFI to support MUP Extensions and a extended community for 20 BGP. This document also provides BGP signaling and procedures for 21 the new SAFI to convert mobile session information into appropriate 22 IP forwarding information. These extensions can be used by operators 23 between MUP PE, MUP GW and MUP Controller for integrating mobile user 24 plane into BGP MUP network using the IP based routing. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 8, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. BGP MUP Extensions . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. BGP MUP SAFI . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.1. BGP Interwork Segment Discovery route . . . . . . . . 5 66 3.1.2. BGP Direct Segment Discovery route . . . . . . . . . 6 67 3.1.3. BGP Type 1 Session Transformed (ST) Route . . . . . . 6 68 3.1.4. BGP Type 2 Session Transformed (ST) Route . . . . . . 8 69 3.2. BGP MUP Extended Community . . . . . . . . . . . . . . . 9 70 3.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3.1. Generation of the Interwork Segment Discovery route . 10 72 3.3.2. Withdrawal of the Interwork Segment Discovery route . 10 73 3.3.3. Processing of the Interwork Segment Discovery routes 11 74 3.3.4. Generation of the Direct Segment Discovery route . . 11 75 3.3.5. Withdrawal of the Direct Segment Discovery route . . 12 76 3.3.6. Processing of the Direct Segment Discovery routes . . 12 77 3.3.7. Generation of the Type 1 ST Route . . . . . . . . . . 13 78 3.3.8. Withdrawing of the Type 1 ST Route . . . . . . . . . 14 79 3.3.9. Processing of the Type 1 ST Route . . . . . . . . . . 14 80 3.3.10. Generation of the Type 2 ST Route . . . . . . . . . . 15 81 3.3.11. Withdrawing of the Type 2 ST Route . . . . . . . . . 15 82 3.3.12. Processing of the Type 2 ST Route . . . . . . . . . . 16 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 7.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 [I-D.mhkk-dmm-srv6mup-architecture] defines the Segment Routing IPv6 94 Mobile User Plane (SRv6 MUP) architecture for Distributed Mobility 95 Management. As part of the architecture, the document defines a new 96 SRv6 segment type called as a MUP Segment, new routing information 97 that can carried within BGP, and 3 new network nodes; MUP PE, MUP GW 98 and a MUP Controller. 100 This document defines a new SAFI known as a BGP Mobile User Plane 101 (BGP-MUP) SAFI to support MUP Extensions for BGP. This draft also 102 provides BGP signaling and procedures for the new SAFI to convert 103 mobile session information into appropriate IP routing information. 104 These extensions can be used by operators between the MUP PE, MUP GW 105 and MUP Controller for integrating mobile user plane into BGP MUP 106 network using the IP based routing. These extensions also works with 107 routing instances accomodationg two new wellknown segment types known 108 as Interwork and Direct [I-D.mhkk-dmm-srv6mup-architecture]. 109 Finally, the BGP encoding and procedures defined in this document 110 that uses SRv6 as the forwarding fabric follows the SRv6 MUP 111 architecture defined in [I-D.mhkk-dmm-srv6mup-architecture]. The BGP 112 extensions to build networks that use forwarding mechanisms other 113 than SRv6 (SRv6 MUP) are outside the scope of this document. 115 1.1. Requirements Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Terminology 125 MUP: Mobile User Plane 127 MUP Segment: Representation of mobile user plane segment 129 MUP PE: Provider Edge node in a MUP network 131 MUP GW: Gateway node to interwork with another mobile user plane 132 networks 134 MUP Controller: Controller node for a MUP network 136 UE: User Equipment, as per [TS.23501] 138 gNodeB: 3GPP-compliant implementation of 5G-NR base station, as per 139 [TS.23501] 141 UPF: 3GPP-compliant implementation of User Plane Function, as per 142 [TS.23501] 143 TEID: Tunnel Endpoint Identifier, as per [TS.29281] 145 3. BGP MUP Extensions 147 3.1. BGP MUP SAFI 149 This draft defines a new BGP SAFI known as a BGP-MUP SAFI. The value 150 of this SAFI is to be assigned by IANA from the Subsequent Address 151 Family Identifiers (SAFI) registry. 153 This document also defines a new BGP NLRI known as the BGP-MUP NLRI. 154 The following is the format of the BGP-MUP NLRI: 156 +-----------------------------------+ 157 | Architecture Type (1 octet) | 158 +-----------------------------------+ 159 | Route Type (2 octets) | 160 +-----------------------------------+ 161 | Length (1 octet) | 162 +-----------------------------------+ 163 | Route Type specific (variable) | 164 +-----------------------------------+ 166 The Architecture Type field defines the encoding of the rest of BGP- 167 MUP NLRI for a given Mobile User Plane architecture. This draft 168 defines the following architecture type for BGP-MUP NLRI: 170 + 1 - 3gpp-5g; 172 The Route Type field defines the encoding of the rest of BGP-MUP NLRI 173 (Route Type specific BGP-MUP NLRI) for a given architecture type. 175 The Length field indicates the length in octets of the Route Type 176 specific field of the BGP-MUP NLRI. 178 This document defines the following Route Types for BGP-MUP NLRI. 180 + 1 - Interwork Segment Discovery route; 181 + 2 - Direct Segment Discovery route; 182 + 3 - Type 1 Session Transformed (ST) route; 183 + 4 - Type 2 Session Transformed (ST) route; 185 These Route Types are applicable for the 3gpp-5G architecture type as 186 per [I-D.mhkk-dmm-srv6mup-architecture]. Other new architectures can 187 share them if it is applicable as well. 189 The BGP-MUP NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 190 Extensions [RFC4760] with an Address Family Identifier (AFI) of 1 or 191 2 and a Subsequent AFI (SAFI) of BGP-MUP. The NLRI field in the 192 MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the BGP-MUP NLRI 193 (encoded as specified above). The value of the AFI field in the 194 MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the BGP-MUP NLRI 195 determines whether the addresses carried in the routes are IPv4 or 196 IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates IPv6 197 addresses). 199 In order for two BGP speakers to exchange BGP-MUP NLRIs, they must 200 use a BGP Capabilities Advertisement to ensure that they both are 201 capable of properly processing such an NLRI. This is done as 202 specified in [RFC4760], by using capability code 1 (multiprotocol 203 BGP) with an AFI of 1 or 2 and an SAFI of BGP-MUP. 205 This document defines 4 Route Types for 3gpp-5G architecture type. 206 Any other Route Types MUST be silently ignored upon a receipt if a 207 BGP speaker supports only 3gpp-5G architecture type. An 208 implementation MAY log an error when such Route Types are ignored. 209 An implementation MAY considered retrieving any discarded Route Types 210 by simply resetting the session or issuing a Route-REFRESH message 211 [RFC2918] if the Route Refresh Capability is successfully negotiated. 213 The following sections describes the format of the Route Type 214 specific BGP-MUP NLRI for various Route Types defined in this 215 document. 217 3.1.1. BGP Interwork Segment Discovery route 219 A BGP Interwork Segment Discovery route Type specific BGP-MUP NLRI 220 consist of the following: 222 +-----------------------------------+ 223 | RD (8 octets) | 224 +-----------------------------------+ 225 | Prefix Length (1 octet) | 226 +-----------------------------------+ 227 | Prefix (variable) | 228 +-----------------------------------+ 230 The Interwork Segment Discovery route Type NLRI consist of RD which 231 is encoded as described in [RFC4364]. It also has an prefix 232 associated with Interwork segment connected locally. For the purpose 233 of BGP route key processing, only the RD, Prefix Length and Prefix 234 are considered to be part of the prefix in the NLRI. 236 In 3GPP 5G specific case, a prefix used for a N3 interface of the 237 gNodeB connected locally MAY be used as this prefix. The prefix 238 length of one octet indicating length of the prefix. If the AFI is 239 IPv4, then the maximum value of the Prefix Length is 32 bits 240 otherwise it is considered as a malformed NLRI. If the AFI is IPv6, 241 then the maximum value of of the Prefix length is 128 bits otherwise 242 it is considered as a malformed NLRI. A BGP speaker MUST handle such 243 a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A BGP speaker 244 MUST skip such NLRIs and continue processing of rest of the Update 245 message. 247 3.1.2. BGP Direct Segment Discovery route 249 A BGP Direct Segment Discovery route Type specific BGP-MUP NLRI 250 consist of the following: 252 +-----------------------------------+ 253 | RD (8 octets) | 254 +-----------------------------------+ 255 | Address (4 or 16 octets) | 256 +-----------------------------------+ 258 The Direct Segment Discovery route Type NLRI consist of RD which is 259 encoded as described in [RFC4364]. It also has an Address of 260 originating BGP speaker. For the purpose of BGP route key 261 processing, only the RD and Address are considered to be part of the 262 prefix in the NLRI. 264 If the AFI is IPv4 then the address length is 4 octets otherwise it 265 is considered as a malformed NLRI. If the AFI is IPv6 then the 266 address length is 16 octets otherwise it is considered as a malformed 267 NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- 268 as-withdraw" [RFC7606]. A BGP speaker MUST skip such NLRIs and 269 continue processing of rest of the Update message. 271 3.1.3. BGP Type 1 Session Transformed (ST) Route 273 A BGP Type 1 ST Route Type specific BGP-MUP NLRI consist of the 274 following: 276 +-----------------------------------+ 277 | RD (8 octets) | 278 +-----------------------------------+ 279 | Prefix Length (1 octet) | 280 +-----------------------------------+ 281 | Prefix (variable) | 282 +-----------------------------------+ 283 | Architecture specific (variable) | 284 +-----------------------------------+ 286 The Type 1 ST Route Type NLRI consist of RD which is encoded as 287 described in [RFC4364]. It also has Prefix length of one octet 288 indicating length of the Prefix. For the purpose of BGP route key 289 processing, only the RD, Prefix Length and Prefix are considered to 290 be part of the prefix in the NLRI. 292 In 3GPP 5G specific case, Prefix is the prefix allocated to a UE. If 293 the AFI is IPv4, then the maximum value of the Prefix Length field is 294 32. If the AFI is IPv6, then the maximum value of the Prefix Length 295 field is 128. Any other length field is considered a a malformed 296 NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- 297 as-withdraw" [RFC7606]. A BGP speaker MUST skip such NLRIs and 298 continue processing of rest of the Update message. 300 The architecture specific encoding values will follow after the 301 variable length Prefix. 303 3.1.3.1. 3gpp-5g Specific BGP Type 1 ST Route 305 A BGP 3gpp-5g Type 1 ST Route Type specific BGP-MUP NLRI consist of 306 the following: 308 +-----------------------------------+ 309 | TEID (4 octets) | 310 +-----------------------------------+ 311 | QFI (1 octet) | 312 +-----------------------------------+ 313 | Endpoint Address Length (1 octet) | 314 +-----------------------------------+ 315 | Endpoint Address (variable) | 316 +-----------------------------------+ 318 The TEID has a fixed length of 4 octets. The TEID value of 0 is 319 considered as an invalid and a malformed TEID. A BGP speaker MUST 320 handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A 321 BGP speaker MUST skip such NLRIs and continue processing of rest of 322 the Update message. 324 The QFI has a fixed length of 1 octet. 326 The Endpoint Address Length has a fixed length of 1 octet. Endpoint 327 Address field contains of an IPv4 address, then the value of the 328 Endpoint Address Length field is 32. If the Endpoint Address field 329 contains of an IPv6 Address, then the value of the Endpoint Address 330 Length field is 128. Any other value is considered as an invalid and 331 a malformed Endpoint Address. A BGP speaker MUST handle such a 332 malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A BGP speaker 333 MUST skip such NLRIs and continue processing of rest of the Update 334 message. 336 The NLRI architecture field MUST be encoded as shown above if a BGP 337 speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the 338 NLRI is considered as a malformed. A BGP speaker MUST handle such a 339 malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A BGP speaker 340 MUST skip such NLRIs and continue processing of rest of the Update 341 message. 343 3.1.4. BGP Type 2 Session Transformed (ST) Route 345 A BGP Type 2 ST Route Type specific BGP-MUP NLRI consist of the 346 following: 348 +-----------------------------------+ 349 | RD (8 octets) | 350 +-----------------------------------+ 351 | Endpoint Length (1 octet) | 352 +-----------------------------------+ 353 | Endpoint Address (variable) | 354 +-----------------------------------+ 355 | Architecture specific Endpoint | 356 | Identifier (variable) | 357 +-----------------------------------+ 359 The Type 2 ST Route Type NLRI consist of RD which is encoded as 360 described in [RFC4364]. It also has Endpoint length of one octet 361 indicating length of the Endpoint Address and the Architecture 362 specific Endpoint Identifier as per 363 [I-D.mhkk-dmm-srv6mup-architecture] defines aggregation capability by 364 the Type2 ST Route. If the AFI is IPv4 and the Endpoint Length is 365 longer than 32 then the Architecture specific endpoint Identifier 366 field exists with the IPv4 Endpoint Address. If the AFI is IPv6 and 367 the Endpoint Length is longer than 128 then the Architecture specific 368 endpoint Identifier field exists with then the IPv6 Endpoint Address. 369 For the purpose of BGP route key processing, only the RD, Endpoint 370 Address and Architecture specific Endpoint Identifier are considered 371 to be part of the prefix in the NLRI. 373 In 3GPP 5G specific case, the Endpoint Address is a N3 interface 374 address of the UPF. If the AFI is IPv4, then the maximum Endpoint 375 length is 64 otherwise it is considered as a malformed NLRI. If the 376 AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is 377 considered as a malformed NLRI. A BGP speaker MUST handle such a 378 malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A BGP speaker 379 MUST skip such NLRIs and continue processing of rest of the Update 380 message. 382 The architecture specific encoding values will follow after the 383 variable length Prefix. 385 3.1.4.1. 3gpp-5g Specific BGP Type 2 ST Route 387 A BGP 3gpp-5g Type 2 ST Route Type specific BGP-MUP NLRI consist of 388 the following: 390 +-----------------------------------+ 391 | TEID (0-4 octets) | 392 +-----------------------------------+ 394 The maximum length of TEID is 4 octets. The TEID value of 0 is 395 considered as an invalid and a malformed TEID. A BGP speaker MUST 396 handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A 397 BGP speaker MUST skip such NLRIs and continue processing of rest of 398 the Update message. 400 The NLRI architecture field MUST be encoded as shown above if a BGP 401 speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the 402 NLRI is considered as a malformed. A BGP speaker MUST handle such a 403 malformed NLRI as a "Treat-as-withdraw" [RFC7606]. A BGP speaker 404 MUST skip such NLRIs and continue processing of rest of the Update 405 message. 407 3.2. BGP MUP Extended Community 409 This document defines a new BGP Extended community known as BGP MUP 410 Extended community as per [I-D.mhkk-dmm-srv6mup-architecture]. 412 This is a BGP MUP specific Extended Community, of an extended type, 413 and is transitive across AS boundaries [RFC4360]. 415 The Type value of this Extended community is set to MUP type, to be 416 assigned by IANA from BGP Extended community transtive registry. The 417 Sub-Type value is set to Direct-Type Segment Identifier type, to be 418 assigned by IANA from BGP Extended community transtive registry. The 419 value field of the community is set to the 6 bytes of configurable 420 segment identifier value. 422 The usage of this Extended community is described in the 423 Section 3.3.12 and Section 3.3.10 425 3.3. Operation 427 BGP speakers acting as a MUP PE, MUP GW and a MUP Controller MUST 428 establish a BGP session to exchange BGP-MUP NLRIs for both, IPv4 and 429 IPv6 AFIs. Once the session is established successfully, BGP 430 speakers can exchange the Discovery routes as well as Session 431 Transformed routes. This information is specific to a given routing 432 instance. BGP-MUP SAFI is expected to work with routing instances 433 accomodationg MUP segments. In 3GPP 5G specific case, the routing 434 instances are depicted as N3RAN and N6DN instances defined in 435 [I-D.mhkk-dmm-srv6mup-architecture]. The subsequent sections 436 describes procedures of generating and processing of each route 437 types. 439 3.3.1. Generation of the Interwork Segment Discovery route 441 The Interwork Segment Discovery route is generated by the MUP GW when 442 a routing instance accommodates an Interwork type MUP Segment, e.g., 443 N3 interfaces or routes on RAN side in 3GPP 5G specific case. It 444 generates route per each N3RAN IP prefix and stores the route in the 445 routing instance of N3RAN. The IP prefix MAY include a gNodeB 446 address which is connecting to the MUP GW. The BGP AFI for BGP 447 MP_REACH_NLRI attribute to carry the Discovery route is decided based 448 on the AFI of the prefix. 450 When advertising the Interwork Segment Discovery route, a MUP GW MUST 451 attach the export BGP Route Target Extended Community of the 452 associated routing instance. 454 When advertising the Interwork Segment Discovery route, a MUP GW MUST 455 use the IPv6 address of the MUP GW as the nexthop address in the 456 MP_REACH_NLRI attribute. 458 The Interwork Segment Discovery route update MUST have a prefix SID 459 attribute which the SID consists of the MUP GW locater followed by a 460 function. In 3GPP 5G specific case, if the BGP AFI is IPv4, the 461 function MUST be GTP4.E [I-D.ietf-dmm-srv6-mobile-uplane], or MUST be 462 GTP6.E [I-D.ietf-dmm-srv6-mobile-uplane] if the BGP AFI is IPv6. 464 3.3.2. Withdrawal of the Interwork Segment Discovery route 466 The Interwork Segment Discovery route is withdrawn by the MUP GW when 467 it detects that the MUP Segment no longer present for the N3RAN. The 468 BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery 469 route is decided based on the AFI of the prefix. 471 When withdrawing the Interwork Segment Discovery route, a MUP GW MUST 472 attach the export BGP Route Target Extended Community of the 473 associated routing instance. 475 3.3.3. Processing of the Interwork Segment Discovery routes 477 Both, the MUP GW and the MUP PE MAY receive the Discovery Interwork 478 routes from other MUP GWs in the BGP MUP network. A BGP speaker 479 acting as a MUP PE or a MUP GW MAY keep the received MUP Interwork 480 Segment Discovery routes advertised from other MUP GWs. The 481 receiving BGP speaker will perform the importing of the received MUP 482 Interwork Segment Discovery routes in the configured routing instance 483 based on the Route Target extended communities. The IP prefixes for 484 the received segments are imported into the configured routing 485 instance table. Thereby the receiving BGP speaker can provide 486 network connectivity between the nodes that exist in the segments. A 487 BGP speaker MAY discard the received Interwork Segment Discovery 488 route if the speaker fails to import the route based on the Route 489 Target extended communities. 491 The BGP speaker receiving the Interwork Segment Discovery routes 492 SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. However, 493 the receiving BGP speaker MUST ensure that the value of Address filed 494 in the NLRI is an address of the originator of the locator value in 495 the prefix SID attribute. The originator of the locator value can be 496 resolved from the IPv6 IGP table. If the result of the match is not 497 identical then the receiving BGP speaker MUST consider it as a 498 malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is 499 applied. A BGP speaker MUST skip such NLRIs and continue processing 500 of rest of the Update message. 502 When a BGP speaker receives a MP_REACH_NLRI attribute update message 503 with a Discovery Internetwork NLRI without a prefix SID attribute, 504 than it MUST be treated as if it contained a malformed prefix SID 505 attribute and the "Treat-as-withdraw procedure of [RFC7606] is 506 applied. A BGP speaker MUST skip such NLRIs and continue processing 507 of rest of the Update message. 509 When a BGP speaker receives an MP_UNREACH_NLRI attribute update 510 message it MUST delete the withdrawn Interwork Segment Discovery 511 route from the routing instance table where it was created. 513 3.3.4. Generation of the Direct Segment Discovery route 515 The Direct Segment Discovery route is generated by the MUP PE when a 516 routing instance accommodates a Direct type MUP Segment, e.g., N6 517 interface or routes on DN side in 3GPP 5G specific case. It 518 generates the Direct Segment Discovery route per each routing 519 instance for the MUP Segment. The address in the BGP-MUP NLRI MUST 520 be a unique MUP PE identifier. The BGP AFI for BGP MP_REACH_NLRI 521 attribute to carry the Direct Segment Discovery route is decided 522 based on the AFI of the MUP PE identifier 523 [I-D.mhkk-dmm-srv6mup-architecture]. 525 When announcing the Direct Segment Discovery route, a MUP PE MUST 526 attach a BGP MUP Extended community of the associated routing 527 instance. The sub-type of the Extended community is Direct-Type 528 Segment Identifier. 530 When advertising the Direct Segment Discovery route, a MUP PE MUST 531 use the IPv6 address of the MUP PE as the nexthop address in the 532 MP_REACH_NLRI attribute. 534 The Direct Segment Discovery route update MUST have a prefix SID 535 attribute which the SID consists of the MUP PE locator followed by a 536 function. The function MAY be End.DT4/6 or End.DX4/6. 538 3.3.5. Withdrawal of the Direct Segment Discovery route 540 The Direct Segment Discovery route is withdrawn by the MUP PE when it 541 detects that the MUP Segment no longer present for the routing 542 instance. The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the 543 Discovery route is decided based on the AFI of the MUP PE identifier. 545 When withdrawing the Direct Segment Discovery route, a BGP speaker 546 MUST attach a BGP MUP Extended community of the associated routing 547 instance. 549 3.3.6. Processing of the Direct Segment Discovery routes 551 Both, the MUP GW and the MUP PE MAY receive the Discovery Direct 552 routes from other MUP PEs in the BGP MUP network. A BGP speaker 553 acting as a MUP PE or a MUP GW MAY keep the received MUP Direct 554 Segment Discovery routes advertised from other MUP PEs. The 555 receiving BGP speaker will perform the importing of the received MUP 556 Direct Segment Discovery routes in the configured routing instance 557 based on the Route Target extended communities. The IP prefixes for 558 the received segments are imported into the configured routing 559 instance table. Thereby the receiving BGP speaker can provide 560 network connectivity between the nodes that exist in the segments. A 561 BGP speaker MAY discard the received Direct Segment Discovery route 562 if the speaker fails to import the route based on the Route Target 563 extended communities. 565 The BGP speaker receiving the Direct Segment Discovery routes SHOULD 566 ignore the nexthop in the MP_REACH_NLRI attribute. However, the 567 receiving BGP speaker MUST ensure that the received nexthop value in 568 the MP_REACH_NLRI attribute is identical to the originator of the 569 locator value in the prefix SID attribute. The originator of the 570 locator value can be resolved from the IPv6 IGP table. If the result 571 of the match is not identical then the receiving BGP speaker MUST 572 consider it as a malformed NLRI and the "Treat-as-withdraw procedure 573 of [RFC7606] is applied. A BGP speaker MUST skip such NLRIs and 574 continue processing of rest of the Update message. 576 When a BGP speaker receives a MP_REACH_NLRI attribute update message 577 with a Direct Segment Discovery route without a prefix SID attribute, 578 than it MUST be treated as if it contained a malformed prefix SID 579 attribute and the "Treat-as-withdraw procedure of [RFC7606] is 580 applied. A BGP speaker MUST skip such NLRIs and continue processing 581 of rest of the Update message. 583 When a BGP speaker receives an MP_UNREACH_NLRI attribute update 584 message it MUST delete the withdrawn Direct Segment Discovery route 585 from the routing instance table where it was created. 587 3.3.7. Generation of the Type 1 ST Route 589 A BGP speaker acting as a MUP controller generates Type 1 ST route 590 from corresponding session information through a northbound API as 591 per [I-D.mhkk-dmm-srv6mup-architecture]. The northbound API 592 definition for ST1 route creation is out of scope of this document. 594 In 3GPP 5G specific case, to compose a Type 1 ST route the MUP 595 controller acquires UE address or prefix, Tunnel Endpoint address of 596 GTP [TS.29281] tunnel, TEID, and QFI for access side as input 597 parameters from the northbound API. The MUP controller decides the 598 RD of the Type 1 ST route based on operator policy. 600 When advertising the Type 1 ST route, the MUP controller SHOULD 601 attach a Route Target Extended community which the MUP PEs are 602 importing into the routing instance for the corresponding Direct 603 segment. 605 The MUP controller MUST set the nexthop of the route to the address 606 of the MUP Controller. 608 The MUP controller MUST announce this route using a AFI of the route 609 and the SAFI of BGP-MUP to all other BGP speakers within the SRv6 610 domain. 612 3.3.8. Withdrawing of the Type 1 ST Route 614 A BGP speaker acting as a MUP controller withdraws Type 1 ST route 615 based on deletion of corresponding session information through a 616 northbound API as per [I-D.mhkk-dmm-srv6mup-architecture]. The 617 northbound API definition for ST1 route withdraw is out of scope of 618 this document. 620 In 3GPP 5G specific case, to withdraw a Type 1 ST route the MUP 621 controller acquires the UE address or prefix, Tunnel Endpoint address 622 of GTP[TS.29281] tunnel, TEID,and QFI for access side as input 623 parameters from the northbound API. The MUP controller MUST 624 advertise the withdraws of the Type 1 ST route. 626 When withdrawing the Type 1 ST route, the MUP controller SHOULD 627 attach the Route Target Extended community which the MUP PEs are 628 importing into the routing instance accomodating the corresponding 629 Direct segment to the Route Target Extended community. 631 3.3.9. Processing of the Type 1 ST Route 633 Both, the MUP GW and the MUP PE MAY receive the Type 1 ST routes from 634 the MUP Controller in the BGP MUP network. A BGP speaker acting as a 635 MUP PE or a MUP GW MAY keep the received MUP Type 1 ST routes 636 advertised from the MUP Controller. The receiving BGP speaker will 637 perform the importing of the received MUP Type 1 ST routes in the 638 configured N6DN routing instance based on the Route Target extended 639 communities. A BGP speaker MAY discard the received Type 1 ST route 640 if the speaker fails to import the route based on the Route Target 641 extended communities. 643 In case of a BGP speaker receiving a Type 1 ST routes is a MUP PE, 644 the MUP PE SHOULD use the received Tunnel Endpoint Address in this 645 NLRI as a key to lookup the associated Interwork Segment Discovery 646 route and extract the locator and the function in the prefix SID 647 attribute of the Interwork route. 649 In 3GPP 5G specific case, the MUP PE extracts TEID, QFI and Tunnel 650 Endpoint address from the NLRI. Then the MUP PE SHOULD generate the 651 forwarding SID for GTP4/6.E based on the procedures mentioned in the 652 [I-D.ietf-dmm-srv6-mobile-uplane]. If the MUP PE cannot generate the 653 prefix SID, then it SHOULD mark the received Type 1 ST route as an 654 invalid route. The MUP PE MAY hold such an invalid route until the 655 route as a valid route upon successful generation of prefix SID. 657 The MUP PE receiving Type 1 ST routes SHOULD ignore the received 658 nexthop in the MP_REACH_NLRI attribute. 660 The MUP PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute 661 MUST delete all the routes from the associated routing instance. 663 3.3.10. Generation of the Type 2 ST Route 665 A BGP speaker acting as a MUP controller generates Type 2 ST route 666 from corresponding session information through a northbound API, or 667 pre-defined configuration as per [I-D.mhkk-dmm-srv6mup-architecture]. 668 The northbound API definition for ST2 route creation is out of scope 669 of this document. 671 In 3GPP 5G specific case, to compose a Type 2 ST route the MUP 672 controller acquires the Endpoint consists of Endpoint address of GTP 673 [TS.29281] tunnel and TEID for core side with the effective length of 674 the Endpoint as input parameters. The MUP controller decides the RD 675 of the Type 2 ST route based on operator policy. 677 When advertising the Type 2 ST route, the MUP controller SHOULD 678 attach a BGP MUP Extended community corresponding to the Direct 679 segment. The sub-type of the Extended community is Direct-Type 680 Segment Identifier. This Segment Identifier is generated from the 681 information received through a northbound API, or a pre-defined 682 configuration as per [I-D.mhkk-dmm-srv6mup-architecture]. The 683 northbound API definition for receving this information is out of 684 scope of this document. 686 The MUP controller MUST also attach a Route Target Extended community 687 of the routing instances in the MUP GW accomodating the corresponding 688 Interwork segment. 690 The MUP controller MUST set the nexthop of the route to the address 691 of the MUP Controller. 693 3.3.11. Withdrawing of the Type 2 ST Route 695 A BGP speaker acting as a MUP controller withdraws Type 2 ST route 696 based on deletion of corresponding session information through a 697 northbound API as per [I-D.mhkk-dmm-srv6mup-architecture]. The 698 northbound API definition for ST2 route withdraw is out of scope of 699 this document. 701 In 3GPP 5G specific case, to withdraw a Type 2 ST route the MUP 702 controller acquires the Endpoint consists of Endpoint address of GTP 703 [TS.29281] tunnel and TEID for core side with the effective length of 704 the Endpoint as input parameters. The MUP controller MUST advertise 705 the withdraws of the Type 2 ST route. 707 When withdrawing the Type 2 ST route, the MUP controller SHOULD 708 attach the BGP MUP Extended community corresponding to the Direct 709 segment, and the Route Target Extended community which the MUP GWs 710 are importing into the routing instance accomodating the 711 corresponding Interwork segment to the Route Target Extended 712 community. 714 3.3.12. Processing of the Type 2 ST Route 716 Both, the MUP GW and the MUP PE MAY receive the Type 2 ST routes from 717 the MUP Controller in the BGP MUP network. A BGP speaker acting as a 718 MUP PE or a MUP GW MAY keep the received MUP Type 2 ST routes 719 advertised from the MUP Controller. The receiving BGP speaker will 720 perform the importing of the received MUP Type 2 ST routes in the 721 configured N3RAN routing instance based on the Route Target extended 722 communities. A BGP speaker MAY discard the received Type 2 ST route 723 if the speaker fails to import the route based on the Route Target 724 extended communities. 726 The BGP speaker receiving the Type 2 ST routes SHOULD ignore the 727 received nexthop in the MP_REACH_NLRI attribute. 729 A MUP GW receiving the Type 2 ST routes in a MP_REACH_NLRI attribute 730 without a BGP MUP Extended community SHOULD consider the route as a 731 malformed route. The MUP GW MUST handle such a malformed NLRI as a 732 "Treat-as-withdraw" [RFC7606]. 734 The MUP GW receiving Type 2 ST route with a BGP MUP Extended 735 Community should extract the received segment identifier from the 736 community. The segment identifier is used to resolve an appropriate 737 Direct segment routing instance. 739 4. Security Considerations 741 The mechanisms described in this document could reuse the existing 742 BGP security mechanisms [RFC4271] [RFC4272]. The security model and 743 threats specific to Provider Provisioned VPNs, including L3VPNs, are 744 discussed in [RFC4111]. The method defined in [RFC5925] SHOULD be 745 used where authentication of BGP control packets is needed. 747 This document defines 3 new network nodes; MUP PE, MUP GW and a MUP 748 Controller. These MUP BGP speakers SHOULD NOT establish BGP sessions 749 with other BGP speakers in the domains which are not trusted without 750 any explicit configuration or an operator intervention. Usage of 751 procedures defined in [RFC5925] SHOULD be enforced at such boundaries 752 to ensure the proper authentication of BGP control packets. 754 Furthermore, [RFC5925] will not help to keep the BGP messages 755 private. To protect the BGP messages exchanged between BGP speakers 756 from eavesdrop, establishing BGP sessions over encrypted paths SHOULD 757 be considered. 759 MUP PEs and GWs SHOULD impose an upper bound on number of routes they 760 should store to protect their control plane load. For example, BGP 761 implementations MAY provide a configuration knob to impose an upper 762 bound on Type 1 ST Routes. 764 5. IANA Considerations 766 This document defines a new BGP SAFI known as a BGP-MUP SAFI. IANA 767 is requested to assign the value for the new SAFI from the Subsequent 768 Address Family Identifiers (SAFI) registry. 770 This document defines a new Architecture Type for a BGP-MUP SAFI. 771 IANA is requested to create a new Architecture Type NLRI registry for 772 BGP-MUP SAFI. Furthermore, IANA is also requested to assign values 773 for the following Architecture Types from the newly created BGP-MUP 774 Architecture Type NLRI registry: 776 + 1 - 3gpp-5g; 778 This document defines new NLRIs for a BGP-MUP SAFI. IANA is 779 requested to create a new NLRI registry for BGP-MUP SAFI. 780 Furthermore, IANA is also requested to assign values for the 781 following NLRIs from the newly created BGP-MUP NLRI registry: 783 + 1 - Discovery Internetwork route; 784 + 2 - Direct Segment Discovery route; 785 + 3 - Type 1 Session Transformed (ST) route; 786 + 4 - Type 2 Session Transformed (ST) route; 788 This document defines a new BGP Extended Community called "SRv6 MUP 789 Extended Community". This Community is of an extended type and is 790 transitive. IANA is requested to assign the Type and the Sub-Type 791 value for this Community from the Transitive Extended Community 792 registry. 794 6. Contributors 796 In addition to the authors listed on the front page, the following 797 individuals have also made significant contributions to the draft: 799 Katsuhiro Horiba 800 SoftBank 801 Email: katsuhiro.horiba@g.softbank.co.jp 802 Yuya Kawakami 803 SoftBank 804 Email: yuya.kawakami01@g.softbank.co.jp 806 Kalyani Rajaraman 807 SoftBank 808 Email: kalyanir@arrcus.com 810 7. References 812 7.1. Normative References 814 [I-D.mhkk-dmm-srv6mup-architecture] 815 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 816 Murakami, T., Patel, K., Kohno, M., Kamata, T., Garvia, P. 817 C., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., 818 Perumal, K., and J. Horn, "Segment Routing IPv6 Mobile 819 User Plane Architecture for Distributed Mobility 820 Management", draft-mhkk-dmm-srv6mup-architecture-02 (work 821 in progress), March 2022. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, 825 DOI 10.17487/RFC2119, March 1997, 826 . 828 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 829 DOI 10.17487/RFC2918, September 2000, 830 . 832 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 833 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 834 DOI 10.17487/RFC4271, January 2006, 835 . 837 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 838 RFC 4272, DOI 10.17487/RFC4272, January 2006, 839 . 841 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 842 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 843 February 2006, . 845 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 846 "Multiprotocol Extensions for BGP-4", RFC 4760, 847 DOI 10.17487/RFC4760, January 2007, 848 . 850 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 851 Patel, "Revised Error Handling for BGP UPDATE Messages", 852 RFC 7606, DOI 10.17487/RFC7606, August 2015, 853 . 855 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 856 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 857 May 2017, . 859 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 860 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 861 DOI 10.17487/RFC9012, April 2021, 862 . 864 7.2. Informative References 866 [I-D.ietf-dmm-srv6-mobile-uplane] 867 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 868 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 869 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-18 870 (work in progress), February 2022. 872 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 873 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 874 DOI 10.17487/RFC4111, July 2005, 875 . 877 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 878 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 879 2006, . 881 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 882 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 883 June 2010, . 885 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 886 Austein, "BGP Prefix Origin Validation", RFC 6811, 887 DOI 10.17487/RFC6811, January 2013, 888 . 890 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 891 Specification", RFC 8205, DOI 10.17487/RFC8205, September 892 2017, . 894 [TS.23501] 895 3GPP, "System architecture for the 5G System (5GS)", 3GPP 896 TS 23.501 17.2.0, September 2021, 897 . 899 [TS.29281] 900 3GPP, "General Packet Radio System (GPRS) Tunnelling 901 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 16.1.0, 902 September 2020. 904 Authors' Addresses 906 Tetsuya Murakami 907 Arrcus 908 2077 Gateway Place, Suite 400 909 San Jose, CA 95110 910 USA 912 Email: tetsuya@arrcus.com 914 Keyur Patel 915 Arrcus 916 2077 Gateway Place, Suite 400 917 San Jose, CA 95110 918 USA 920 Email: keyur@arrcus.com 922 Satoru Matsushima 923 SoftBank 924 Japan 926 Email: satoru.matsushima@g.softbank.co.jp 928 Jeffrey Zhang 929 Juniper Networks 930 USA 932 Email: zzhang@juniper.net 934 Swadesh Agrawal 935 Cisco Systems 936 USA 938 Email: swaagraw@cisco.com