idnits 2.17.1 draft-drake-bess-enhanced-vpn-05.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 (December 7, 2020) is 1207 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) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-20 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-12 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == 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-08 == Outdated reference: A later version (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-01 Summary: 1 error (**), 0 flaws (~~), 7 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: June 10, 2021 Old Dog Consulting 6 L. Jalil 7 Verizon 8 A. Lingala 9 AT&T 10 December 7, 2020 12 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs 13 draft-drake-bess-enhanced-vpn-05 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. In the context of IETF technologies, they are known as IETF 22 network slices. 24 In order to support IETF network slicing, as well as to offer 25 enhanced VPN services in general, it is necessary to define a 26 mechanism by which specific resources (links and/or nodes) of an 27 underlay network can be used by a specific network slice, VPN, or set 28 of VPNs. This document sets out such a mechanism for use in Segment 29 Routing networks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 10, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 4 68 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 6 69 4.1. The BGP-LS Filter Attribute . . . . . . . . . . . . . . . 8 70 4.1.1. The Filter TLV . . . . . . . . . . . . . . . . . . . 9 71 4.1.2. The DSCP List TLV . . . . . . . . . . . . . . . . . . 10 72 4.1.3. The Color List TLV . . . . . . . . . . . . . . . . . 11 73 4.1.4. The Root TLV . . . . . . . . . . . . . . . . . . . . 12 74 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 12 75 5. Comparison With ACTN . . . . . . . . . . . . . . . . . . . . 13 76 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. MP2MP Connectivity . . . . . . . . . . . . . . . . . . . 14 78 6.2. P2MP Unidirectional Connectivity . . . . . . . . . . . . 15 79 6.3. P2P Unidirectional Connectivity . . . . . . . . . . . . . 16 80 6.4. P2P Bidirectional Connectivity . . . . . . . . . . . . . 17 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. New BGP Path Attribute . . . . . . . . . . . . . . . . . 19 85 9.2. New BGP-LS Filter attribute TLVs Type Registry . . . . . 19 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 12.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 Network slicing is an approach to network operations that builds on 96 the concept of network abstraction to provide programmability, 97 flexibility, and modularity. Driven largely by needs surfacing from 98 5G, the concept of network slicing has gained traction, for example 99 in [TS23501] and [TS28530]. Network slicing requires the underlying 100 network to support partitioning the network resources to provide the 101 client with dedicated (private) networking, computing, and storage 102 resources drawn from a shared pool. The network slices may be seen 103 as (and operated as) virtual networks. In the context of IETF 104 tehnologies network slices are known as "IETF network slices", 105 however, in this document we simply use the term "network slice" 106 since we are working within this context. 108 Advanced services drive a need to create virtual networks with 109 enhanced characteristics. The tenant of such a virtual network can 110 require a degree of isolation and performance that previously could 111 only be satisfied by dedicated networks. Additionally, the tenant 112 may ask for some level of control to their virtual networks, e.g., to 113 customize the service forwarding paths in the underlying network. 115 The concept of "IETF network slices" is introduced in 116 [I-D.nsdt-teas-ietf-network-slice-definition]. 117 [I-D.ietf-teas-enhanced-vpn] builds on this concept and introduces 118 "enhanced VPNs". 120 In order to support network slicing, as well as to offer enhanced VPN 121 services in general, it is necessary to define a mechanism by which 122 specific resources (links and/or nodes) of an underlay network can be 123 used by a specific network slice, a single VPN, or a well-defined set 124 of VPNs. This document sets out such a mechanism for use in Segment 125 Routing networks [RFC8402] and builds on the ideas introduced in 126 [I-D.ietf-idr-segment-routing-te-policy]. I.e., it generalizes that 127 work to support multipoint-to-multipoint (MP2MP), point-to-multipoint 128 (P2MP), and bidirectional point-to-point (P2P) topologies; it 129 integrates BGP-based VPN support ([RFC4364], [RFC7432]); it supports 130 Differentiated Services Code Points (DSCP) as well a Color-based 131 forwarding, and it uses BGP Link-State (BGP-LS) [RFC7752] to 132 distribute topology information. 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Overview of Approach 144 The approach described in this document is based on a network 145 controller that uses the {source, destination} traffic matrix and the 146 performance and scaling properties of each network slice, VPN, or set 147 of VPNs in conjunction with the topology of the underlay network to 148 assign each network slice, VPN, or set of VPNs a set of underlay 149 links and nodes that it can use. That is, each network slice, VPN, 150 or set of VPNs gets a subset, either dedicated or shared, of the 151 resources in the underlay network. Note that, in this document, we 152 recognize that scalability of protocol mechanisms to partition 153 network resources is very important; this gives rise to the concept 154 of "a set of VPNs" so that the slice of network resources achieved 155 using the protocol mechanisms defined in this document can be shared 156 by a well-defined set of VPNs as configured by the network operator. 158 It should be noted that resources can be assigned at any of the 159 following granularities: 161 o All provider edge (PE) routers in a given VPN 163 o A set of PEs in a given VPN 165 o An individual PE in a given VPN. 167 There are two phases to this approach: 169 Step-1: Discovery and data gathering. Information is gathered 170 from the underlay network about the links, nodes, and network 171 resources available for use by the VPN or network slice. 173 Step-2: Configuration and provisioning. The underlay resources 174 are configured for use for the VPN or network slice. 176 Once the network controller has determined the resource assignments, 177 it distributes this information to the PEs that participate in each 178 VPN using the usual VPN information dissemination tools, e.g., route 179 targets (RT) [RFC4360], route reflectors (RR) [RFC4456], and RT 180 constraints [RFC4684]. 182 This information is distributed to the PEs by giving them a 183 customized and limited view of the underlay network on the basis of a 184 network slice, a VPN, or a set of VPNs. Each PE will have a complete 185 view of the underlay network and this customized and limited view 186 acts as filter on the underlay network telling the PE which underlay 187 network resources it can use to direct the traffic of a given network 188 slice, VPN, or set of VPNs to best deliver end-to-end services. 190 The resource allocation information is encoded using BGP-LS. This 191 approach is chosen for the following reasons: 193 o It is BGP-based so it integrates easily with the existing BGP- 194 based VPN infrastructure ([RFC4364], [RFC4684]). 196 o It supports Segment Routing which is necessary to enforce the PEs' 197 usage of the resources allocated to the VPN or set of VPNs. 199 o It supports Segment Routing which is necessary to enforce the PEs' 200 usage of the resources allocated to the network slice, VPN, or set 201 of VPNs. The use of RSVP-TE ([RFC3209]) rather than Segment 202 Routing is at the discretion of the network operator as BGP-LS 203 supports both and either confines a packet flow to a specific 204 path. 206 o It supports inter-AS connectivity which is a perquisite for 207 supporting the existing BGP-based VPN infrastructure. 209 o It is canonical, in that it can be used to advertise the resources 210 of underlay networks that use either IS-IS or OSPF. 212 It should be noted that this mechanism also follows the scalability 213 model of the existing BGP-based VPN infrastructure, which is that the 214 per-VPN information is restricted to only those PE routers that are 215 supporting that VPN and that the provider (P) routers have no per-VPN 216 state. 218 The PEs in non-enhanced VPNs do not receive this resource allocation 219 information and would not confine their usage of the underlay network 220 resources. In order to ensure that the underlay network resources 221 allocated to enhanced VPNs are not inadvertently used by the PEs in 222 non-enhanced VPNs, the network controller SHOULD ensure that the IGP 223 and traffic engineering (TE) metrics for these resources is higher 224 than the metrics for the underlay network resources allocated to non- 225 enhanced VPNs. In certain situations, detailed in Section 4, PEs in 226 enhanced VPNs will use the underlay networks resources allocated to 227 non-enhanced VPNs. 229 Additional to the programming of the PEs and its computation and 230 assignment of resources for use by network slices, VPNs, or sets of 231 VPNs, the network controller also instructs the P routers to make the 232 actual allocation of these resources by assigning link bandwidth to a 233 specific DSCP or adjacency segment identifier (SID) 234 [I-D.dong-spring-sr-for-enhanced-vpn]. 236 4. Detailed Protocol Operation 238 We define a BGP-LS Filter to be a BGP-LS encoded description of a 239 subset of the links and nodes in the underlay network. A BGP-LS 240 Filter defines all or part of the topology for a network slice or a 241 set of one or more VPNs. The topology defined by a BGP-LS Filter 242 needs to provide connectivity between the PEs in a given network 243 slice, VPN or set of VPNs. I.e., it connects the PEs in these VPNs 244 and is used by them to send packets to each other. A given filter is 245 tagged with the route targets of the VPNs whose PEs are to import the 246 filter. A BGP-LS Filter is pushed southbound to those PEs by the 247 network controller and SHOULD provide multiple paths between a given 248 ingress/egress PE pair. 250 Note that there will be multiple BGP-LS Filters in a given network 251 deployment and that a given underlay network link or node may appear 252 in more than one of them. In order to provide disambiguation, the 253 address family indicator (AFI) 16388 (BGP-LS) and the subsequent 254 address family identifier (SAFI) 72 (BGP-LS-VPN) are used in BGP-LS 255 UPDATE messages and the network controller SHOULD allocate a 256 different route distinguisher (RD) to each BGP-LS Filter. As for 257 standard VPNs, an implementation option ("RD Auto") may be offered to 258 assist in configuring unique RDs. 260 Within a given VPN, when an ingress PE needs to send a packet to an 261 egress PE it selects a path to that egress PE from the topology 262 defined by the BGP-LS Filters it has imported for that VPN. It then 263 either adds a segment routing label stack specifying that path to the 264 packet or places the packet in an RSVP-TE LSP which uses that path. 265 The ingress PE may use any path computation it wishes if that path 266 computation confines the path to the topology defined by the relevant 267 set of BGP-LS Filters. 269 If Segment Routing is used and a node SID or a prefix SID is placed 270 in the segment routing label stack, then when that segment is active 271 the P routers will forward the packet using the underlay network 272 resources allocated to non-enhanced VPNs. Similarly, if the RSVP-TE 273 label switched path (LSP) was established using a loose source route 274 to the subject node, the path to that node was selected using the 275 underlay network resources allocated to non-enhanced VPNs. 277 Because the BGP-LS UPDATE messages specifying a BGP-LS Filter may 278 arrive in any order and the BGP-LS UPDATE messages of multiple BGP-LS 279 Filters may be interleaved, there is a need for a new attribute that 280 is attached to a BGP-LS UPDATE. This attribute contains a Filter ID, 281 a Filter version number, a Filter type (MP2MP, P2MP, or P2P), the 282 total number of fragments in the filter, and the specific fragment 283 number of the piece in hand. I.e., it is assumed that a PE may 284 import more than one BGP-LS Filter, that a given BGP-LS Filter may 285 change over time, and that a given BGP-LS Filter may span multiple 286 BGP-LS UPDATE messages. The Filter ID needs to be unique across the 287 set of VPNs into which the BGP-LS Filter is to be imported. 289 A BGP-LS Filter that is created for a set of VPNs will contain a set 290 of network resources sufficient to connect between the PEs in each 291 discrete VPN in the set, and each of the BGP-LS UPDATE messages for 292 the filter MUST be tagged with the RT for each VPN in the set. 294 If a PE imports more than one BGP-LS Filter it MAY use the union of 295 the links and nodes specified in each filter when selecting a path. 297 A given BGP-LS Filter may change in response to updates to the PE 298 membership in a VPN to which the BGP-LS Filter applies or to updates 299 to the underlay network. This implies that the network controller 300 needs to be connected to the route reflectors associated with the 301 VPNs for which it is providing BGP-LS maps. When this occurs, the 302 network controller SHOULD push a new version of the affected BGP-LS 303 Filters. That is, it increments the version number of each BGP-LS 304 Filter. Note that a network controller does not need to compute new 305 BGP-LS Filters in response to an individual link or node failure in 306 the underlay network if connectivity still exists among the PEs in 307 the network slice, VPN or set or VPNs with the existing BGP-LS 308 Filters. 310 A BGP-LS Filter cannot be used by a PE until it is completely 311 assembled. If the BGP-LS Filter that is being assembled is a newer 312 version of a BGP-LS Filter that the PE is currently using, the PE 313 SHOULD continue to use its current version of the BGP-LS Filter until 314 the newer version is completely assembled. 316 When selecting a path using one or more BGP-LS Filters, an ingress PE 317 can use a link or node only if it is active in the underlay network. 318 If this precludes connectivity to the egress PE it may use the 319 underlay network resources not allocated to enhanced VPNs to reach 320 the egress PE. 322 Additionally, when there is a newly activated PE it will not be 323 present in any of the BGP-LS Filters used by the other PEs. Until a 324 new BGP-LS Filter that contains that PE has been distributed, other 325 PEs will use the underlay network resources not allocated to enhanced 326 VPNs to reach the newly activated PE, and the newly activate PE will 327 use these resources to reach other PEs. 329 4.1. The BGP-LS Filter Attribute 331 [RFC4271] defines the BGP Path attribute. This document introduces a 332 new Optional Transitive Path attribute called the BGP-LS Filter 333 attribute with value TBD1 to be assigned by IANA. 335 The first BGP-LS Filter attribute MUST be processed and subsequent 336 instances MUST be ignored. 338 The common fields of the BGP-LS Filter attribute are set as follows: 340 o Optional bit is set to 1 to indicate that this is an optional 341 attribute. 343 o The Transitive bit is set to 1 to indicate that this is a 344 transitive attribute. 346 o The Extended Length bit is set according to the length of the BGP- 347 LS Filter attribute as defined in [RFC4271]. 349 o The Attribute Type Code is set to TBD1. 351 The content of the BGP-LS Filter attribute is a series of Type- 352 Length-Value (TLV) constructs. Each TLV may include sub-TLVs. All 353 TLVs and sub-TLVs have a common format that is: 355 o Type: A single octet indicating the type of the BGP-LS Filter 356 attribute TLV. Values are taken from the registry described in 357 Section 9.2. 359 o Length: A two octet field indicating the length of the data 360 following the Length field counted in octets. 362 o Value: The contents of the TLV. 364 The formats of the TLVs defined in this document are shown in the 365 following sections. The presence rules and meanings are as follows. 367 o The BGP-LS Filter attribute MUST contain a Filter TLV. 369 o The BGP-LS Filter attribute MAY contain a DSCP List TLV. 371 o The BGP-LS Filter attribute MAY contain a Color List TLV. 373 o The BGP-LS Filter attribute MAY contain a Root TLV. 375 4.1.1. The Filter TLV 377 The BGP-LS Filter attribute MUST contain exactly one Filter TLV. Its 378 format is shown in Figure 1. Note that a given BGP-LS Filter may 379 span multiple UPDATE messages and the Topology, Version Number, and 380 the Number of Fragments fields in the BGP-LS Filter attribute 381 contained in each UPDATE message MUST be set to the same value or the 382 BGP-LS Filter is unusable. 384 +--------------------------------------------+ 385 | Type = 1 (1 octet) | 386 +--------------------------------------------+ 387 | Length (2 octets) | 388 +--------------------------------------------+ 389 | Topology (1 Octet) | 390 +--------------------------------------------+ 391 | ID (4 Octets) | 392 +--------------------------------------------+ 393 | Version Number (4 Octets) | 394 +--------------------------------------------+ 395 | Number of Fragments (4 Octets) | 396 +--------------------------------------------+ 397 | Fragment Number (4 Octets) | 398 +--------------------------------------------+ 400 Figure 1: The Filter TLV Format 402 The fields are as follows: 404 o Type is set to 1 to indicate a Filter TLV. 406 o Length is set to 17 octets. 408 o Topology indicates the topology defined by this BGP-LS Filter. 410 1. P2P unidirectional 412 2. P2P bidirectional 414 3. P2MP 416 4. MP2MP 418 o The ID of this BGP-LS Filter. This ID needs to be unique within 419 the set of VPNs into which the BGP-LS Filter is to be imported. 421 o The Version Number of this BGP-LS Filter. The contents of a BGP- 422 LS Filter with a given ID may change over time. This field 423 indicates the version of the BGP-LS Filter being advertized in 424 this UPDATE message. 426 o Number of Fragments indicates the number of BGP UPDATE messages 427 defining this BGP-LS Filter. 429 o Fragment Number indicates ordinal position of this UPDATE message 430 within the set of UPDATE messages defining this BGP-LS Filter. A 431 BGP-LS Filter is not complete, i.e., usable, until all UPDATE 432 messages have been received with Fragment Numbers in the range 1 433 <= Fragment Number <= Number of Fragments. An UPDATE message with 434 a Fragment Number outside this range is to be ignored. 436 4.1.2. The DSCP List TLV 438 The DSCP List TLV MAY be included in the BGP-LS Filter attribute. If 439 included, a packet whose DSCP matches a DSCP in the DSCP list is to 440 be forwarded using the BGP-LS Filter defined by the BGP-LS Filter 441 attribute that contains the DSCP list. The first DSCP List TLV MUST 442 be processed and subsequent instances MUST be ignored. The format of 443 the DSCP List TLV is shown in Figure 2. 445 If a DSCP List TLV is included in a BGP-LS Filter attribute, then a 446 packet that matches an entry in the list MAY be forwarded using the 447 BGP-LS Filter defined by the BGP-LS Filter attribute, but a packet 448 which doesn't match an entry in this list MUST NOT use the filter. 449 If both a DSCP List TLV and a Color List TLV (see Section 4.1.3) are 450 both included in a BGP-LS Filter attribute, packets matching an entry 451 in either list MAY be forwarded using the BGP-LS Filter defined by 452 the BGP-LS Filter attribute. If neither list is included in a BGP-LS 453 Filter attribute, then all packets for that network slice, VPN, or 454 set of VPNs can be forwarded using the BGP-LS Filter defined by the 455 containing BGP-LS Filter attribute. 457 +--------------------------------------------+ 458 | Type = 2 (1 octet) | 459 +--------------------------------------------+ 460 | Length (2 octets) | 461 +--------------------------------------------+ 462 | DSCP List (variable) | 463 +--------------------------------------------+ 465 Figure 2: The DSCP List TLV Format 467 The fields are as follows: 469 o Type is set to 2 to indicate a DSCP List TLV. 471 o Length indicates the length in octets of the DSCP List. 473 o DSCP List contains a list of DSCPs, each one octet in length and 474 encodes the DSCP per [RFC2474] as the most significant six bits of 475 the octet. 477 4.1.3. The Color List TLV 479 The Color List TLV MAY be included in the BGP-LS Filter attribute. 480 If a BGP UPDATE contains a Color extended community with a color (as 481 defined by [I-D.ietf-idr-tunnel-encaps]) that matches an entry in the 482 Color List, then a packet whose destination is covered by one of the 483 routes in that UPDATE is to be forwarded using the BGP-LS Filter 484 defined by the BGP-LS Filter attribute that contains the Color List 485 TLV. The first Color List TLV MUST be processed and subsequent 486 instances MUST be ignored. The format of the Color List TLV is shown 487 in Figure 3. 489 If Color List TLV is included in a BGP-LS Filter attribute, then a 490 packet that matches an entry in the list MAY be forwarded using the 491 BGP-LS Filter defined by the BGP-LS Filter attribute, but a packet 492 which doesn't match an entry in this list MUST NOT use the filter. 493 If both a DSCP List TLV (see Section 4.1.2 and a Color List TLV are 494 both included in a BGP-LS Filter attribute, packets matching an entry 495 in either list MAY be forwarded using the BGP-LS Filter defined by 496 the BGP-LS Filter attribute. If neither list is included in a BGP-LS 497 Filter attribute, then all packets for that network slice, VPN, or 498 set of VPNs can be forwarded using the BGP-LS Filter defined by the 499 containing BGP-LS Filter attribute. 501 +--------------------------------------------+ 502 | Type = 3 (1 octet) | 503 +--------------------------------------------+ 504 | Length (2 octets) | 505 +--------------------------------------------+ 506 | Color List (variable) | 507 +--------------------------------------------+ 509 Figure 3: The Color List TLV Format 511 The fields are as follows: 513 o Type is set to 3 to indicate a Color List TLV. 515 o Length indicates the length in octets of the Color List. 517 o Color List contains a list of Colors, each four octets in length 518 and as defined in [I-D.ietf-idr-tunnel-encaps]. 520 4.1.4. The Root TLV 522 The Root TLV MUST be included in the BGP-LS Filter attribute if its 523 topology is of type P2MP or P2P unidirectional. It defines the root 524 node for that topology and if it is not present the BGP-LS Filter is 525 unusable. The TLV, if present, MUST be ignored if the topology is of 526 type MP2MP or P2P bidirectional. 528 The Root TLV is structured as shown in Figure 4 and MAY contain any 529 of the sub-TLVs defined in section 3.2.1.4 of [RFC7752]. 531 +--------------------------------------------+ 532 | Type = 3 (1 octet) | 533 +--------------------------------------------+ 534 | Length (2 octets) | 535 +--------------------------------------------+ 536 | Sub-TLVs (variable) | 537 +--------------------------------------------+ 539 Figure 4: The Root TLV Format 541 The fields are as follows: 543 o Type is set to 3 to indicate a Color List TLV. 545 o Length indicates the length in octets of the Color List. 547 o There follows a sequence of zero or more sub-TLVs as defined in 548 section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be 549 deduced from the Length field of the Root TLV. 551 4.2. Error Handling 553 Section 6 of [RFC4271] describes the handling of malformed BGP 554 attributes, or those that are in error in some way. [RFC7606] 555 revises BGP error handling specifically for the for UPDATE message, 556 provides guidelines for the authors of documents defining new 557 attributes, and revises the error handling procedures for a number of 558 existing attributes. This document introduces the BGP-LS Filter 559 attribute and so defines error handling as follows: 561 o When parsing a message, an unknown Attribute Type code or a length 562 that suggests that the attribute is longer than the remaining 563 message is treated as a malformed message and the "treat-as- 564 withdraw" approach is used as per [RFC7606]. 566 o When parsing a message that contains an BGP-LS Filter attribute, 567 the following cases constitute errors: 569 1. Optional bit is set to 0 in BGP-LS Filter attribute. 571 2. Transitive bit is set to 0 in BGP-LS Filter attribute. 573 3. The attribute does not contain a Filter TLV or contains more 574 than one Filter TLV. 576 4. The TLV length indicates that the TLV extends beyond the end 577 of the BGP-LS Filter attribute. 579 5. There is an unknown TLV type field found in BGP-LS Filter 580 attribute. 582 The errors listed above are treated as follows: 584 1., 2., 3., 4.: The attribute MUST be treated as malformed and 585 the "treat-as-withdraw" approach used as per [RFC7606]. 587 5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 588 continue. 590 5. Comparison With ACTN 592 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 593 framework that facilitates the abstraction of underlying network 594 resources to higher-layer applications and that allows nework 595 operators to create virtual networks through the abstraction of the 596 operators' network resources. The applicability of ACTN to network 597 slicing is discussed further in 598 [I-D.king-teas-applicability-actn-slicing]. 600 Essentially the ACTN framework describes how to request and provision 601 a network slice, but does not define how the network is operated to 602 deliver that slice. Therefore, a direct comparison between this work 603 and ACTN is not appropriate. ACTN could be used as a management 604 framework to operate a slicing system built using the protocol 605 extensions defined in this document. 607 6. Examples 609 Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6) 610 are connected across a network of twelve P nodes (P1 through P12). 611 Each PE is dual-homed, and the P nodes are variously connected so 612 that there are multiple routes between PEs. 614 PE3 PE4 615 |\ /| 616 | \ / | 617 | \ / | 618 | \/ | 619 | /\ | 620 | / \ | 621 | / \ | 622 |/ \| 623 P1--------P2 624 / |\ /| \ 625 / | \ / | \ 626 / | \ / | \ 627 / | \/ | \ 628 P3-------P4--------P5-------P6 629 | / | /\ | \ | 630 | / | / \ | \ | 631 | / | / \ | \ | 632 |/ |/ \| \| 633 P7---P8--P9--------P10-P11-P12 634 |\ /| |\ /| 635 | \/ | | \/ | 636 | /\ | | /\ | 637 |/ \| |/ \| 638 PE1 PE2 PE5 PE6 640 Figure 5: Underlay Network Topology 642 6.1. MP2MP Connectivity 644 Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that 645 connects PE1, PE3, and PE6 can be installed over the underlay 646 network. Paths have been computed so that, for example, PE1 is 647 connected to both PE3 and PE6 via pairs of redundant paths. 648 Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to 649 PE1 and PE3. 651 PE3 PE4 652 | \ 653 | \ 654 | \ 655 | \ 656 | \ 657 | \ 658 | \ 659 | \ 660 P1 P2 661 / \ /| 662 / \ / | 663 / \ / | 664 / \ / | 665 P3 P4 X P5 P6 666 | / \ \ 667 | / \ \ 668 | / \ \ 669 | / \ \ 670 P7 P8--P9---------P10-P11 P12 671 | / \ | 672 | / \ | 673 | / \ | 674 |/ \| 675 PE1 PE2 PE5 PE6 677 Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6 679 6.2. P2MP Unidirectional Connectivity 681 Figure 7 shows the provision of a Point-to-Multipoint (P2MP) service 682 rooted at PE3 and connected to PE1 and PE6. As in the previous 683 example, a pair of redundant paths is established between PE3 and 684 each of PE1 and PE6. Thus, the two paths from PE3 to PE1 are 685 PE3-P1-P4-P7-PE1 and PE3-P2-P9-P8-PE1. 687 PE3 PE4 688 | \ 689 | \ 690 | \ 691 | \ 692 | \ 693 | \ 694 | \ 695 | \ 696 P1 P2 697 |\ / \ 698 | \ / \ 699 | \ / \ 700 | \ / \ 701 P3 P4 X P5 P6 702 / / \ | 703 / / \ | 704 / / \ | 705 / / \ | 706 P7 P8--P9 P10-P11 P12 707 | / \ | 708 | / \ | 709 | / \ | 710 |/ \| 711 PE1 PE2 PE5 PE6 713 Figure 7: A P2MP Unidirectional Service Installed at PE3 715 6.3. P2P Unidirectional Connectivity 717 Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and 718 connected to PE3. This is equivalent to a Segment Routing Traffic 719 Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy] 720 installed at PE1. 722 As in the previous examples, a pair of redundant paths are computed. 724 PE3 PE4 725 |\ 726 | \ 727 | \ 728 | \ 729 | \ 730 | \ 731 | \ 732 | \ 733 P1 P2 734 | | 735 | | 736 | | 737 | | 738 P3 P4 P5 P6 739 / | 740 / | 741 / | 742 / | 743 P7 P8--P9--------P10 P11 P12 744 | / 745 | / 746 | / 747 |/ 748 PE1 PE2 PE5 PE6 750 Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at 751 PE1 753 6.4. P2P Bidirectional Connectivity 755 Figure 9 show a bidirectional P2P service connecting PE1 and PE6. 756 This is equivalent to a Segment Routing Traffic Engineering (SR TE) 757 Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and 758 PE6. 760 PE3 PE4 762 P1 P2 764 P3 P4--------P5 P6 765 / \ 766 / \ 767 / \ 768 / \ 769 P7 P8--P9--------P10-P11 P12 770 | / \ | 771 | / \ | 772 | / \ | 773 |/ \| 774 PE1 PE2 PE5 PE6 776 Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6 778 7. Security Considerations 780 TBD 782 8. Manageability Considerations 784 Per VPN OAM and telemetry will be required in order to monitor and 785 verify the performance of network slices. This is particularly 786 important when the performance of a network slice has been committed 787 to a customer through a Service Level Agreement. 789 As noted in Section 5, ACTN may provide a suitable management model. 790 However, an Enhanced VPN service model may be needed following the 791 concepts described in [RFC8309] and similar in structure to the Layer 792 3 VPN service model defined in [RFC8299]. 794 Local policy may be used to balance load between BGP-LS filters that 795 are matched by the same flow. It MUST be possible for an operator to 796 query those policies and understand how traffic is being matched to 797 filters. An implementation MAY also make those policies configurable 798 by an operator so that the operator can exert control over how load 799 is balanced (for example, by applying weights to various filters. 801 9. IANA Considerations 803 9.1. New BGP Path Attribute 805 IANA maintains a registry of "Border Gateway Protocol (BGP) 806 Parameters" with a subregistry of "BGP Path Attributes". IANA is 807 requested to assign a new Path attribute called "BGP-LS Filter 808 attribute" (TBD1 in this document) with this document as a reference. 810 9.2. New BGP-LS Filter attribute TLVs Type Registry 812 IANA maintains a registry of "Border Gateway Protocol (BGP) 813 Parameters". IANA is request to create a new subregistry called the 814 "BGP-LS Filter attribute TLVs" registry. 816 Valid values are in the range 0 to 255. 818 o Values 0 and 255 are to be marked "Reserved, not to be allocated". 820 o Values 1 through 254 are to be assigned according to the "First 821 Come First Served" policy [RFC8126] 823 This document should be given as a reference for this registry. The 824 new registry should track: 826 o Type 828 o Name 830 o Reference Document or Contact 832 o Registration Date 834 The registry should initially be populated as follows: 836 Type | Name | Reference | Date 837 ------+-------------------------+---------------+--------------- 838 1 | Filter TLV | [This.I-D] | Date-to-be-set 839 2 | DSCP List TLV | [This.I-D] | Date-to-be-set 840 3 | Color List TLV | [This.I-D] | Date-to-be-set 841 4 | Root TLV | [This.I-D] | Date-to-be-set 843 10. Acknowledgements 845 The authors are grateful to all those who contributed to the 846 discussions that led to this work: Ron Bonica, Stewart Bryant, Jie 847 Dong, Keyur Patel, Julian Lucek, and Colby Barth. 849 Stephane Litkowski provided useful review comments. 851 11. Contributors 853 The following people contributed text to this document: 855 Gyan Mishra 856 Email: hayabusagsm@gmail.com 858 12. References 860 12.1. Normative References 862 [I-D.ietf-idr-tunnel-encaps] 863 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 864 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 865 encaps-20 (work in progress), November 2020. 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, 869 DOI 10.17487/RFC2119, March 1997, 870 . 872 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 873 "Definition of the Differentiated Services Field (DS 874 Field) in the IPv4 and IPv6 Headers", RFC 2474, 875 DOI 10.17487/RFC2474, December 1998, 876 . 878 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 879 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 880 DOI 10.17487/RFC4271, January 2006, 881 . 883 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 884 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 885 2006, . 887 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 888 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 889 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 890 2015, . 892 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 893 Patel, "Revised Error Handling for BGP UPDATE Messages", 894 RFC 7606, DOI 10.17487/RFC7606, August 2015, 895 . 897 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 898 S. Ray, "North-Bound Distribution of Link-State and 899 Traffic Engineering (TE) Information Using BGP", RFC 7752, 900 DOI 10.17487/RFC7752, March 2016, 901 . 903 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 904 Writing an IANA Considerations Section in RFCs", BCP 26, 905 RFC 8126, DOI 10.17487/RFC8126, June 2017, 906 . 908 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 909 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 910 May 2017, . 912 12.2. Informative References 914 [I-D.dong-spring-sr-for-enhanced-vpn] 915 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 916 Z., and F. Clad, "Segment Routing based Virtual Transport 917 Network (VTN) for Enhanced VPN", draft-dong-spring-sr-for- 918 enhanced-vpn-12 (work in progress), December 2020. 920 [I-D.ietf-idr-segment-routing-te-policy] 921 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 922 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 923 Routing Policies in BGP", draft-ietf-idr-segment-routing- 924 te-policy-11 (work in progress), November 2020. 926 [I-D.ietf-teas-enhanced-vpn] 927 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 928 Framework for Enhanced Virtual Private Networks (VPN+) 929 Service", draft-ietf-teas-enhanced-vpn-06 (work in 930 progress), July 2020. 932 [I-D.king-teas-applicability-actn-slicing] 933 King, D., Drake, J., and H. Zheng, "Applicability of 934 Abstraction and Control of Traffic Engineered Networks 935 (ACTN) to Network Slicing", draft-king-teas-applicability- 936 actn-slicing-08 (work in progress), October 2020. 938 [I-D.nsdt-teas-ietf-network-slice-definition] 939 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 940 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 941 teas-ietf-network-slice-definition-01 (work in progress), 942 November 2020. 944 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 945 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 946 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 947 . 949 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 950 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 951 February 2006, . 953 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 954 Reflection: An Alternative to Full Mesh Internal BGP 955 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 956 . 958 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 959 R., Patel, K., and J. Guichard, "Constrained Route 960 Distribution for Border Gateway Protocol/MultiProtocol 961 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 962 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 963 November 2006, . 965 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 966 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 967 DOI 10.17487/RFC8299, January 2018, 968 . 970 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 971 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 972 . 974 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 975 Decraene, B., Litkowski, S., and R. Shakir, "Segment 976 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 977 July 2018, . 979 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 980 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 981 DOI 10.17487/RFC8453, August 2018, 982 . 984 [TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP 985 TS23.501", 2016, 986 . 989 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 990 and requirements - 3GPP TS28.530", 2016, 991 . 994 Authors' Addresses 996 John Drake 997 Juniper Networks 999 Email: jdrake@juniper.net 1001 Adrian Farrel 1002 Old Dog Consulting 1004 Email: adrian@olddog.co.uk 1006 Luay Jalil 1007 Verizon 1009 Email: luay.jalil@verizon.com 1011 Avinash Lingala 1012 AT&T 1014 Email: ar977m@att.com