idnits 2.17.1 draft-drake-bess-enhanced-vpn-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 (August 10, 2020) is 1355 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 (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-09 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-06 Summary: 2 errors (**), 0 flaws (~~), 5 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: February 11, 2021 Old Dog Consulting 6 L. Jalil 7 Verizon 8 A. Lingala 9 AT&T 10 August 10, 2020 12 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs 13 draft-drake-bess-enhanced-vpn-04 15 Abstract 17 Future networks that support advanced services, such as those enabled 18 by 5G mobile networks, envision a set of overlay networks each with 19 different performance and scaling properties. These overlays are 20 known as network slices and are realized over a common underlay 21 network. 23 In order to support network slicing, as well as to offer enhanced VPN 24 services in general, it is necessary to define a mechanism by which 25 specific resources (links and/or nodes) of an underlay network can be 26 used by a specific network slice, VPN, or set of VPNs. This document 27 sets out such a mechanism for use in Segment Routing networks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 11, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 3 66 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 5 67 4.1. The BGP-LS Filter Attribute . . . . . . . . . . . . . . . 7 68 4.1.1. The Filter TLV . . . . . . . . . . . . . . . . . . . 8 69 4.1.2. The DSCP List TLV . . . . . . . . . . . . . . . . . . 9 70 4.1.3. The Color List TLV . . . . . . . . . . . . . . . . . 10 71 4.1.4. The Root TLV . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 73 5. Comparison With ACTN . . . . . . . . . . . . . . . . . . . . 12 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. MP2MP Connectivity . . . . . . . . . . . . . . . . . . . 13 76 6.2. P2MP Unidirectional Connectivity . . . . . . . . . . . . 14 77 6.3. P2P Unidirectional Connectivity . . . . . . . . . . . . . 15 78 6.4. P2P Bidirectional Connectivity . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. Manageability Considerations . . . . . . . . . . . . . . . . 17 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 9.1. New BGP Path Attribute . . . . . . . . . . . . . . . . . 17 83 9.2. New BGP-LS Filter attribute TLVs Type Registry . . . . . 18 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 11.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 Network slicing is an approach to network operations that builds on 93 the concept of network abstraction to provide programmability, 94 flexibility, and modularity. Driven largely by needs surfacing from 95 5G, the concept of network slicing has gained traction, for example 96 in [TS23501] and [TS28530]. Network slicing requires the underlying 97 network to support partitioning the network resources to provide the 98 client with dedicated (private) networking, computing, and storage 99 resources drawn from a shared pool. The slices may be seen as (and 100 operated as) virtual networks. 102 Advanced services drive a need to create virtual networks with 103 enhanced characteristics. The tenant of such a virtual network can 104 require a degree of isolation and performance that previously could 105 only be satisfied by dedicated networks. Additionally, the tenant 106 may ask for some level of control to their virtual networks, e.g., to 107 customize the service forwarding paths in the underlying network. 109 The concepts of "enhanced VPNs" and "network slicing" are introduced 110 in [I-D.ietf-teas-enhanced-vpn]. 112 In order to support network slicing, as well as to offer enhanced VPN 113 services in general, it is necessary to define a mechanism by which 114 specific resources (links and/or nodes) of an underlay network can be 115 used by a specific network slice, VPN, or set of VPNs. This document 116 sets out such a mechanism for use in Segment Routing networks 117 [RFC8402] and builds on the ideas introduced in 118 [I-D.ietf-idr-segment-routing-te-policy]. I.e., it generalizes that 119 work to support multipoint-to-multipoint (MP2MP), point-to-multipoint 120 (P2MP), and bidirectional point-to-point (P2P) topologies; it 121 integrates BGP-based VPN support ([RFC4364], [RFC7432]); it supports 122 DSCP as well a Color-based forwarding, and it uses BGP Link-State 123 (BGP-LS) [RFC7752] to distribute topology information. 125 2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Overview of Approach 135 The approach is based on a network controller that uses the {source, 136 destination} traffic matrix and the performance and scaling 137 properties of each network slice, VPN, or set of VPNs in conjunction 138 with the topology of the underlay network to assign each network 139 slice, VPN, or set of VPNs a set of underlay links and nodes that it 140 can use. That is, each network slice, VPN, or set of VPNs gets a 141 subset, either dedicated or shared, of the resources in the underlay 142 network. 144 It should be noted that resources can be assigned at any of the 145 following granularities: 147 o All PEs in a given VPN 149 o A set of PEs in a given VPN 151 o An individual PE in a given VPN. 153 Once the network controller has determined the resource assignments, 154 it distributes this information to the PEs that participate in each 155 VPN using the usual VPN information dissemination tools, e.g., route 156 targets (RT) [RFC4360], route reflectors (RR) [RFC4456], and RT 157 constraints [RFC4684]. 159 This information is distributed to the PEs by giving them a 160 customized and limited view of the underlay network on the basis of a 161 network slice, a VPN, or a set of VPNs. Each PE will have a complete 162 view of the underlay network and this customized and limited view 163 acts as filter on the underlay network telling the PE which underlay 164 network resources it can use to direct the traffic of a given network 165 slice, VPN, or set of VPNs to best deliver end-to-end services. 167 The resource allocation information is encoded using BGP-LS. This 168 approach is chosen for the following reasons: 170 o It is BGP-based so it integrates easily with the existing BGP- 171 based VPN infrastructure ([RFC4364], [RFC4684]) 173 o It supports Segment Routing which is necessary to enforce the PEs' 174 usage of the resources allocated to the VPN or set of VPNs 176 o It supports Segment Routing which is necessary to enforce the PEs' 177 usage of the resources allocated to the network slice, VPN, or set 178 of VPNs. The use of RSVP-TE ([RFC3209]) rather than Segment 179 Routing is at the discretion of the network operator as BGP-LS 180 supports both and either confines a packet flow to a specific 181 path. 183 o It supports inter-AS connectivity which is a perquisite for 184 supporting the existing BGP-based VPN infrastructure 186 o It is canonical, in that it can be used to advertise the resources 187 of underlay networks that use either IS-IS or OSPF 189 It should be noted that this mechanism also follows the scalability 190 model of the existing BGP-based VPN infrastructure, which is that the 191 per-VPN information is restricted to only those PE routers that are 192 supporting that VPN and that the P routers have no per-VPN state. 194 The PEs in non-enhanced VPNs do not receive this resource allocation 195 information and would not confine their usage of the underlay network 196 resources. In order to ensure that the underlay network resources 197 allocated to enhanced VPNs are not inadvertently used by the PEs in 198 non-enhanced VPNs, the network controller SHOULD ensure that the IGP 199 and TE metrics for these resources is higher than the metrics for the 200 underlay network resources allocated to non-enhanced VPNs. In 201 certain situations, detailed in Section 4, PEs in enhanced VPNs will 202 use the underlay networks resources allocated to non-enhanced VPNs. 204 Additional to the programming of the PEs and its computation and 205 assignment of resources for use by network slices, VPNs, or sets of 206 VPNs, the network controller also instructs the P routers to make the 207 actual allocation of these resources by assigning link bandwidth to a 208 specific DSCP or adjacency SID [I-D.dong-spring-sr-for-enhanced-vpn]. 210 4. Detailed Protocol Operation 212 We define a BGP-LS Filter to be a BGP-LS encoded description of a 213 subset of the links and nodes in the underlay network. A BGP-LS 214 Filter defines the topology for a network slice or a set of one or 215 more VPNs. The topology defined by a BGP-LS Filter needs to provide 216 connectivity between the PEs in a given network slice, VPN or set of 217 VPNs. I.e., it connects the PEs in these VPNs and is used by them to 218 send packets to each other. A given filter is tagged with the route 219 targets of the VPNs whose PEs are to import the filter. A BGP-LS 220 Filter is pushed southbound to those PEs by the network controller 221 and SHOULD provide multiple paths between a given ingress/egress PE 222 pair. 224 Note that there will be multiple BGP-LS Filters in a given network 225 deployment and that a given underlay network link or node may appear 226 in more than one of them. In order to provide disambiguation AFI 227 16388 (BGP-LS) and SAFI 72 (BGP-LS-VPN) are used in BGP-LS UPDATE 228 messages and the network controller SHOULD allocate a different route 229 distinguisher (RD) to each BGP-LS Filter. 231 Within a given VPN, when an ingress PE needs to send a packet to an 232 egress PE it selects a path to that egress PE from the topology 233 defined by the BGP-LS Filters it has imported for that VPN. It then 234 either adds a segment routing label stack specifying that path to the 235 packet or places the packet in an RSVP-TE LSP which uses that path. 236 The ingress PE may use any path computation it wishes if that path 237 computation confines the path to the topology defined by the relevant 238 set of BGP-LS Filters. 240 If Segment Routing is used and a nodal SID is placed in the segment 241 routing label stack, then when that segment is active the P routers 242 will forward the packet using the underlay network resources 243 allocated to non-enhanced VPNs. Similarly, if the RSVP-TE LSP was 244 established using a loose source route to the subject node, the path 245 to that node was selected using the underlay network resources 246 allocated to non-enhanced VPNs. 248 Because the BGP-LS UPDATE messages specifying a BGP-LS Filter may 249 arrive in any order and the BGP-LS UPDATE messages of multiple BGP-LS 250 Filters may be interleaved, there is a need for a new attribute that 251 is attached to a BGP-LS UPDATE. This attribute contains a Filter ID, 252 a Filter version number, a Filter type (MP2MP, P2MP, or P2P), the 253 total number of fragments in the filter, and the specific fragment 254 number of the piece in hand. I.e., it is assumed that a PE may 255 import more than one BGP-LS Filter, that a given BGP-LS Filter may 256 change over time, and that a given BGP-LS Filter may span multiple 257 BGP-LS UPDATE messages. The Filter ID needs to be unique across the 258 set of VPNs into which the BGP-LS Filter is to be imported. 260 A BGP-LS Filter that is created for a set of VPNs will contain a set 261 of network resources sufficient to connect the PEs in each VPN in the 262 set and each of the BGP-LS UPDATE messages for the filter MUST be 263 tagged with the RT for each VPN in the set. 265 If a PE imports more than one BGP-LS Filter it may use the union of 266 the links and nodes specified in each filter when selecting a path. 267 A PE should give precedence to BGP-LS Filters of type P2MP and P2P 268 when selecting a path. Routes targets specific to a given VPN/PE 269 pair are needed for BGP-LS Filters of type P2MP and P2P. 271 A given BGP-LS Filter may change in response to updates to the PE 272 membership in a VPN to which the BGP-LS Filter applies or to updates 273 to the underlay network. This implies that the network controller 274 needs to be connected to the route reflectors associated with the 275 VPNs for which it is providing BGP-LS maps. When this occurs, the 276 network controller should push a new version of the affected BGP-LS 277 Filters. That is, it increments the version number of each BGP-LS 278 Filter. Note that a network controller does not need to compute new 279 BGP-LS Filters in response to an individual link or node failure in 280 the underlay network if connectivity still exists among the PEs in 281 the network slice, VPN or set or VPNs with the existing BGP-LS 282 Filters. 284 A BGP-LS Filter cannot be used by a PE until it is completely 285 assembled. If the BGP-LS Filter that is being assembled is a newer 286 version of a BGP-LS Filter that the PE is currently using, the PE 287 should continue to use its current version of the BGP-LS Filter until 288 the newer version is completely assembled. 290 When selecting a path using one or more BGP-LS Filters, an ingress PE 291 can use a link or node only if it is active in the underlay network. 292 If this precludes connectivity to the egress PE it may use the 293 underlay network resources allocated to non-enhanced VPNs to reach 294 the egress PE. 296 Additionally, when there is a newly activated PE it will not be 297 present in any of the BGP-LS Filters used by the other PEs. Until a 298 new BGP-LS Filter or Filters that contain that PE has been 299 distributed, other PEs will use the underlay network resources 300 allocated to non-enhanced VPNs to reach the newly activated PE and it 301 use these resources to reach other PEs. 303 4.1. The BGP-LS Filter Attribute 305 [RFC4271] defines the BGP Path attribute. This document introduces a 306 new Optional Transitive Path attribute called the BGP-LS Filter 307 attribute with value TBD1 to be assigned by IANA. 309 The first BGP-LS Filter attribute MUST be processed and subsequent 310 instances MUST be ignored. 312 The common fields of the BGP-LS Filter attribute are set as follows: 314 o Optional bit is set to 1 to indicate that this is an optional 315 attribute. 317 o The Transitive bit is set to 1 to indicate that this is a 318 transitive attribute. 320 o The Extended Length bit is set according to the length of the BGP- 321 LS Filter attribute as defined in [RFC4271]. 323 o The Attribute Type Code is set to TBD1. 325 The content of the BGP-LS Filter attribute is a series of Type- 326 Length-Value (TLV) constructs. Each TLV may include sub-TLVs. All 327 TLVs and sub-TLVs have a common format that is: 329 o Type: A single octet indicating the type of the BGP-LS Filter 330 attribute TLV. Values are taken from the registry described in 331 Section 9.2. 333 o Length: A two octet field indicating the length of the data 334 following the Length field counted in octets. 336 o Value: The contents of the TLV. 338 The formats of the TLVs defined in this document are shown in the 339 following sections. The presence rules and meanings are as follows. 341 o The BGP-LS Filter attribute MUST contain a Filter TLV. 343 o The BGP-LS Filter attribute MAY contain a DSCP List TLV. 345 o The BGP-LS Filter attribute MAY contain a Color List TLV. 347 o The BGP-LS Filter attribute MAY contain a Root TLV. 349 4.1.1. The Filter TLV 351 The BGP-LS Filter attribute MUST contain exactly one Filter TLV. Its 352 format is shown in Figure 1. Note that a given BGP-LS Filter may 353 span multiple UPDATE messages and the Topology, Version Number, and 354 the Number of Fragments fields in the BGP-LS Filter attribute 355 contained in each UPDATE message MUST be set to the same value or the 356 BGP-LS Filter is unusable. 358 +--------------------------------------------+ 359 | Type = 1 (1 octet) | 360 +--------------------------------------------+ 361 | Length (2 octets) | 362 +--------------------------------------------+ 363 | Topology (1 Octet) | 364 +--------------------------------------------+ 365 | ID (4 Octets) | 366 +--------------------------------------------+ 367 | Version Number (4 Octets) | 368 +--------------------------------------------+ 369 | Number of Fragments (4 Octets) | 370 +--------------------------------------------+ 371 | Fragment Number (4 Octets) | 372 +--------------------------------------------+ 374 Figure 1: The Filter TLV Format 376 The fields are as follows: 378 o Type is set to 1 to indicate a Filter TLV. 380 o Length is set to 17 octets. 382 o Topology indicates whether this BGP-LS Filter is MP2MP, P2MP, P2P 383 unidirectional, or P2P bidirectional. 385 o The ID of this BGP-LS Filter. This ID needs to be unique within 386 the set of VPNs into which the BGP-LS Filter is to be imported. 388 o The Version Number of this BGP-LS Filter. I.e., the contents of a 389 BGP-LS Filter with a given ID may change over time and this field 390 indicates the latest version of that BGP-LS Filter. 392 o Number of Fragments indicates the number of BGP UPDATE messages 393 defining this BGP-LS Filter. 395 o Fragment Number indicates ordinal position of this UPDATE message 396 within the set of UPDATE messages defining this BGP-LS Filter. A 397 BGP-LS Filter is not complete, i.e., usable, until all UPDATE 398 messages have been received with Fragment Numbers in the range 1 399 <= Fragment Number <= Number of Fragments. An UPDATE message with 400 a Fragment Number outside this range is to be ignored. 402 4.1.2. The DSCP List TLV 404 The DSCP List TLV MAY be included in the BGP-LS Filter attribute. If 405 included, a packet whose DSCP matches a DSCP in the DSCP list is to 406 be forwarded using the BGP-LS Filter defined by the containing BGP-LS 407 Filter attribute. The first DSCP List TLV MUST be processed and 408 subsequent instances MUST be ignored. The format of the DSCP List 409 TLV is shown in Figure 2. 411 +--------------------------------------------+ 412 | Type = 2 (1 octet) | 413 +--------------------------------------------+ 414 | Length (2 octets) | 415 +--------------------------------------------+ 416 | DSCP List (variable) | 417 +--------------------------------------------+ 419 Figure 2: The DSCP List TLV Format 421 The fields are as follows: 423 o Type is set to 2 to indicate a DSCP List TLV. 425 o Length indicates the length in octets of the DSCP List. 427 o DSCP List contains a list of DSCPs, each one octet in length and 428 encoded in the standard format. 430 4.1.3. The Color List TLV 432 The Color List TLV MAY be included in the BGP-LS Filter attribute. 433 If a BGP UPDATE contains a Color extended community with a color (as 434 defined by [RFC5512]) that matches an entry in the Color List, then a 435 packet whose destination is covered by one of the routes in that 436 UPDATE is to be forwarded using the BGP-LS Filter defined by the 437 containing BGP-LS Filter attribute. The first Color List TLV MUST be 438 processed and subsequent instances MUST be ignored. The format of 439 the Color List TLV is shown in Figure 3. 441 Note that if both a DSCP List and a Color List TLV are included in a 442 BGP-LS Filter attribute, packets matching an entry in either list are 443 to be forwarded using the BGP-LS Filter defined by the containing 444 BGP-LS Filter attribute. If neither list is included then all 445 packets for that network slice, VPN, or set of VPNs can be forwarded 446 using the BGP-LS Filter defined by the containing BGP-LS Filter 447 attribute. 449 +--------------------------------------------+ 450 | Type = 3 (1 octet) | 451 +--------------------------------------------+ 452 | Length (2 octets) | 453 +--------------------------------------------+ 454 | Color List (variable) | 455 +--------------------------------------------+ 457 Figure 3: The Color List TLV Format 459 The fields are as follows: 461 o Type is set to 3 to indicate a Color List TLV. 463 o Length indicates the length in octets of the Color List. 465 o Color List contains a list of Colors, each four octets in length. 467 4.1.4. The Root TLV 469 The Root TLV MUST be included in the BGP-LS Filter attribute if its 470 topology is of type P2MP or P2P unidirectional. It defines the root 471 node for that topology and if it is not present the BGP-LS Filter is 472 unusable. The TLV, if present, MUST be ignored if the topology is of 473 type MP2MP or P2P bidirectional. 475 The Root TLV is structured as shown in Figure 4 and MAY contain any 476 of the sub-TLVs defined in section 3.2.1.4 of [RFC7752]. 478 +--------------------------------------------+ 479 | Type = 3 (1 octet) | 480 +--------------------------------------------+ 481 | Length (2 octets) | 482 +--------------------------------------------+ 483 | Sub-TLVs (variable) | 484 +--------------------------------------------+ 486 Figure 4: The Root TLV Format 488 The fields are as follows: 490 o Type is set to 3 to indicate a Color List TLV. 492 o Length indicates the length in octets of the Color List. 494 o There follows a sequence of zero or more sub-TLVs as defined in 495 section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be 496 deduced from the Length field of the Root TLV and from the Length 497 fields of each of the sub-TLVs. 499 4.2. Error Handling 501 Section 6 of [RFC4271] describes the handling of malformed BGP 502 attributes, or those that are in error in some way. [RFC7606] 503 revises BGP error handling specifically for the for UPDATE message, 504 provides guidelines for the authors of documents defining new 505 attributes, and revises the error handling procedures for a number of 506 existing attributes. This document introduces the BGP-LS Filter 507 attribute and so defines error handling as follows: 509 o When parsing a message, an unknown Attribute Type code or a length 510 that suggests that the attribute is longer than the remaining 511 message is treated as a malformed message and the "treat-as- 512 withdraw" approach used as per [RFC7606]. 514 o When parsing a message that contains an BGP-LS Filter attribute, 515 the following cases constitute errors: 517 1. Optional bit is set to 0 in BGP-LS Filter attribute. 519 2. Transitive bit is set to 0 in BGP-LS Filter attribute. 521 3. The attribute does not contain a Filter TLV or it contains 522 more than one Filter TLV. 524 4. The TLV length indicates that the TLV extends beyond the end 525 of the BGP-LS Filter attribute. 527 5. There is an unknown TLV type field found in BGP-LS Filter 528 attribute. 530 o The errors listed above are treated as follows: 532 1., 2., 3., 4.: The attribute MUST be treated as malformed and 533 the "treat-as-withdraw" approach used as per [RFC7606]. 535 5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 536 continue. 538 5. Comparison With ACTN 540 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 541 framework that facilitates the abstraction of underlying network 542 resources to higher-layer applications and that allows nework 543 operators to create virtual networks through the abstraction of the 544 operators' network resources. The applicability of ACTN to network 545 slicing is discussed further in 546 [I-D.king-teas-applicability-actn-slicing]. 548 Essentially the ACTN framework describes how to request and provision 549 a network slice, but does not define how the network is operated to 550 deliver that slice. Therefore, a direct comparison between this work 551 and ACTN is not appropriate. 553 6. Examples 555 Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6) 556 are connected across a network of twelve P nodes (P1 through P12). 557 Each PE is dual-homed, and the P nodes are variously connected so 558 that there are multiple routes between PEs. 560 PE3 PE4 561 |\ /| 562 | \ / | 563 | \ / | 564 | \/ | 565 | /\ | 566 | / \ | 567 | / \ | 568 |/ \| 569 P1--------P2 570 / |\ /| \ 571 / | \ / | \ 572 / | \ / | \ 573 / | \/ | \ 574 P3-------P4--------P5-------P6 575 | / | /\ | \ | 576 | / | / \ | \ | 577 | / | / \ | \ | 578 |/ |/ \| \| 579 P7---P8--P9--------P10-P11-P12 580 |\ /| |\ /| 581 | \/ | | \/ | 582 | /\ | | /\ | 583 |/ \| |/ \| 584 PE1 PE2 PE5 PE6 586 Figure 5: Underlay Network Topology 588 6.1. MP2MP Connectivity 590 Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that 591 connects PE1, PE3, and PE6 can be installed over the underlay 592 network. Path have been computed so that, for example, PE1 is 593 connected to both PE3 and PE6 via a pair of redundant paths. 594 Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to 595 PE1 and PE3. 597 PE3 PE4 598 | \ 599 | \ 600 | \ 601 | \ 602 | \ 603 | \ 604 | \ 605 | \ 606 P1 P2 607 / \ /| 608 / \ / | 609 / \ / | 610 / \ / | 611 P3 P4 X P5 P6 612 | / \ \ 613 | / \ \ 614 | / \ \ 615 | / \ \ 616 P7 P8--P9---------P10-P11 P12 617 | / \ | 618 | / \ | 619 | / \ | 620 |/ \| 621 PE1 PE2 PE5 PE6 623 Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6 625 6.2. P2MP Unidirectional Connectivity 627 Figure 7 shows the provision of a Point-to-Multipoint (P2MP) rooted 628 at PE3 and connected to PE1 and PE6. As in the previous example, a 629 redundant pair of paths is established between PE3 and each of PE1 630 and PE6. Thus, the two paths from PE3 to PE1 are PE3-P1-P4-P7-PE1 631 and PE3-P2-P9-P8-PE1. 633 PE3 PE4 634 | \ 635 | \ 636 | \ 637 | \ 638 | \ 639 | \ 640 | \ 641 | \ 642 P1 P2 643 |\ / \ 644 | \ / \ 645 | \ / \ 646 | \ / \ 647 P3 P4 X P5 P6 648 / / \ | 649 / / \ | 650 / / \ | 651 / / \ | 652 P7---P8--P9 P10-P11 P12 653 | / \ | 654 | / \ | 655 | / \ | 656 |/ \| 657 PE1 PE2 PE5 PE6 659 Figure 7: A P2MP Unidirectional Service Installed at PE3 661 6.3. P2P Unidirectional Connectivity 663 Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and 664 connected to PE3. This is equivalent to a Segment Routing Traffic 665 Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy] 666 installed at PE1. 668 As in the previous examples, a pair of redundant paths are computed. 670 PE3 PE4 671 |\ 672 | \ 673 | \ 674 | \ 675 | \ 676 | \ 677 | \ 678 | \ 679 P1 P2 680 | | 681 | | 682 | | 683 | | 684 P3 P4 P5 P6 685 / | 686 / | 687 / | 688 / | 689 P7 P8--P9--------P10 P11 P12 690 | / 691 | / 692 | / 693 |/ 694 PE1 PE2 PE5 PE6 696 Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at 697 PE1 699 6.4. P2P Bidirectional Connectivity 701 Figure 9 show a bidirectional P2P service connecting PE1 and PE6. 702 This is equivalent to a Segment Routing Traffic Engineering (SR TE) 703 Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and 704 PE6. 706 PE3 PE4 708 P1 P2 710 P3 P4--------P5 P6 711 / \ 712 / \ 713 / \ 714 / \ 715 P7 P8--P9--------P10-P11 P12 716 | / \ | 717 | / \ | 718 | / \ | 719 |/ \| 720 PE1 PE2 PE5 PE6 722 Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6 724 7. Security Considerations 726 TBD 728 8. Manageability Considerations 730 Per VPN OAM and telemetry will be required in order to monitor and 731 verify the performance of network slices. This is particularly 732 important when the performance of a network slice has been committed 733 to a customer through a Service Level Agreement. 735 TBD 737 9. IANA Considerations 739 9.1. New BGP Path Attribute 741 IANA maintains a registry of "Border Gateway Protocol (BGP) 742 Parameters" with a subregistry of "BGP Path Attributes". IANA is 743 requested to assign a new Path attribute called "BGP-LS Filter 744 attribute" (TBD1 in this document) with this document as a reference. 746 9.2. New BGP-LS Filter attribute TLVs Type Registry 748 IANA maintains a registry of "Border Gateway Protocol (BGP) 749 Parameters". IANA is request to create a new subregistry called the 750 "BGP-LS Filter attribute TLVs" registry. 752 Valid values are in the range 0 to 255. 754 o Values 0 and 255 are to be marked "Reserved, not to be allocated". 756 o Values 1 through 254 are to be assigned according to the "First 757 Come First Served" policy [RFC8126] 759 This document should be given as a reference for this registry. The 760 new registry should track: 762 o Type 764 o Name 766 o Reference Document or Contact 768 o Registration Date 770 The registry should initially be populated as follows: 772 Type | Name | Reference | Date 773 ------+-------------------------+---------------+--------------- 774 1 | Filter TLV | [This.I-D] | Date-to-be-set 775 2 | DSCP List TLV | [This.I-D] | Date-to-be-set 776 3 | Color List TLV | [This.I-D] | Date-to-be-set 777 4 | Root TLV | [This.I-D] | Date-to-be-set 779 10. Acknowledgements 781 The authors are grateful to all those who contributed to the 782 discussions that led to this work: Ron Bonica, Stewart Bryant, Jie 783 Dong, Keyur Patel, and Colby Barth. 785 11. References 787 11.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 795 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 796 DOI 10.17487/RFC4271, January 2006, 797 . 799 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 800 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 801 2006, . 803 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 804 Subsequent Address Family Identifier (SAFI) and the BGP 805 Tunnel Encapsulation Attribute", RFC 5512, 806 DOI 10.17487/RFC5512, April 2009, 807 . 809 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 810 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 811 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 812 2015, . 814 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 815 Patel, "Revised Error Handling for BGP UPDATE Messages", 816 RFC 7606, DOI 10.17487/RFC7606, August 2015, 817 . 819 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 820 S. Ray, "North-Bound Distribution of Link-State and 821 Traffic Engineering (TE) Information Using BGP", RFC 7752, 822 DOI 10.17487/RFC7752, March 2016, 823 . 825 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 826 Writing an IANA Considerations Section in RFCs", BCP 26, 827 RFC 8126, DOI 10.17487/RFC8126, June 2017, 828 . 830 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 831 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 832 May 2017, . 834 11.2. Informative References 836 [I-D.dong-spring-sr-for-enhanced-vpn] 837 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 838 Z., and F. Clad, "Segment Routing for Resource Guaranteed 839 Virtual Networks", draft-dong-spring-sr-for-enhanced- 840 vpn-09 (work in progress), July 2020. 842 [I-D.ietf-idr-segment-routing-te-policy] 843 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 844 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 845 Routing Policies in BGP", draft-ietf-idr-segment-routing- 846 te-policy-09 (work in progress), May 2020. 848 [I-D.ietf-teas-enhanced-vpn] 849 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 850 Framework for Enhanced Virtual Private Networks (VPN+) 851 Service", draft-ietf-teas-enhanced-vpn-06 (work in 852 progress), July 2020. 854 [I-D.king-teas-applicability-actn-slicing] 855 King, D., Drake, J., and H. Zheng, "Applicability of 856 Abstraction and Control of Traffic Engineered Networks 857 (ACTN) to TE Network Slicing", draft-king-teas- 858 applicability-actn-slicing-06 (work in progress), July 859 2020. 861 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 862 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 863 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 864 . 866 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 867 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 868 February 2006, . 870 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 871 Reflection: An Alternative to Full Mesh Internal BGP 872 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 873 . 875 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 876 R., Patel, K., and J. Guichard, "Constrained Route 877 Distribution for Border Gateway Protocol/MultiProtocol 878 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 879 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 880 November 2006, . 882 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 883 Decraene, B., Litkowski, S., and R. Shakir, "Segment 884 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 885 July 2018, . 887 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 888 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 889 DOI 10.17487/RFC8453, August 2018, 890 . 892 [TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP 893 TS23.501", 2016, 894 . 897 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 898 and requirements - 3GPP TS28.530", 2016, 899 . 902 Authors' Addresses 904 John Drake 905 Juniper Networks 907 Email: jdrake@juniper.net 909 Adrian Farrel 910 Old Dog Consulting 912 Email: adrian@olddog.co.uk 914 Luay Jalil 915 Verizon 917 Email: luay.jalil@verizon.com 919 Avinash Lingala 920 AT&T 922 Email: ar977m@att.com