idnits 2.17.1 draft-drake-bess-enhanced-vpn-06.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 (February 4, 2021) is 1177 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-21 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == 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 (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-08 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 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: August 8, 2021 Old Dog Consulting 6 L. Jalil 7 Verizon 8 A. Lingala 9 AT&T 10 February 4, 2021 12 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs 13 draft-drake-bess-enhanced-vpn-06 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 August 8, 2021. 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-slice-definition], however, in this 106 document we simply use the term "network slice" since we are working 107 entirely 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-slice-definition] and 118 [I-D.nsdt-teas-ns-framework]. [I-D.ietf-teas-enhanced-vpn] builds on 119 this concept and introduces "enhanced VPNs". 121 In order to support network slicing, as well as to offer enhanced VPN 122 services in general, it is necessary to define a mechanism by which 123 specific resources (links and/or nodes) of an underlay network can be 124 used by a specific network slice, a single VPN, or a well-defined set 125 of VPNs. This document sets out such a mechanism for use in Segment 126 Routing networks [RFC8402] and builds on the ideas introduced in 127 [I-D.ietf-idr-segment-routing-te-policy]. I.e., it generalizes that 128 work to support multipoint-to-multipoint (MP2MP), point-to-multipoint 129 (P2MP), and bidirectional point-to-point (P2P) topologies; it 130 integrates BGP-based VPN support ([RFC4364], [RFC7432]); it supports 131 Differentiated Services Code Points (DSCP) as well a Color-based 132 forwarding, and it uses BGP Link-State (BGP-LS) [RFC7752] to 133 distribute topology information. 135 This document supports the concept of a network slice network model 136 interface that provides the funciton needed by the network slice 137 service model interface defined in [I-D.nsdt-teas-ns-framework]. 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.dong-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 [I-D.ietf-idr-tunnel-encaps]) that matches an entry in the 487 Color List, then a packet whose destination is covered by one of the 488 routes in that UPDATE is to be forwarded using the BGP-LS Filter 489 defined by the BGP-LS Filter attribute that contains the Color List 490 TLV. The first Color List TLV MUST be processed and subsequent 491 instances MUST be ignored. The format of the Color List TLV is shown 492 in Figure 3. 494 If Color List TLV is included in a BGP-LS Filter attribute, then a 495 packet that matches an entry in the list MAY be forwarded using the 496 BGP-LS Filter defined by the BGP-LS Filter attribute, but a packet 497 which doesn't match an entry in this list MUST NOT use the filter. 498 If both a DSCP List TLV (see Section 4.1.2 and a Color List TLV are 499 both included in a BGP-LS Filter attribute, packets matching an entry 500 in either list MAY be forwarded using the BGP-LS Filter defined by 501 the BGP-LS Filter attribute. If neither list is included in a BGP-LS 502 Filter attribute, then all packets for that network slice, VPN, or 503 set of VPNs can be forwarded using the BGP-LS Filter defined by the 504 containing BGP-LS Filter attribute. 506 +--------------------------------------------+ 507 | Type = 3 (1 octet) | 508 +--------------------------------------------+ 509 | Length (2 octets) | 510 +--------------------------------------------+ 511 | Color List (variable) | 512 +--------------------------------------------+ 514 Figure 3: The Color List TLV Format 516 The fields are as follows: 518 o Type is set to 3 to indicate a Color List TLV. 520 o Length indicates the length in octets of the Color List. 522 o Color List contains a list of Colors, each four octets in length 523 and as defined in [I-D.ietf-idr-tunnel-encaps]. 525 4.1.4. The Root TLV 527 The Root TLV MUST be included in the BGP-LS Filter attribute if its 528 topology is of type P2MP or P2P unidirectional. It defines the root 529 node for that topology and if it is not present the BGP-LS Filter is 530 unusable. The TLV, if present, MUST be ignored if the topology is of 531 type MP2MP or P2P bidirectional. 533 The Root TLV is structured as shown in Figure 4 and MAY contain any 534 of the sub-TLVs defined in section 3.2.1.4 of [RFC7752]. 536 +--------------------------------------------+ 537 | Type = 3 (1 octet) | 538 +--------------------------------------------+ 539 | Length (2 octets) | 540 +--------------------------------------------+ 541 | Sub-TLVs (variable) | 542 +--------------------------------------------+ 544 Figure 4: The Root TLV Format 546 The fields are as follows: 548 o Type is set to 3 to indicate a Color List TLV. 550 o Length indicates the length in octets of the Color List. 552 o There follows a sequence of zero or more sub-TLVs as defined in 553 section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be 554 deduced from the Length field of the Root TLV. 556 4.2. Error Handling 558 Section 6 of [RFC4271] describes the handling of malformed BGP 559 attributes, or those that are in error in some way. [RFC7606] 560 revises BGP error handling specifically for the for UPDATE message, 561 provides guidelines for the authors of documents defining new 562 attributes, and revises the error handling procedures for a number of 563 existing attributes. This document introduces the BGP-LS Filter 564 attribute and so defines error handling as follows: 566 o When parsing a message, an unknown Attribute Type code or a length 567 that suggests that the attribute is longer than the remaining 568 message is treated as a malformed message and the "treat-as- 569 withdraw" approach is used as per [RFC7606]. 571 o When parsing a message that contains an BGP-LS Filter attribute, 572 the following cases constitute errors: 574 1. Optional bit is set to 0 in BGP-LS Filter attribute. 576 2. Transitive bit is set to 0 in BGP-LS Filter attribute. 578 3. The attribute does not contain a Filter TLV or contains more 579 than one Filter TLV. 581 4. The TLV length indicates that the TLV extends beyond the end 582 of the BGP-LS Filter attribute. 584 5. There is an unknown TLV type field found in BGP-LS Filter 585 attribute. 587 The errors listed above are treated as follows: 589 1., 2., 3., 4.: The attribute MUST be treated as malformed and 590 the "treat-as-withdraw" approach used as per [RFC7606]. 592 5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 593 continue. 595 5. Comparison With ACTN 597 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 598 framework that facilitates the abstraction of underlying network 599 resources to higher-layer applications and that allows nework 600 operators to create virtual networks through the abstraction of the 601 operators' network resources. The applicability of ACTN to network 602 slicing is discussed further in 603 [I-D.king-teas-applicability-actn-slicing]. 605 Essentially the ACTN framework describes how to request and provision 606 a network slice, but does not define how the network is operated to 607 deliver that slice. Therefore, a direct comparison between this work 608 and ACTN is not appropriate. ACTN could be used as a management 609 framework to operate a slicing system built using the protocol 610 extensions defined in this document. 612 6. Examples 614 Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6) 615 are connected across a network of twelve P nodes (P1 through P12). 616 Each PE is dual-homed, and the P nodes are variously connected so 617 that there are multiple routes between PEs. 619 PE3 PE4 620 |\ /| 621 | \ / | 622 | \ / | 623 | \/ | 624 | /\ | 625 | / \ | 626 | / \ | 627 |/ \| 628 P1--------P2 629 / |\ /| \ 630 / | \ / | \ 631 / | \ / | \ 632 / | \/ | \ 633 P3-------P4--------P5-------P6 634 | / | /\ | \ | 635 | / | / \ | \ | 636 | / | / \ | \ | 637 |/ |/ \| \| 638 P7---P8--P9--------P10-P11-P12 639 |\ /| |\ /| 640 | \/ | | \/ | 641 | /\ | | /\ | 642 |/ \| |/ \| 643 PE1 PE2 PE5 PE6 645 Figure 5: Underlay Network Topology 647 6.1. MP2MP Connectivity 649 Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that 650 connects PE1, PE3, and PE6 can be installed over the underlay 651 network. Paths have been computed so that, for example, PE1 is 652 connected to both PE3 and PE6 via pairs of redundant paths. 653 Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to 654 PE1 and PE3. 656 PE3 PE4 657 | \ 658 | \ 659 | \ 660 | \ 661 | \ 662 | \ 663 | \ 664 | \ 665 P1 P2 666 / \ /| 667 / \ / | 668 / \ / | 669 / \ / | 670 P3 P4 X P5 P6 671 | / \ \ 672 | / \ \ 673 | / \ \ 674 | / \ \ 675 P7 P8--P9---------P10-P11 P12 676 | / \ | 677 | / \ | 678 | / \ | 679 |/ \| 680 PE1 PE2 PE5 PE6 682 Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6 684 6.2. P2MP Unidirectional Connectivity 686 Figure 7 shows the provision of a Point-to-Multipoint (P2MP) service 687 rooted at PE3 and connected to PE1 and PE6. As in the previous 688 example, a pair of redundant paths is established between PE3 and 689 each of PE1 and PE6. Thus, the two paths from PE3 to PE1 are 690 PE3-P1-P4-P7-PE1 and PE3-P2-P9-P8-PE1. 692 PE3 PE4 693 | \ 694 | \ 695 | \ 696 | \ 697 | \ 698 | \ 699 | \ 700 | \ 701 P1 P2 702 |\ / \ 703 | \ / \ 704 | \ / \ 705 | \ / \ 706 P3 P4 X P5 P6 707 / / \ | 708 / / \ | 709 / / \ | 710 / / \ | 711 P7 P8--P9 P10-P11 P12 712 | / \ | 713 | / \ | 714 | / \ | 715 |/ \| 716 PE1 PE2 PE5 PE6 718 Figure 7: A P2MP Unidirectional Service Installed at PE3 720 6.3. P2P Unidirectional Connectivity 722 Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and 723 connected to PE3. This is equivalent to a Segment Routing Traffic 724 Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy] 725 installed at PE1. 727 As in the previous examples, a pair of redundant paths are computed. 729 PE3 PE4 730 |\ 731 | \ 732 | \ 733 | \ 734 | \ 735 | \ 736 | \ 737 | \ 738 P1 P2 739 | | 740 | | 741 | | 742 | | 743 P3 P4 P5 P6 744 / | 745 / | 746 / | 747 / | 748 P7 P8--P9--------P10 P11 P12 749 | / 750 | / 751 | / 752 |/ 753 PE1 PE2 PE5 PE6 755 Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at 756 PE1 758 6.4. P2P Bidirectional Connectivity 760 Figure 9 show a bidirectional P2P service connecting PE1 and PE6. 761 This is equivalent to a Segment Routing Traffic Engineering (SR TE) 762 Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and 763 PE6. 765 PE3 PE4 767 P1 P2 769 P3 P4--------P5 P6 770 / \ 771 / \ 772 / \ 773 / \ 774 P7 P8--P9--------P10-P11 P12 775 | / \ | 776 | / \ | 777 | / \ | 778 |/ \| 779 PE1 PE2 PE5 PE6 781 Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6 783 7. Security Considerations 785 TBD 787 8. Manageability Considerations 789 Per VPN OAM and telemetry will be required in order to monitor and 790 verify the performance of network slices. This is particularly 791 important when the performance of a network slice has been committed 792 to a customer through a Service Level Agreement. 794 As noted in Section 5, ACTN may provide a suitable management model. 795 However, an Enhanced VPN service model may be needed following the 796 concepts described in [RFC8309] and similar in structure to the Layer 797 3 VPN service model defined in [RFC8299]. 799 Local policy may be used to balance load between BGP-LS filters that 800 are matched by the same flow. It MUST be possible for an operator to 801 query those policies and understand how traffic is being matched to 802 filters. An implementation MAY also make those policies configurable 803 by an operator so that the operator can exert control over how load 804 is balanced (for example, by applying weights to various filters. 806 9. IANA Considerations 808 9.1. New BGP Path Attribute 810 IANA maintains a registry of "Border Gateway Protocol (BGP) 811 Parameters" with a subregistry of "BGP Path Attributes". IANA is 812 requested to assign a new Path attribute called "BGP-LS Filter 813 attribute" (TBD1 in this document) with this document as a reference. 815 9.2. New BGP-LS Filter attribute TLVs Type Registry 817 IANA maintains a registry of "Border Gateway Protocol (BGP) 818 Parameters". IANA is request to create a new subregistry called the 819 "BGP-LS Filter attribute TLVs" registry. 821 Valid values are in the range 0 to 255. 823 o Values 0 and 255 are to be marked "Reserved, not to be allocated". 825 o Values 1 through 254 are to be assigned according to the "First 826 Come First Served" policy [RFC8126] 828 This document should be given as a reference for this registry. The 829 new registry should track: 831 o Type 833 o Name 835 o Reference Document or Contact 837 o Registration Date 839 The registry should initially be populated as follows: 841 Type | Name | Reference | Date 842 ------+-------------------------+---------------+--------------- 843 1 | Filter TLV | [This.I-D] | Date-to-be-set 844 2 | DSCP List TLV | [This.I-D] | Date-to-be-set 845 3 | Color List TLV | [This.I-D] | Date-to-be-set 846 4 | Root TLV | [This.I-D] | Date-to-be-set 848 10. Acknowledgements 850 The authors are grateful to all those who contributed to the 851 discussions that led to this work: Ron Bonica, Stewart Bryant, Jie 852 Dong, Keyur Patel, Julian Lucek, and Colby Barth. 854 Stephane Litkowski provided useful review comments. 856 11. Contributors 858 The following people contributed text to this document: 860 Gyan Mishra 861 Email: hayabusagsm@gmail.com 863 12. References 865 12.1. Normative References 867 [I-D.ietf-idr-tunnel-encaps] 868 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 869 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 870 encaps-21 (work in progress), January 2021. 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 878 "Definition of the Differentiated Services Field (DS 879 Field) in the IPv4 and IPv6 Headers", RFC 2474, 880 DOI 10.17487/RFC2474, December 1998, 881 . 883 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 884 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 885 DOI 10.17487/RFC4271, January 2006, 886 . 888 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 889 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 890 2006, . 892 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 893 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 894 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 895 2015, . 897 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 898 Patel, "Revised Error Handling for BGP UPDATE Messages", 899 RFC 7606, DOI 10.17487/RFC7606, August 2015, 900 . 902 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 903 S. Ray, "North-Bound Distribution of Link-State and 904 Traffic Engineering (TE) Information Using BGP", RFC 7752, 905 DOI 10.17487/RFC7752, March 2016, 906 . 908 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 909 Writing an IANA Considerations Section in RFCs", BCP 26, 910 RFC 8126, DOI 10.17487/RFC8126, June 2017, 911 . 913 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 914 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 915 May 2017, . 917 12.2. Informative References 919 [I-D.dong-spring-sr-for-enhanced-vpn] 920 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 921 Z., and F. Clad, "Segment Routing based Virtual Transport 922 Network (VTN) for Enhanced VPN", draft-dong-spring-sr-for- 923 enhanced-vpn-13 (work in progress), January 2021. 925 [I-D.ietf-idr-segment-routing-te-policy] 926 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 927 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 928 Routing Policies in BGP", draft-ietf-idr-segment-routing- 929 te-policy-11 (work in progress), November 2020. 931 [I-D.ietf-teas-enhanced-vpn] 932 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 933 Framework for Enhanced Virtual Private Networks (VPN+) 934 Service", draft-ietf-teas-enhanced-vpn-06 (work in 935 progress), July 2020. 937 [I-D.ietf-teas-ietf-network-slice-definition] 938 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 939 Tantsura, "Definition of IETF Network Slices", draft-ietf- 940 teas-ietf-network-slice-definition-00 (work in progress), 941 January 2021. 943 [I-D.king-teas-applicability-actn-slicing] 944 King, D., Drake, J., and H. Zheng, "Applicability of 945 Abstraction and Control of Traffic Engineered Networks 946 (ACTN) to Network Slicing", draft-king-teas-applicability- 947 actn-slicing-08 (work in progress), October 2020. 949 [I-D.nsdt-teas-ns-framework] 950 Gray, E. and J. Drake, "Framework for Transport Network 951 Slices", draft-nsdt-teas-ns-framework-04 (work in 952 progress), July 2020. 954 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 955 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 956 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 957 . 959 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 960 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 961 February 2006, . 963 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 964 Reflection: An Alternative to Full Mesh Internal BGP 965 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 966 . 968 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 969 R., Patel, K., and J. Guichard, "Constrained Route 970 Distribution for Border Gateway Protocol/MultiProtocol 971 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 972 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 973 November 2006, . 975 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 976 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 977 DOI 10.17487/RFC8299, January 2018, 978 . 980 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 981 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 982 . 984 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 985 Decraene, B., Litkowski, S., and R. Shakir, "Segment 986 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 987 July 2018, . 989 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 990 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 991 DOI 10.17487/RFC8453, August 2018, 992 . 994 [TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP 995 TS23.501", 2016, 996 . 999 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 1000 and requirements - 3GPP TS28.530", 2016, 1001 . 1004 Authors' Addresses 1006 John Drake 1007 Juniper Networks 1009 Email: jdrake@juniper.net 1011 Adrian Farrel 1012 Old Dog Consulting 1014 Email: adrian@olddog.co.uk 1016 Luay Jalil 1017 Verizon 1019 Email: luay.jalil@verizon.com 1021 Avinash Lingala 1022 AT&T 1024 Email: ar977m@att.com