idnits 2.17.1 draft-drake-bess-enhanced-vpn-07.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 (November 15, 2021) is 893 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 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-01 == Outdated reference: A later version (-06) exists of draft-ietf-teas-applicability-actn-slicing-00 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-05 Summary: 1 error (**), 0 flaws (~~), 6 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: May 19, 2022 Old Dog Consulting 6 L. Jalil 7 Verizon 8 A. Lingala 9 AT&T 10 November 15, 2021 12 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs 13 draft-drake-bess-enhanced-vpn-07 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 May 19, 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 13 75 5. Comparison With ACTN . . . . . . . . . . . . . . . . . . . . 13 76 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. MP2MP Connectivity . . . . . . . . . . . . . . . . . . . 15 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 [I-D.ietf-teas-ietf-network-slices], however, in this document we 106 simply use the term "network slice" since we are working entirely 107 within this context. 109 Advanced services drive a need to create virtual networks with 110 enhanced characteristics. The tenant of such a virtual network can 111 require a degree of isolation and performance that previously could 112 only be satisfied by dedicated networks. Additionally, the tenant 113 may ask for some level of control to their virtual networks, e.g., to 114 customize the service forwarding paths in the underlying network. 116 The concept of "IETF network slices" is introduced in 117 [I-D.ietf-teas-ietf-network-slices]. [I-D.ietf-teas-enhanced-vpn] 118 builds on this concept and introduces "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 This document supports the concept of a network slice network model 135 interface that provides the funciton needed by the network slice 136 service model interface defined in 137 [I-D.ietf-teas-ietf-network-slices]. 139 2. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. Overview of Approach 149 The approach described in this document is based on a network 150 controller that uses the {source, destination} traffic matrix and the 151 performance and scaling properties of each network slice, VPN, or set 152 of VPNs in conjunction with the topology of the underlay network to 153 assign each network slice, VPN, or set of VPNs a set of underlay 154 links and nodes that it can use. That is, each network slice, VPN, 155 or set of VPNs gets a subset, either dedicated or shared, of the 156 resources in the underlay network. Note that, in this document, we 157 recognize that scalability of protocol mechanisms to partition 158 network resources is very important; this gives rise to the concept 159 of "a set of VPNs" so that the slice of network resources achieved 160 using the protocol mechanisms defined in this document can be shared 161 by a well-defined set of VPNs as configured by the network operator. 163 It should be noted that resources can be assigned at any of the 164 following granularities: 166 o All provider edge (PE) routers in a given VPN. 168 o A set of PEs in a given VPN. 170 o An individual PE in a given VPN. 172 There are two phases to this approach: 174 Step-1: Discovery and data gathering. Information is gathered 175 from the underlay network about the links, nodes, and network 176 resources available for use by the VPN or network slice. 178 Step-2: Configuration and provisioning. The underlay resources 179 are configured for use for the VPN or network slice. 181 Once the network controller has determined the resource assignments, 182 it distributes this information to the PEs that participate in each 183 VPN using the usual VPN information dissemination tools, e.g., route 184 targets (RT) [RFC4360], route reflectors (RR) [RFC4456], and RT 185 constraints [RFC4684]. 187 This information is distributed to the PEs by giving them a 188 customized and limited view of the underlay network on the basis of a 189 network slice, a VPN, or a set of VPNs. Each PE will have a complete 190 view of the underlay network and this customized and limited view 191 acts as filter on the underlay network telling the PE which underlay 192 network resources it can use to direct the traffic of a given network 193 slice, VPN, or set of VPNs to best deliver end-to-end services. 195 The resource allocation information is encoded using BGP-LS. This 196 approach is chosen for the following reasons: 198 o It is BGP-based so it integrates easily with the existing BGP- 199 based VPN infrastructure ([RFC4364], [RFC4684]). 201 o It supports Segment Routing which is necessary to enforce the PEs' 202 usage of the resources allocated to the VPN or set of VPNs. 204 o It supports Segment Routing which is necessary to enforce the PEs' 205 usage of the resources allocated to the network slice, VPN, or set 206 of VPNs. The use of RSVP-TE ([RFC3209]) rather than Segment 207 Routing is at the discretion of the network operator as BGP-LS 208 supports both and either confines a packet flow to a specific 209 path. 211 o It supports inter-AS connectivity which is a perquisite for 212 supporting the existing BGP-based VPN infrastructure. 214 o It is canonical, in that it can be used to advertise the resources 215 of underlay networks that use either IS-IS or OSPF. 217 It should be noted that this mechanism also follows the scalability 218 model of the existing BGP-based VPN infrastructure, which is that the 219 per-VPN information is restricted to only those PE routers that are 220 supporting that VPN and that the provider (P) routers have no per-VPN 221 state. 223 The PEs in non-enhanced VPNs do not receive this resource allocation 224 information and would not confine their usage of the underlay network 225 resources. In order to ensure that the underlay network resources 226 allocated to enhanced VPNs are not inadvertently used by the PEs in 227 non-enhanced VPNs, the network controller SHOULD ensure that the IGP 228 and traffic engineering (TE) metrics for these resources is higher 229 than the metrics for the underlay network resources allocated to non- 230 enhanced VPNs. In certain situations, detailed in Section 4, PEs in 231 enhanced VPNs will use the underlay networks resources allocated to 232 non-enhanced VPNs. 234 Additional to the programming of the PEs and its computation and 235 assignment of resources for use by network slices, VPNs, or sets of 236 VPNs, the network controller also instructs the P routers to make the 237 actual allocation of these resources by assigning link bandwidth to a 238 specific DSCP or adjacency segment identifier (SID) 239 [I-D.ietf-spring-sr-for-enhanced-vpn]. 241 4. Detailed Protocol Operation 243 We define a BGP-LS Filter to be a BGP-LS encoded description of a 244 subset of the links and nodes in the underlay network. A BGP-LS 245 Filter defines all or part of the topology for a network slice or a 246 set of one or more VPNs. The topology defined by a BGP-LS Filter 247 needs to provide connectivity between the PEs in a given network 248 slice, VPN or set of VPNs. I.e., it connects the PEs in these VPNs 249 and is used by them to send packets to each other. A given filter is 250 tagged with the route targets of the VPNs whose PEs are to import the 251 filter. A BGP-LS Filter is pushed southbound to those PEs by the 252 network controller and SHOULD provide multiple paths between a given 253 ingress/egress PE pair. 255 Note that there will be multiple BGP-LS Filters in a given network 256 deployment and that a given underlay network link or node may appear 257 in more than one of them. In order to provide disambiguation, the 258 address family indicator (AFI) 16388 (BGP-LS) and the subsequent 259 address family identifier (SAFI) 72 (BGP-LS-VPN) are used in BGP-LS 260 UPDATE messages and the network controller SHOULD allocate a 261 different route distinguisher (RD) to each BGP-LS Filter. As for 262 standard VPNs, an implementation option ("RD Auto") may be offered to 263 assist in configuring unique RDs. 265 Within a given VPN, when an ingress PE needs to send a packet to an 266 egress PE it selects a path to that egress PE from the topology 267 defined by the BGP-LS Filters it has imported for that VPN. It then 268 either adds a segment routing label stack specifying that path to the 269 packet or places the packet in an RSVP-TE LSP which uses that path. 270 The ingress PE may use any path computation it wishes if that path 271 computation confines the path to the topology defined by the relevant 272 set of BGP-LS Filters. 274 If Segment Routing is used and a node SID or a prefix SID is placed 275 in the segment routing label stack, then when that segment is active 276 the P routers will forward the packet using the underlay network 277 resources allocated to non-enhanced VPNs. Similarly, if the RSVP-TE 278 label switched path (LSP) was established using a loose source route 279 to the subject node, the path to that node was selected using the 280 underlay network resources allocated to non-enhanced VPNs. 282 Because the BGP-LS UPDATE messages specifying a BGP-LS Filter may 283 arrive in any order and the BGP-LS UPDATE messages of multiple BGP-LS 284 Filters may be interleaved, there is a need for a new attribute that 285 is attached to a BGP-LS UPDATE. This attribute contains a Filter ID, 286 a Filter version number, a Filter type (MP2MP, P2MP, or P2P), the 287 total number of fragments in the filter, and the specific fragment 288 number of the piece in hand. I.e., it is assumed that a PE may 289 import more than one BGP-LS Filter, that a given BGP-LS Filter may 290 change over time, and that a given BGP-LS Filter may span multiple 291 BGP-LS UPDATE messages. The Filter ID needs to be unique across the 292 set of VPNs into which the BGP-LS Filter is to be imported. 294 A BGP-LS Filter that is created for a set of VPNs will contain a set 295 of network resources sufficient to connect between the PEs in each 296 discrete VPN in the set, and each of the BGP-LS UPDATE messages for 297 the filter MUST be tagged with the RT for each VPN in the set. 299 If a PE imports more than one BGP-LS Filter it MAY use the union of 300 the links and nodes specified in each filter when selecting a path. 302 A given BGP-LS Filter may change in response to updates to the PE 303 membership in a VPN to which the BGP-LS Filter applies or to updates 304 to the underlay network. This implies that the network controller 305 needs to be connected to the route reflectors associated with the 306 VPNs for which it is providing BGP-LS maps. When this occurs, the 307 network controller SHOULD push a new version of the affected BGP-LS 308 Filters. That is, it increments the version number of each BGP-LS 309 Filter. Note that a network controller does not need to compute new 310 BGP-LS Filters in response to an individual link or node failure in 311 the underlay network if connectivity still exists among the PEs in 312 the network slice, VPN or set or VPNs with the existing BGP-LS 313 Filters. 315 A BGP-LS Filter cannot be used by a PE until it is completely 316 assembled. If the BGP-LS Filter that is being assembled is a newer 317 version of a BGP-LS Filter that the PE is currently using, the PE 318 SHOULD continue to use its current version of the BGP-LS Filter until 319 the newer version is completely assembled. 321 When selecting a path using one or more BGP-LS Filters, an ingress PE 322 can use a link or node only if it is active in the underlay network. 323 If this precludes connectivity to the egress PE it may use the 324 underlay network resources not allocated to enhanced VPNs to reach 325 the egress PE. 327 Additionally, when there is a newly activated PE it will not be 328 present in any of the BGP-LS Filters used by the other PEs. Until a 329 new BGP-LS Filter that contains that PE has been distributed, other 330 PEs will use the underlay network resources not allocated to enhanced 331 VPNs to reach the newly activated PE, and the newly activate PE will 332 use these resources to reach other PEs. 334 4.1. The BGP-LS Filter Attribute 336 [RFC4271] defines the BGP Path attribute. This document introduces a 337 new Optional Transitive Path attribute called the BGP-LS Filter 338 attribute with value TBD1 to be assigned by IANA. 340 The first BGP-LS Filter attribute MUST be processed and subsequent 341 instances MUST be ignored. 343 The common fields of the BGP-LS Filter attribute are set as follows: 345 o Optional bit is set to 1 to indicate that this is an optional 346 attribute. 348 o The Transitive bit is set to 1 to indicate that this is a 349 transitive attribute. 351 o The Extended Length bit is set according to the length of the BGP- 352 LS Filter attribute as defined in [RFC4271]. 354 o The Attribute Type Code is set to TBD1. 356 The content of the BGP-LS Filter attribute is a series of Type- 357 Length-Value (TLV) constructs. Each TLV may include sub-TLVs. All 358 TLVs and sub-TLVs have a common format that is: 360 o Type: A single octet indicating the type of the BGP-LS Filter 361 attribute TLV. Values are taken from the registry described in 362 Section 9.2. 364 o Length: A two octet field indicating the length of the data 365 following the Length field counted in octets. 367 o Value: The contents of the TLV. 369 The formats of the TLVs defined in this document are shown in the 370 following sections. The presence rules and meanings are as follows. 372 o The BGP-LS Filter attribute MUST contain a Filter TLV. 374 o The BGP-LS Filter attribute MAY contain a DSCP List TLV. 376 o The BGP-LS Filter attribute MAY contain a Color List TLV. 378 o The BGP-LS Filter attribute MAY contain a Root TLV. 380 4.1.1. The Filter TLV 382 The BGP-LS Filter attribute MUST contain exactly one Filter TLV. Its 383 format is shown in Figure 1. Note that a given BGP-LS Filter may 384 span multiple UPDATE messages and the Topology, Version Number, and 385 the Number of Fragments fields in the BGP-LS Filter attribute 386 contained in each UPDATE message MUST be set to the same value or the 387 BGP-LS Filter is unusable. 389 +--------------------------------------------+ 390 | Type = 1 (1 octet) | 391 +--------------------------------------------+ 392 | Length (2 octets) | 393 +--------------------------------------------+ 394 | Topology (1 Octet) | 395 +--------------------------------------------+ 396 | ID (4 Octets) | 397 +--------------------------------------------+ 398 | Version Number (4 Octets) | 399 +--------------------------------------------+ 400 | Number of Fragments (4 Octets) | 401 +--------------------------------------------+ 402 | Fragment Number (4 Octets) | 403 +--------------------------------------------+ 405 Figure 1: The Filter TLV Format 407 The fields are as follows: 409 o Type is set to 1 to indicate a Filter TLV. 411 o Length is set to 17 octets. 413 o Topology indicates the topology defined by this BGP-LS Filter. 415 1. P2P unidirectional 417 2. P2P bidirectional 419 3. P2MP 421 4. MP2MP 423 o The ID of this BGP-LS Filter. This ID needs to be unique within 424 the set of VPNs into which the BGP-LS Filter is to be imported. 426 o The Version Number of this BGP-LS Filter. The contents of a BGP- 427 LS Filter with a given ID may change over time. This field 428 indicates the version of the BGP-LS Filter being advertized in 429 this UPDATE message. 431 o Number of Fragments indicates the number of BGP UPDATE messages 432 defining this BGP-LS Filter. 434 o Fragment Number indicates ordinal position of this UPDATE message 435 within the set of UPDATE messages defining this BGP-LS Filter. A 436 BGP-LS Filter is not complete, i.e., usable, until all UPDATE 437 messages have been received with Fragment Numbers in the range 1 438 <= Fragment Number <= Number of Fragments. An UPDATE message with 439 a Fragment Number outside this range is to be ignored. 441 4.1.2. The DSCP List TLV 443 The DSCP List TLV MAY be included in the BGP-LS Filter attribute. If 444 included, a packet whose DSCP matches a DSCP in the DSCP list is to 445 be forwarded using the BGP-LS Filter defined by the BGP-LS Filter 446 attribute that contains the DSCP list. The first DSCP List TLV MUST 447 be processed and subsequent instances MUST be ignored. The format of 448 the DSCP List TLV is shown in Figure 2. 450 If a DSCP List TLV is included in a BGP-LS Filter attribute, then a 451 packet that matches an entry in the list MAY be forwarded using the 452 BGP-LS Filter defined by the BGP-LS Filter attribute, but a packet 453 which doesn't match an entry in this list MUST NOT use the filter. 454 If both a DSCP List TLV and a Color List TLV (see Section 4.1.3) are 455 both included in a BGP-LS Filter attribute, packets matching an entry 456 in either list MAY be forwarded using the BGP-LS Filter defined by 457 the BGP-LS Filter attribute. If neither list is included in a BGP-LS 458 Filter attribute, then all packets for that network slice, VPN, or 459 set of VPNs can be forwarded using the BGP-LS Filter defined by the 460 containing BGP-LS Filter attribute. 462 +--------------------------------------------+ 463 | Type = 2 (1 octet) | 464 +--------------------------------------------+ 465 | Length (2 octets) | 466 +--------------------------------------------+ 467 | DSCP List (variable) | 468 +--------------------------------------------+ 470 Figure 2: The DSCP List TLV Format 472 The fields are as follows: 474 o Type is set to 2 to indicate a DSCP List TLV. 476 o Length indicates the length in octets of the DSCP List. 478 o DSCP List contains a list of DSCPs, each one octet in length and 479 encodes the DSCP per [RFC2474] as the most significant six bits of 480 the octet. 482 4.1.3. The Color List TLV 484 The Color List TLV MAY be included in the BGP-LS Filter attribute. 485 If a BGP UPDATE contains a Color extended community with a color (as 486 defined by [RFC9012]) that matches an entry in the Color List, then a 487 packet whose destination is covered by one of the routes in that 488 UPDATE is to be forwarded using the BGP-LS Filter defined by the BGP- 489 LS Filter attribute that contains the Color List TLV. The first 490 Color List TLV MUST be processed and subsequent instances MUST be 491 ignored. The format of the Color List TLV is shown in Figure 3. 493 If Color List TLV is included in a BGP-LS Filter attribute, then a 494 packet that matches an entry in the list MAY be forwarded using the 495 BGP-LS Filter defined by the BGP-LS Filter attribute, but a packet 496 which doesn't match an entry in this list MUST NOT use the filter. 497 If both a DSCP List TLV (see Section 4.1.2 and a Color List TLV are 498 both included in a BGP-LS Filter attribute, packets matching an entry 499 in either list MAY be forwarded using the BGP-LS Filter defined by 500 the BGP-LS Filter attribute. If neither list is included in a BGP-LS 501 Filter attribute, then all packets for that network slice, VPN, or 502 set of VPNs can be forwarded using the BGP-LS Filter defined by the 503 containing BGP-LS Filter attribute. 505 +--------------------------------------------+ 506 | Type = 3 (1 octet) | 507 +--------------------------------------------+ 508 | Length (2 octets) | 509 +--------------------------------------------+ 510 | Color List (variable) | 511 +--------------------------------------------+ 513 Figure 3: The Color List TLV Format 515 The fields are as follows: 517 o Type is set to 3 to indicate a Color List TLV. 519 o Length indicates the length in octets of the Color List. 521 o Color List contains a list of Colors, each four octets in length 522 and as defined in [RFC9012]. 524 4.1.4. The Root TLV 526 The Root TLV MUST be included in the BGP-LS Filter attribute if its 527 topology is of type P2MP or P2P unidirectional. It defines the root 528 node for that topology and if it is not present the BGP-LS Filter is 529 unusable. The TLV, if present, MUST be ignored if the topology is of 530 type MP2MP or P2P bidirectional. 532 The Root TLV is structured as shown in Figure 4 and MAY contain any 533 of the sub-TLVs defined in section 3.2.1.4 of [RFC7752]. 535 +--------------------------------------------+ 536 | Type = 3 (1 octet) | 537 +--------------------------------------------+ 538 | Length (2 octets) | 539 +--------------------------------------------+ 540 | Sub-TLVs (variable) | 541 +--------------------------------------------+ 543 Figure 4: The Root TLV Format 545 The fields are as follows: 547 o Type is set to 3 to indicate a Color List TLV. 549 o Length indicates the length in octets of the Color List. 551 o There follows a sequence of zero or more sub-TLVs as defined in 552 section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be 553 deduced from the Length field of the Root TLV. 555 4.2. Error Handling 557 Section 6 of [RFC4271] describes the handling of malformed BGP 558 attributes, or those that are in error in some way. [RFC7606] 559 revises BGP error handling specifically for the for UPDATE message, 560 provides guidelines for the authors of documents defining new 561 attributes, and revises the error handling procedures for a number of 562 existing attributes. This document introduces the BGP-LS Filter 563 attribute and so defines error handling as follows: 565 o When parsing a message, an unknown Attribute Type code or a length 566 that suggests that the attribute is longer than the remaining 567 message is treated as a malformed message and the "treat-as- 568 withdraw" approach is used as per [RFC7606]. 570 o When parsing a message that contains an BGP-LS Filter attribute, 571 the following cases constitute errors: 573 1. Optional bit is set to 0 in BGP-LS Filter attribute. 575 2. Transitive bit is set to 0 in BGP-LS Filter attribute. 577 3. The attribute does not contain a Filter TLV or contains more 578 than one Filter TLV. 580 4. The TLV length indicates that the TLV extends beyond the end 581 of the BGP-LS Filter attribute. 583 5. There is an unknown TLV type field found in BGP-LS Filter 584 attribute. 586 The errors listed above are treated as follows: 588 1., 2., 3., 4.: The attribute MUST be treated as malformed and 589 the "treat-as-withdraw" approach used as per [RFC7606]. 591 5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 592 continue. 594 5. Comparison With ACTN 596 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 597 framework that facilitates the abstraction of underlying network 598 resources to higher-layer applications and that allows nework 599 operators to create virtual networks through the abstraction of the 600 operators' network resources. The applicability of ACTN to network 601 slicing is discussed further in 602 [I-D.ietf-teas-applicability-actn-slicing]. 604 Essentially the ACTN framework describes how to request and provision 605 a network slice, but does not define how the network is operated to 606 deliver that slice. Therefore, a direct comparison between this work 607 and ACTN is not appropriate. ACTN could be used as a management 608 framework to operate a slicing system built using the protocol 609 extensions defined in this document. 611 6. Examples 613 Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6) 614 are connected across a network of twelve P nodes (P1 through P12). 615 Each PE is dual-homed, and the P nodes are variously connected so 616 that there are multiple routes between PEs. 618 PE3 PE4 619 |\ /| 620 | \ / | 621 | \ / | 622 | \/ | 623 | /\ | 624 | / \ | 625 | / \ | 626 |/ \| 627 P1--------P2 628 / |\ /| \ 629 / | \ / | \ 630 / | \ / | \ 631 / | \/ | \ 632 P3-------P4--------P5-------P6 633 | / | /\ | \ | 634 | / | / \ | \ | 635 | / | / \ | \ | 636 |/ |/ \| \| 637 P7---P8--P9--------P10-P11-P12 638 |\ /| |\ /| 639 | \/ | | \/ | 640 | /\ | | /\ | 641 |/ \| |/ \| 642 PE1 PE2 PE5 PE6 644 Figure 5: Underlay Network Topology 646 6.1. MP2MP Connectivity 648 Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that 649 connects PE1, PE3, and PE6 can be installed over the underlay 650 network. Paths have been computed so that, for example, PE1 is 651 connected to both PE3 and PE6 via pairs of redundant paths. 652 Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to 653 PE1 and PE3. 655 PE3 PE4 656 | \ 657 | \ 658 | \ 659 | \ 660 | \ 661 | \ 662 | \ 663 | \ 664 P1 P2 665 / \ /| 666 / \ / | 667 / \ / | 668 / \ / | 669 P3 P4 X P5 P6 670 | / \ \ 671 | / \ \ 672 | / \ \ 673 | / \ \ 674 P7 P8--P9---------P10-P11 P12 675 | / \ | 676 | / \ | 677 | / \ | 678 |/ \| 679 PE1 PE2 PE5 PE6 681 Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6 683 6.2. P2MP Unidirectional Connectivity 685 Figure 7 shows the provision of a Point-to-Multipoint (P2MP) service 686 rooted at PE3 and connected to PE1 and PE6. As in the previous 687 example, a pair of redundant paths is established between PE3 and 688 each of PE1 and PE6. Thus, the two paths from PE3 to PE1 are 689 PE3-P1-P4-P7-PE1 and PE3-P2-P9-P8-PE1. 691 PE3 PE4 692 | \ 693 | \ 694 | \ 695 | \ 696 | \ 697 | \ 698 | \ 699 | \ 700 P1 P2 701 |\ / \ 702 | \ / \ 703 | \ / \ 704 | \ / \ 705 P3 P4 X P5 P6 706 / / \ | 707 / / \ | 708 / / \ | 709 / / \ | 710 P7 P8--P9 P10-P11 P12 711 | / \ | 712 | / \ | 713 | / \ | 714 |/ \| 715 PE1 PE2 PE5 PE6 717 Figure 7: A P2MP Unidirectional Service Installed at PE3 719 6.3. P2P Unidirectional Connectivity 721 Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and 722 connected to PE3. This is equivalent to a Segment Routing Traffic 723 Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy] 724 installed at PE1. 726 As in the previous examples, a pair of redundant paths are computed. 728 PE3 PE4 729 |\ 730 | \ 731 | \ 732 | \ 733 | \ 734 | \ 735 | \ 736 | \ 737 P1 P2 738 | | 739 | | 740 | | 741 | | 742 P3 P4 P5 P6 743 / | 744 / | 745 / | 746 / | 747 P7 P8--P9--------P10 P11 P12 748 | / 749 | / 750 | / 751 |/ 752 PE1 PE2 PE5 PE6 754 Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at 755 PE1 757 6.4. P2P Bidirectional Connectivity 759 Figure 9 show a bidirectional P2P service connecting PE1 and PE6. 760 This is equivalent to a Segment Routing Traffic Engineering (SR TE) 761 Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and 762 PE6. 764 PE3 PE4 766 P1 P2 768 P3 P4--------P5 P6 769 / \ 770 / \ 771 / \ 772 / \ 773 P7 P8--P9--------P10-P11 P12 774 | / \ | 775 | / \ | 776 | / \ | 777 |/ \| 778 PE1 PE2 PE5 PE6 780 Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6 782 7. Security Considerations 784 TBD 786 8. Manageability Considerations 788 Per VPN OAM and telemetry will be required in order to monitor and 789 verify the performance of network slices. This is particularly 790 important when the performance of a network slice has been committed 791 to a customer through a Service Level Agreement. 793 As noted in Section 5, ACTN may provide a suitable management model. 794 However, an Enhanced VPN service model may be needed following the 795 concepts described in [RFC8309] and similar in structure to the Layer 796 3 VPN service model defined in [RFC8299]. 798 Local policy may be used to balance load between BGP-LS filters that 799 are matched by the same flow. It MUST be possible for an operator to 800 query those policies and understand how traffic is being matched to 801 filters. An implementation MAY also make those policies configurable 802 by an operator so that the operator can exert control over how load 803 is balanced (for example, by applying weights to various filters. 805 9. IANA Considerations 807 9.1. New BGP Path Attribute 809 IANA maintains a registry of "Border Gateway Protocol (BGP) 810 Parameters" with a subregistry of "BGP Path Attributes". IANA is 811 requested to assign a new Path attribute called "BGP-LS Filter 812 attribute" (TBD1 in this document) with this document as a reference. 814 9.2. New BGP-LS Filter attribute TLVs Type Registry 816 IANA maintains a registry of "Border Gateway Protocol (BGP) 817 Parameters". IANA is request to create a new subregistry called the 818 "BGP-LS Filter attribute TLVs" registry. 820 Valid values are in the range 0 to 255. 822 o Values 0 and 255 are to be marked "Reserved, not to be allocated". 824 o Values 1 through 254 are to be assigned according to the "First 825 Come First Served" policy [RFC8126] 827 This document should be given as a reference for this registry. The 828 new registry should track: 830 o Type 832 o Name 834 o Reference Document or Contact 836 o Registration Date 838 The registry should initially be populated as follows: 840 Type | Name | Reference | Date 841 ------+-------------------------+---------------+--------------- 842 1 | Filter TLV | [This.I-D] | Date-to-be-set 843 2 | DSCP List TLV | [This.I-D] | Date-to-be-set 844 3 | Color List TLV | [This.I-D] | Date-to-be-set 845 4 | Root TLV | [This.I-D] | Date-to-be-set 847 10. Acknowledgements 849 The authors are grateful to all those who contributed to the 850 discussions that led to this work: Ron Bonica, Stewart Bryant, Jie 851 Dong, Keyur Patel, Julian Lucek, and Colby Barth. 853 Stephane Litkowski provided useful review comments. 855 11. Contributors 857 The following people contributed text to this document: 859 Gyan Mishra 860 Email: hayabusagsm@gmail.com 862 12. References 864 12.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 872 "Definition of the Differentiated Services Field (DS 873 Field) in the IPv4 and IPv6 Headers", RFC 2474, 874 DOI 10.17487/RFC2474, December 1998, 875 . 877 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 878 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 879 DOI 10.17487/RFC4271, January 2006, 880 . 882 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 883 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 884 2006, . 886 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 887 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 888 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 889 2015, . 891 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 892 Patel, "Revised Error Handling for BGP UPDATE Messages", 893 RFC 7606, DOI 10.17487/RFC7606, August 2015, 894 . 896 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 897 S. Ray, "North-Bound Distribution of Link-State and 898 Traffic Engineering (TE) Information Using BGP", RFC 7752, 899 DOI 10.17487/RFC7752, March 2016, 900 . 902 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 903 Writing an IANA Considerations Section in RFCs", BCP 26, 904 RFC 8126, DOI 10.17487/RFC8126, June 2017, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 912 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 913 DOI 10.17487/RFC9012, April 2021, 914 . 916 12.2. Informative References 918 [I-D.ietf-idr-segment-routing-te-policy] 919 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 920 Jain, D., and S. Lin, "Advertising Segment Routing 921 Policies in BGP", draft-ietf-idr-segment-routing-te- 922 policy-14 (work in progress), November 2021. 924 [I-D.ietf-spring-sr-for-enhanced-vpn] 925 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 926 Z., and F. Clad, "Segment Routing based Virtual Transport 927 Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- 928 enhanced-vpn-01 (work in progress), July 2021. 930 [I-D.ietf-teas-applicability-actn-slicing] 931 King, D., Drake, J., Zheng, H., and A. Farrel, 932 "Applicability of Abstraction and Control of Traffic 933 Engineered Networks (ACTN) to Network Slicing", draft- 934 ietf-teas-applicability-actn-slicing-00 (work in 935 progress), September 2021. 937 [I-D.ietf-teas-enhanced-vpn] 938 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 939 Framework for Enhanced Virtual Private Network (VPN+) 940 Services", draft-ietf-teas-enhanced-vpn-09 (work in 941 progress), October 2021. 943 [I-D.ietf-teas-ietf-network-slices] 944 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 945 Makhijani, K., Contreras, L. M., and J. Tantsura, 946 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 947 network-slices-05 (work in progress), October 2021. 949 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 950 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 951 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 952 . 954 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 955 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 956 February 2006, . 958 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 959 Reflection: An Alternative to Full Mesh Internal BGP 960 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 961 . 963 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 964 R., Patel, K., and J. Guichard, "Constrained Route 965 Distribution for Border Gateway Protocol/MultiProtocol 966 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 967 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 968 November 2006, . 970 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 971 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 972 DOI 10.17487/RFC8299, January 2018, 973 . 975 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 976 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 977 . 979 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 980 Decraene, B., Litkowski, S., and R. Shakir, "Segment 981 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 982 July 2018, . 984 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 985 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 986 DOI 10.17487/RFC8453, August 2018, 987 . 989 [TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP 990 TS23.501", 2016, 991 . 994 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 995 and requirements - 3GPP TS28.530", 2016, 996 . 999 Authors' Addresses 1001 John Drake 1002 Juniper Networks 1004 Email: jdrake@juniper.net 1006 Adrian Farrel 1007 Old Dog Consulting 1009 Email: adrian@olddog.co.uk 1011 Luay Jalil 1012 Verizon 1014 Email: luay.jalil@verizon.com 1016 Avinash Lingala 1017 AT&T 1019 Email: ar977m@att.com