idnits 2.17.1 draft-drake-bess-enhanced-vpn-01.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 (May 10, 2019) is 1812 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) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-05 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group J. Drake 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track A. Farrel 5 Expires: November 11, 2019 Old Dog Consulting 6 May 10, 2019 8 BGP-LS Maps : A Framework for Network Slicing and Enhanced VPNs 9 draft-drake-bess-enhanced-vpn-01 11 Abstract 13 Future networks that support advanced services, such as those enabled 14 by 5G mobile networks, envision a set of overlay networks each with 15 different performance and scaling properties. These overlays are 16 known as network slices and are realized over a common underlay 17 network. 19 In order to support network slicing, as well as to offer enhanced VPN 20 services in general, it is necessary to define a mechanism by which 21 specific resources (links and/or nodes) of an underlay network can be 22 used by a specific network slice, VPN, or set of VPNs. This document 23 sets out such a mechanism for use in Segment Routing networks. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 11, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 3 62 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 5 63 4.1. The BGP-LS Map Attribute . . . . . . . . . . . . . . . . 6 64 4.1.1. The Map TLV . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.2. The DSCP List TLV . . . . . . . . . . . . . . . . . . 9 66 4.1.3. The Color List TLV . . . . . . . . . . . . . . . . . 9 67 4.1.4. The Root TLV . . . . . . . . . . . . . . . . . . . . 10 68 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 69 5. Comparison With ACTN . . . . . . . . . . . . . . . . . . . . 12 70 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. MP2MP Connectivity . . . . . . . . . . . . . . . . . . . 12 72 6.2. P2MP Unidirectional Connectivity . . . . . . . . . . . . 13 73 6.3. P2P Unidirectional Connectivity . . . . . . . . . . . . . 14 74 6.4. P2P Bidirectional Connectivity . . . . . . . . . . . . . 15 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. New BGP Path Attribute . . . . . . . . . . . . . . . . . 16 78 8.2. New BGP-LS Map attribute TLVs Type Registry . . . . . . . 16 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 80 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 83 11.2. Informative References . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 Network slicing is an approach to network operations that builds on 89 the concept of network abstraction to provide programmability, 90 flexibility, and modularity. Driven largely by needs surfacing from 91 5G, the concept of network slicing has gained traction, for example 92 in [TS23501] and [TS28530]. Network slicing requires the underlying 93 network to support partitioning the network resources to provide the 94 client with dedicated (private) networking, computing, and storage 95 resources drawn from a shared pool. The slices may be seen as (and 96 operated as) virtual networks. 98 Advanced services drive a need to create virtual networks with 99 enhanced characteristics. The tenant of such a virtual network can 100 require a degree of isolation and performance that previously could 101 only be satisfied by dedicated networks. Additionally, the tenant 102 may ask for some level of control to their virtual networks, e.g., to 103 customize the service forwarding paths in the underlying network. 105 The concepts of "enhanced VPNs" and "network slicing" are introduced 106 in [I-D.ietf-teas-enhanced-vpn]. 108 In order to support network slicing, as well as to offer enhanced VPN 109 services in general, it is necessary to define a mechanism by which 110 specific resources (links and/or nodes) of an underlay network can be 111 used by a specific network slice, VPN, or set of VPNs. This document 112 sets out such a mechanism for use in Segment Routing networks 113 [RFC8402] and builds on the ideas introduced in 114 [I-D.ietf-idr-segment-routing-te-policy]. I.e., it generalizes that 115 work to support multipoint-to-multipoint (MP2MP), point-to-multipoint 116 (P2MP), and bidirectional point-to-point (P2P) topologies; it 117 integrates BGP-based VPN support ([RFC4364], [RFC7432]); it supports 118 DSCP as well a Color-based forwarding, and it uses BGP Link-State 119 (BGP-LS) [RFC7752] to distribute topology information. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Overview of Approach 131 The approach is based on the use of DSCP-based forwarding in the 132 underlay network [RFC2474]. For each VPN or sets of VPNs that are to 133 use a given underlay network, a central network controller assigns 134 resources per {link, DSCP} pair based upon the {source, destination, 135 DSCP} traffic matrix. That is, each VPN or set of VPNs gets a 136 subset, either dedicated or shared, of the resources in the underlay 137 network. 139 It should be noted that resources can be assigned at any of the 140 following granularities: 142 o All PEs in a given VPN 144 o A set of PEs in a given VPN 145 o An individual PE in a given VPN. 147 Once the central controller has determined the resource assignments, 148 it distributes this information to the PEs that participate in each 149 VPN using the usual VPN information dissemination tools, e.g., route 150 targets (RT) [RFC4360], route reflectors (RR) [RFC4456], and RT 151 constraints [RFC4684]. 153 One way to distribute this information to those PEs is to give them a 154 customized but limited view of the underlay network. (Note that 155 giving each PE a full view of the underlay network does not help the 156 PEs to manipulate the resources assigned for use by a particular 157 slice or VPN, but providing a customized and limited view of those 158 resources as a "virtual network" allows the PE to direct traffic over 159 the designated resources as necessary to best deliver the end-to-end 160 services.) 162 This information is distributed to the PEs by giving them a 163 customized and limited view of the underlay network on the basis of a 164 network slice, a VPN, or a set of VPNs. Each PE will have a complete 165 view of the underlay network and this customized and limited view 166 acts as filter on the underlay network telling the PE which underlay 167 network resources it can use to direct the traffic of a given network 168 slice, VPN, or set of VPNs to best deliver end-to-end services. 170 The resource allocation information is encoded using BGP-LS. This 171 approach is chosen for the following reasons: 173 o It is BGP-based so it integrates easily with the existing BGP- 174 based VPN infrastructure ([RFC4364], [RFC4684]) 176 o It supports Segment Routing which is necessary to enforce the PEs' 177 usage of the resources allocated to the VPN or set of VPNs 179 o It supports inter-AS connectivity which is a perquisite for 180 supporting the existing BGP-based VPN infrastructure 182 o It is canonical, in that it can be used to advertise the resources 183 of underlay networks that use either IS-IS or OSPF 185 It should be noted that this mechanism also follows the scalability 186 model of the existing BGP-based VPN infrastructure, which is that the 187 per-VPN information is restricted to only those PE routers that are 188 supporting that VPN and that the P routers have no per-VPN state. 190 Standard VPNs do not receive this resource allocation information and 191 continue to use CSPF-based Weighted ECMP (WECMP) in the underlay 192 network. This means that resources used by enhanced VPNs are 193 reserved and are distinct from the resources used by the CSPF-based 194 WECMP topology. 196 Additional to the programming of the PEs and its computation and 197 assignment of resources for use by slices, VPN instances, or groups 198 of VPNs, the central controller also instructs the P routers to makes 199 actual allocation of resources per-DSCP. 201 4. Detailed Protocol Operation 203 We define a BGP-LS Map to be a BGP-LS encoded description of a subset 204 of the links and nodes in the underlay network. A BGP-LS Map defines 205 the topology for a network slice or a set of one or more VPNs. The 206 topology connects a set of one or more VPNs and which is be used by 207 the PEs in those VPNs to send packets. I.e., it connects the PEs in 208 these VPNs and is used by them to send packets to each other. A 209 given map is tagged with the route targets of the VPNs whose PEs are 210 to import the map. A BGP-LS map is pushed southbound to these PEs by 211 a network controller and may provide more than one path between a 212 given ingress/egress PE pair. 214 Note that there will be multiple BGP-LS Maps in a given network 215 deployment and that a given underlay network link or node may appear 216 in more than one of them. In order to provide disambiguation AFI 217 16388 (BGP-LS) and SAFI 72 (BGP-LS-VPN) are used in BGP-LS UPDATE 218 messages and the controller SHOULD allocate a different route 219 distinguisher (RD) to each BGP-LS Map. 221 It is assumed that the underlay network is enabled for segment 222 routing. Within a given VPN, when an ingress PE needs to send a 223 packet to an egress PE it selects a path to that egress PE from the 224 topology defined by the BGP-LS maps it has imported for that VPN and 225 it specifies that path using a segment routing label stack. 227 To enable this function there is a need for a new attribute that is 228 attached to a BGP-LS map update that contains a map ID, the version 229 number, a map type (MP2MP, P2MP, or P2P), the total number of 230 fragments in the map, and the specific fragment number of the piece 231 in hand. That is, the total number of fragments in the map, and the 232 fragment number of the piece currently in hand. It is assumed that a 233 PE may import more than one BGP-LS map, that a given BGP-LS map may 234 change over time, and that a given BGP-LS map may span multiple BGP 235 updates. The map ID needs to be unique across the set of VPNs into 236 which the BGP-LS map is to be imported. 238 A BGP-LS map that is created for a set of VPNs will contain a set of 239 network resources sufficient to connect the PEs in each VPN in the 240 set and each of the BGP-LS updates for the map MUST be tagged with 241 the RT for each VPN in the set. 243 If a PE imports more than one BGP-LS map it may use the union of the 244 links and nodes specified in each map when selecting a path. A PE 245 should give precedence to BGP-LS maps of type P2MP and P2P when 246 selecting a path. Routes targets specific to a given VPN/PE pair are 247 needed for BGP-LS maps of type P2MP and P2P. 249 A given BGP-LS map may change in response to updates to the PE 250 membership in a VPN to which the BGP-LS map applies or to updates to 251 the underlay network. When this occurs, the network controller 252 should push a new version of the affected BGP-LS maps. That is, it 253 increments the version number of each BGP-LS map. This implies that 254 the network controller needs to be connected to the route reflectors 255 associated with the VPNs for which it is providing BGP-LS maps. 257 A BGP-LS map cannot be used by a PE until it is completely assembled. 258 If the BGP-LS map that is being assembled is a newer version of a 259 BGP-LS map that the PE is currently using, the PE should continue to 260 use its current version of the BGP-LS map until the newer version is 261 completely assembled. 263 When selecting a path using one or more BGP-LS maps, an ingress PE 264 can use a link or node only if it is active in the underlay network. 265 If this precludes connectivity to the egress PE it may use links and 266 nodes in the CSPF-based WECMP underlay network topology nominally 267 allocated to non-enhanced VPN traffic. 269 Additionally, when there is a newly activated PE it will not be 270 present in any of the BGP-LS maps used by the other PEs. Until a new 271 BGP-LS map or maps that contain that PE has been distributed, other 272 PEs will have to use these links and nodes to reach the newly 273 activated PE and it will have to use these links and nodes to reach 274 other PEs. 276 4.1. The BGP-LS Map Attribute 278 [RFC4271] defines the BGP Path attribute. This document introduces a 279 new Optional Transitive Path attribute called the BGP-LS Map 280 attribute with value TBD1 to be assigned by IANA. 282 The first BGP-LS Map attribute MUST be processed and subsequent 283 instances MUST be ignored. 285 The common fields of the BGP-LS Map attribute are set as follows: 287 o Optional bit is set to 1 to indicate that this is an optional 288 attribute. 290 o The Transitive bit is set to 1 to indicate that this is a 291 transitive attribute. 293 o The Extended Length bit is set according to the length of the BGP- 294 LS Map attribute as defined in [RFC4271]. 296 o The Attribute Type Code is set to TBD1. 298 The content of the BGP-LS Map attribute is a series of Type-Length- 299 Value (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and 300 sub-TLVs have a common format that is: 302 o Type: A single octet indicating the type of the BGP-LS Map 303 attribute TLV. Values are taken from the registry described in 304 Section 8.2. 306 o Length: A two octet field indicating the length of the data 307 following the Length field counted in octets. 309 o Value: The contents of the TLV. 311 The formats of the TLVs defined in this document are shown in the 312 following sections. The presence rules and meanings are as follows. 314 o The BGP-LS Map attribute MUST contain a Map TLV. 316 o The BGP-LS Map attribute MAY contain a DSCP List TLV. 318 o The BGP-LS Map attribute MAY contain a Color List TLV. 320 o The BGP-LS Map attribute MAY contain a Root TLV. 322 4.1.1. The Map TLV 324 The BGP-LS Map attribute MUST contain exactly one Map TLV. Its 325 format is shown in Figure 1. Note that a given BGP-LS map may span 326 multiple UPDATE messages and the Topology, Version Number, and the 327 Number of Fragments fields in the BGP-LS Map attribute contained in 328 each UPDATE message MUST be set to the same value or the BGP-LS map 329 is unusable. 331 +--------------------------------------------+ 332 | Type = 1 (1 octet) | 333 +--------------------------------------------+ 334 | Length (2 octets) | 335 +--------------------------------------------+ 336 | Topology (1 Octet) | 337 +--------------------------------------------+ 338 | ID (4 Octets) | 339 +--------------------------------------------+ 340 | Version Number (4 Octets) | 341 +--------------------------------------------+ 342 | Number of Fragments (4 Octets) | 343 +--------------------------------------------+ 344 | Fragment Number (4 Octets) | 345 +--------------------------------------------+ 347 Figure 1: The Map TLV Format 349 The fields are as follows: 351 o Type is set to 1 to indicate a Map TLV. 353 o Length is set to 17 octets. 355 o Topology indicates whether this BGP-LS map is MP2MP, P2MP, P2P 356 unidirectional, or P2P bidirectional. 358 o The ID of this BGP-LS map. This ID needs to be unique within the 359 set of VPNs into which the BGP-LS map is to be imported. 361 o The Version Number of this BGP-LS map. I.e., the contents of a 362 BGP-LS map with a given ID may change over time and this field 363 indicates the latest version of that BGP-LS map. 365 o Number of Fragments indicates the number of BGP UPDATE messages 366 defining this BGP-LS map. 368 o Fragment Number indicates ordinal position of this UPDATE message 369 within the set of UPDATE messages defining this BGP-LS map. A 370 BGP-LS map is not complete, i.e., usable, until all UPDATE 371 messages have been received with Fragment Numbers in the range 1 372 <= Fragment Number <= Number of Fragments. An UPDATE message with 373 a Fragment Number outside this range is to be ignored. 375 4.1.2. The DSCP List TLV 377 The DSCP List TLV MAY be included in the BGP-LS Map attribute. If 378 included, a packet whose DSCP matches a DSCP in the DSCP list is to 379 be forwarded using the BGP-LS map defined by the containing BGP-LS 380 Map attribute. The first DSCP List TLV MUST be processed and 381 subsequent instances MUST be ignored. The format of the DSCP List 382 TLV is shown in Figure 2. 384 +--------------------------------------------+ 385 | Type = 2 (1 octet) | 386 +--------------------------------------------+ 387 | Length (2 octets) | 388 +--------------------------------------------+ 389 | DSCP List (variable) | 390 +--------------------------------------------+ 392 Figure 2: The DSCP List TLV Format 394 The fields are as follows: 396 o Type is set to 2 to indicate a DSCP List TLV. 398 o Length indicates the length in octets of the DSCP List. 400 o DSCP List contains a list of DSCPs, each one octet in length and 401 encoded in the standard format. 403 4.1.3. The Color List TLV 405 The Color List TLV MAY be included in the BGP-LS Map attribute. If a 406 BGP UPDATE contains a Color extended community with a color (as 407 defined by [RFC5512]) that matches an entry in the Color List, then a 408 packet whose destination is covered by one of the routes in that 409 UPDATE is to be forwarded using the BGP-LS map defined by the 410 containing BGP-LS Map attribute. The first Color List TLV MUST be 411 processed and subsequent instances MUST be ignored. The format of 412 the Color List TLV is shown in Figure 3. 414 Note that if both a DSCP List and a Color List TLV are included in a 415 BGP-LS Map attribute, packets matching an entry in either list are to 416 be forwarded using the BGP-LS map defined by the containing BGP-LS 417 Map attribute. 419 +--------------------------------------------+ 420 | Type = 3 (1 octet) | 421 +--------------------------------------------+ 422 | Length (2 octets) | 423 +--------------------------------------------+ 424 | Color List (variable) | 425 +--------------------------------------------+ 427 Figure 3: The Color List TLV Format 429 The fields are as follows: 431 o Type is set to 3 to indicate a Color List TLV. 433 o Length indicates the length in octets of the Color List. 435 o Color List contains a list of Colors, each four octets in length. 437 4.1.4. The Root TLV 439 The Root TLV MUST be included in the BGP-LS Map attribute if its 440 topology is of type P2MP or P2P unidirectional. It defines the root 441 node for that topology and if it is not present the BGP-LS map is 442 unusable. The TLV, if present, MUST be ignored if the topology is of 443 type MP2MP or P2P bidirectional. 445 The Root TLV is structured as shown in Figure 4 and MAY contain any 446 of the sub-TLVs defined in section 3.2.1.4 of [RFC7752]. 448 +--------------------------------------------+ 449 | Type = 3 (1 octet) | 450 +--------------------------------------------+ 451 | Length (2 octets) | 452 +--------------------------------------------+ 453 | Sub-TLVs (variable) | 454 +--------------------------------------------+ 456 Figure 4: The Root TLV Format 458 The fields are as follows: 460 o Type is set to 3 to indicate a Color List TLV. 462 o Length indicates the length in octets of the Color List. 464 o There follows a sequence of zero or more sub-TLVs as defined in 465 section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be 466 deduced from the Length field of the Root TLV and from the Length 467 fields of each of the sub-TLVs. 469 4.2. Error Handling 471 Section 6 of [RFC4271] describes the handling of malformed BGP 472 attributes, or those that are in error in some way. [RFC7606] 473 revises BGP error handling specifically for the for UPDATE message, 474 provides guidelines for the authors of documents defining new 475 attributes, and revises the error handling procedures for a number of 476 existing attributes. This document introduces the BGP-LS Map 477 attribute and so defines error handling as follows: 479 o When parsing a message, an unknown Attribute Type code or a length 480 that suggests that the attribute is longer than the remaining 481 message is treated as a malformed message and the "treat-as- 482 withdraw" approach used as per [RFC7606]. 484 o When parsing a message that contains an BGP-LS Map attribute, the 485 following cases constitute errors: 487 1. Optional bit is set to 0 in BGP-LS Map attribute. 489 2. Transitive bit is set to 0 in BGP-LS Map attribute. 491 3. The attribute does not contain a Map TLV or it contains more 492 than one Map TLV. 494 4. The TLV length indicates that the TLV extends beyond the end 495 of the BGP-LS Map attribute. 497 5. There is an unknown TLV type field found in BGP-LS Map 498 attribute. 500 o The errors listed above are treated as follows: 502 1., 2., 3., 4.: The attribute MUST be treated as malformed and 503 the "treat-as-withdraw" approach used as per [RFC7606]. 505 5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 506 continue. 508 5. Comparison With ACTN 510 TBD 512 6. Examples 514 Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6) 515 are connected across a network of twelve P nodes (P1 through P12). 516 Each PE is dual-homed, and the P nodes are variously connected so 517 that there are multiple routes between PEs. 519 PE3 PE4 520 |\ /| 521 | \ / | 522 | \ / | 523 | \/ | 524 | /\ | 525 | / \ | 526 | / \ | 527 |/ \| 528 P1--------P2 529 / |\ /| \ 530 / | \ / | \ 531 / | \ / | \ 532 / | \/ | \ 533 P3-------P4--------P5-------P6 534 | / | /\ | \ | 535 | / | / \ | \ | 536 | / | / \ | \ | 537 |/ |/ \| \| 538 P7---P8--P9--------P10-P11-P12 539 |\ /| |\ /| 540 | \/ | | \/ | 541 | /\ | | /\ | 542 |/ \| |/ \| 543 PE1 PE2 PE5 PE6 545 Figure 5: Underlay Network Topology 547 6.1. MP2MP Connectivity 549 Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that 550 connects PE1, PE3, and PE6 can be installed over the underlay 551 network. Path have been computed so that, for example, PE1 is 552 connected to both PE3 and PE6 via a pair of redundant paths. 554 Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to 555 PE1 and PE3. 557 PE3 PE4 558 | \ 559 | \ 560 | \ 561 | \ 562 | \ 563 | \ 564 | \ 565 | \ 566 P1 P2 567 / \ /| 568 / \ / | 569 / \ / | 570 / \ / | 571 P3 P4 X P5 P6 572 | / \ \ 573 | / \ \ 574 | / \ \ 575 | / \ \ 576 P7 P8--P9---------P10-P11 P12 577 | / \ | 578 | / \ | 579 | / \ | 580 |/ \| 581 PE1 PE2 PE5 PE6 583 Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6 585 6.2. P2MP Unidirectional Connectivity 587 Figure 7 shows the provision of a Point-to-Multipoint (P2MP) rooted 588 at PE3 and connected to PE1 and PE6. As in the previous example, a 589 redundant pair of paths is established between PE3 and each of PE1 590 and PE6. Thus, the two paths from PE3 to PE1 are PE3-P1-P4-P7-PE1 591 and PE3-P2-P9-P8-PE1. 593 PE3 PE4 594 | \ 595 | \ 596 | \ 597 | \ 598 | \ 599 | \ 600 | \ 601 | \ 602 P1 P2 603 |\ / \ 604 | \ / \ 605 | \ / \ 606 | \ / \ 607 P3 P4 X P5 P6 608 / / \ | 609 / / \ | 610 / / \ | 611 / / \ | 612 P7---P8--P9 P10-P11 P12 613 | / \ | 614 | / \ | 615 | / \ | 616 |/ \| 617 PE1 PE2 PE5 PE6 619 Figure 7: A P2MP Unidirectional Service Installed at PE3 621 6.3. P2P Unidirectional Connectivity 623 Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and 624 connected to PE3. This is equivalent to a Segment Routing Traffic 625 Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy] 626 installed at PE1. 628 As in the previous examples, a pair of redundant paths are computed. 630 PE3 PE4 631 |\ 632 | \ 633 | \ 634 | \ 635 | \ 636 | \ 637 | \ 638 | \ 639 P1 P2 640 | | 641 | | 642 | | 643 | | 644 P3 P4 P5 P6 645 / | 646 / | 647 / | 648 / | 649 P7 P8--P9--------P10 P11 P12 650 | / 651 | / 652 | / 653 |/ 654 PE1 PE2 PE5 PE6 656 Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at 657 PE1 659 6.4. P2P Bidirectional Connectivity 661 Figure 9 show a bidirectional P2P service connecting PE1 and PE6. 662 This is equivalent to a Segment Routing Traffic Engineering (SR TE) 663 Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and 664 PE6. 666 PE3 PE4 668 P1 P2 670 P3 P4--------P5 P6 671 / \ 672 / \ 673 / \ 674 / \ 675 P7 P8--P9--------P10-P11 P12 676 | / \ | 677 | / \ | 678 | / \ | 679 |/ \| 680 PE1 PE2 PE5 PE6 682 Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6 684 7. Security Considerations 686 TBD 688 8. IANA Considerations 690 8.1. New BGP Path Attribute 692 IANA maintains a registry of "Border Gateway Protocol (BGP) 693 Parameters" with a subregistry of "BGP Path Attributes". IANA is 694 requested to assign a new Path attribute called "BGP-LS Map 695 attribute" (TBD1 in this document) with this document as a reference. 697 8.2. New BGP-LS Map attribute TLVs Type Registry 699 IANA maintains a registry of "Border Gateway Protocol (BGP) 700 Parameters". IANA is request to create a new subregistry called the 701 "BGP-LS Map attribute TLVs" registry. 703 Valid values are in the range 0 to 255. 705 o Values 0 and 255 are to be marked "Reserved, not to be allocated". 707 o Values 1 through 254 are to be assigned according to the "First 708 Come First Served" policy [RFC8126] 710 This document should be given as a reference for this registry. The 711 new registry should track: 713 o Type 715 o Name 717 o Reference Document or Contact 719 o Registration Date 721 The registry should initially be populated as follows: 723 Type | Name | Reference | Date 724 ------+-------------------------+---------------+--------------- 725 1 | Map TLV | [This.I-D] | Date-to-be-set 726 2 | DSCP List TLV | [This.I-D] | Date-to-be-set 727 3 | Color List TLV | [This.I-D] | Date-to-be-set 728 4 | Root TLV | [This.I-D] | Date-to-be-set 730 9. Acknowledgements 732 The authors are grateful to all those who contributed to the 733 discussions that led to this work: Ron Bonica, Stewart Bryant, Jie 734 Dong, and Keyur Patel. 736 10. Contributors 738 The following people contributed text to this document: 740 A N Other 741 Email: another@foocorp.doc 743 11. References 745 11.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, 749 DOI 10.17487/RFC2119, March 1997, 750 . 752 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 753 "Definition of the Differentiated Services Field (DS 754 Field) in the IPv4 and IPv6 Headers", RFC 2474, 755 DOI 10.17487/RFC2474, December 1998, 756 . 758 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 759 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 760 DOI 10.17487/RFC4271, January 2006, 761 . 763 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 764 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 765 2006, . 767 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 768 Subsequent Address Family Identifier (SAFI) and the BGP 769 Tunnel Encapsulation Attribute", RFC 5512, 770 DOI 10.17487/RFC5512, April 2009, 771 . 773 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 774 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 775 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 776 2015, . 778 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 779 Patel, "Revised Error Handling for BGP UPDATE Messages", 780 RFC 7606, DOI 10.17487/RFC7606, August 2015, 781 . 783 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 784 S. Ray, "North-Bound Distribution of Link-State and 785 Traffic Engineering (TE) Information Using BGP", RFC 7752, 786 DOI 10.17487/RFC7752, March 2016, 787 . 789 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 790 Writing an IANA Considerations Section in RFCs", BCP 26, 791 RFC 8126, DOI 10.17487/RFC8126, June 2017, 792 . 794 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 795 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 796 May 2017, . 798 11.2. Informative References 800 [I-D.ietf-idr-segment-routing-te-policy] 801 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 802 E., and S. Lin, "Advertising Segment Routing Policies in 803 BGP", draft-ietf-idr-segment-routing-te-policy-05 (work in 804 progress), November 2018. 806 [I-D.ietf-teas-enhanced-vpn] 807 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 808 Framework for Enhanced Virtual Private Networks (VPN+) 809 Service", draft-ietf-teas-enhanced-vpn-01 (work in 810 progress), February 2019. 812 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 813 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 814 February 2006, . 816 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 817 Reflection: An Alternative to Full Mesh Internal BGP 818 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 819 . 821 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 822 R., Patel, K., and J. Guichard, "Constrained Route 823 Distribution for Border Gateway Protocol/MultiProtocol 824 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 825 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 826 November 2006, . 828 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 829 Decraene, B., Litkowski, S., and R. Shakir, "Segment 830 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 831 July 2018, . 833 [TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP 834 TS23.501", 2016, 835 . 838 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 839 and requirements - 3GPP TS28.530", 2016, 840 . 843 Authors' Addresses 845 John Drake 846 Juniper Networks 848 Email: jdrake@juniper.net 850 Adrian Farrel 851 Old Dog Consulting 853 Email: adrian@olddog.co.uk