idnits 2.17.1 draft-peng-apn-scope-gap-analysis-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.brockners-ippm-ioam-vxlan-gpe' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-serviceid-header' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'I-D.li-6man-app-aware-ipv6-network' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'I-D.peng-apn-security-privacy-consideration' is defined on line 571, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-05 == Outdated reference: A later version (-02) exists of draft-ietf-idr-bgp-flowspec-label-01 == Outdated reference: A later version (-02) exists of draft-ietf-idr-flowspec-mpls-match-01 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-redundancy-protection-00 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-03 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-04 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Peng 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: 28 April 2022 G. Mishra 6 Verizon Inc. 7 25 October 2021 9 APN Scope and Gap Analysis 10 draft-peng-apn-scope-gap-analysis-03 12 Abstract 14 The APN work in IETF is focused on developing a framework and set of 15 mechanisms to derive, convey and use an attribute allowing the 16 implementation of fine-grain user group-level and application group- 17 level requirements in the network layer. APN aims to apply various 18 policies in different nodes along a network path onto a traffic flow 19 altogether, for example, at the headend to steer into corresponding 20 path, at the midpoint to collect corresponding performance 21 measurement data, and at the service function to execute particular 22 policies. Currently there is still no way to efficiently realize 23 this composite network service provisioning along the path. This 24 document further clarifies the scope of the APN work and describes 25 the solution gap analysis. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 28 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. APN Framework and Scope . . . . . . . . . . . . . . . . . . . 3 69 4. Example Use Case and Existing Issues . . . . . . . . . . . . 4 70 5. Basic Solution and Benefits . . . . . . . . . . . . . . . . . 5 71 6. Solution Gap Analysis . . . . . . . . . . . . . . . . . . . . 7 72 6.1. IPv6/MPLS Flow Label . . . . . . . . . . . . . . . . . . 7 73 6.2. SFC ServiceID . . . . . . . . . . . . . . . . . . . . . . 7 74 6.3. IOAM Flow ID . . . . . . . . . . . . . . . . . . . . . . 8 75 6.4. Binding SID . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.5. FlowSpec Label . . . . . . . . . . . . . . . . . . . . . 9 77 6.6. Group Policy ID . . . . . . . . . . . . . . . . . . . . . 9 78 6.7. Detnet Flow Identification . . . . . . . . . . . . . . . 9 79 6.8. Network Slicing Resource ID . . . . . . . . . . . . . . . 10 80 6.9. Service Path ID . . . . . . . . . . . . . . . . . . . . . 10 81 6.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 9. Informative References . . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Application-aware Networking (APN) is introduced in 90 [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. 91 APN conveys an attribute along with data packets into network and 92 makes the network aware about data flow requirements at different 93 granularity levels. 95 Such an attribute is acquired, constructed in a structured value, and 96 then encapsulated in the packet. Such structured value is treated as 97 an opaque object in the network to which the network operator applies 98 policies in various nodes/service functions along the path and 99 provides corresponding services. 101 This structured attribute can be encapsulated in various data planes 102 adopted within a Network Operator controlled limited domain, e.g. 103 MPLS, VXLAN, SR/SRv6 and other tunnel technologies, which waits to be 104 further specified. 106 With APN, it becomes possible to apply various policies in different 107 nodes along a network path onto a traffic flow altogether in a more 108 efficient way, e.g., at the headend to steer into corresponding path, 109 at the midpoint to collect corresponding performance measurement 110 data, and at the service function to execute particular policies. 111 Currently there is still no way to realize this composite network 112 service provisioning along the path very efficiently. It may be 113 possible to stack those various policies in a list of TLVs at the 114 headend. However, this approach would introduce great complexities 115 and impose big challenges on the hardware processing and forwarding. 117 The example use-case presented in this draft further expands on the 118 rationale for such an attribute and how it can be derived and used in 119 that specific context. 121 This document further clarifies the scope of the APN work and 122 describes the solution gap analysis. 124 2. Terminologies 126 APN: Application-aware Networking 128 CPE: Customer Premises Equipment 130 DPI: Deep Packet Inspection 132 OS: Operating System 134 3. APN Framework and Scope 136 The APN framework is introduced in [I-D.li-apn-framework], as shown 137 in the Figure 1. 139 +-----+ +-----+ 140 |App x|-\ /-|App x| 141 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 142 \-|APN- | | Application-aware | |APN- |-/ 143 | |---| Network |---| | 144 /-|Edge | | Service Provisioning | |Edge |-\ 145 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 146 |App y|-/ | | \-|App y| 147 +-----+ |<--- Network Operator Controlled --->| +-----+ 148 Limited Domain 150 Figure 1. APN Framework and Scope 152 APN works within a limited trusted domain. Typically, an APN domain 153 is defined as a Network Operator controlled limited domain (see 154 Figure 1), in which MPLS, VXLAN, SR/SRv6 and other tunnel 155 technologies are adopted to provide network services. 157 With APN, the attribute is acquired based on the existing information 158 in the packet header such as 5-tuple and QinQ (S-VLAN and C-VLAN) at 159 the edge devices of the APN domain, added to the data packets along 160 with the tunnel encapsulation, and delivered to the network, wherein, 161 according to this attribute, corresponding network services are 162 provisioned. When the packets leave the APN domain, the attribute is 163 removed together with the tunnel encapsulation header. 165 4. Example Use Case and Existing Issues 167 To be more specific and more concrete, here we use SD-WAN as an 168 example use case to further expand on the rationale for such 169 attribute and how it can be derived and used in that specific 170 context. 172 In the case of SD-WAN, an enterprise obtains WAN services from an SD- 173 WAN provider so that its employees have access to the applications in 174 the Cloud, and then the SD-WAN provider may buy WAN lines from a 175 Network Operator. The enterprise may know what applications will use 176 the SD-WAN services, but it will only provide the 5 tuples (i.e. 177 source IP address, source port, destination IP address, destination 178 port, transport protocol) of those applications to the SD-WAN 179 provider. So, the SD-WAN provider does not know what applications it 180 is serving, and will only provide 5 tuples to the Network Operator 181 and the service performance requirements for steering their 182 customer's traffic. In this way, the Network Operator does not know 183 anything else about the traffic except the 5 tuples and requirements. 184 Nowadays, SD-WAN is usually using 5-tuple to steer the traffic into 185 corresponding WAN lines across the Network Operator's network 186 [SD-WAN]. 188 However, there are two main issues in the current SD-WAN deployments. 190 1) It is complicated to resolve the 5 tuples. Even worse, as the 191 traffic is encrypted, it becomes impossible to obtain any transport 192 layer information. Moreover, in the IPv6 data plane, with the 193 extension headers being added before the upper layer, in some 194 implementations it becomes very difficult and even impossible to 195 obtain transport layer information because that information is 196 located deep in the packet. So, there is no 5 tuples anymore, and 197 maybe only 2 tuples are available. 199 2) Currently there is still no way to apply various policies in 200 different nodes along the network path onto a traffic flow 201 altogether, that is, at the headend to steer into corresponding path, 202 at the midpoint to collect corresponding performance measurement 203 data, and at the service function to execute particular policies. It 204 may be possible to stack those various policies in a list of TLVs at 205 the headend. However, this approach would introduce great 206 complexities and impose big challenges on the hardware processing and 207 forwarding. 209 5. Basic Solution and Benefits 211 With APN, at the edge node, i.e. CPE, of the SD-WAN (see Figure 2), 212 the 5-tuple, plus information related to user or application group- 213 level requirements is constructed into a structured value, called APN 214 attribute. This attribute is only meaningful for the network 215 operators to apply various policies in different nodes/service 216 functions, which can be enforced from the Controllers. 218 +-----------------+ 219 +---------|SD-WAN Controller|---------+ 220 | +--------|--------+ | 221 | | | 222 | +-------|-------+ | 223 | |SDN Controller| | 224 | +-------|-------+ | 225 +-----+ | | | +-----+ 226 |App x|-\ | | | /-|App x| 227 +-----+ | +--|--+ +-----------|-----------+ +--|--+ | +-----+ 228 \-| | | Application-aware | | |-/ 229 |CPE 1|---| Network |---|CPE 2| 230 /-| | | Service Provisioning | | |-\ 231 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 232 |App y|-/ | | \-|App y| 233 +-----+ |<--- Network Operator Controlled --->| +-----+ 234 Limited Domain 236 Figure 2. SD-WAN using the APN Framework 238 With such an attribute in the network, we can easily solve the two 239 issues above-mentioned. For example, when the packet is sent from 240 the CPE1 and the attribute is added along with the tunnel 241 encapsulation, then it is not necessary to resolve the 5-tuple and 242 perform the deep inspection in every node along the path. This 243 attribute is encapsulated in the network layer and can be easily read 244 by the routers and service functions. If the tunnel is based on the 245 IPv6 data plane, for example, such an attribute can be encapsulated 246 in an option of IPv6 hop-by-hop options header. 248 Since this attribute is taken as an object to the network, the 249 network operators will simply place the policies in the nodes/service 250 functions where this indicated traffic will go through, and the 251 corresponding node/service function will just apply policies for this 252 object. This can be easily done by utilizing this attribute, which 253 is not possible with any current existing mechanism. 255 Such attribute will also bring other benefits, for example, 257 * Improve the forwarding performance since it will only use 1 field 258 in the IP layer instead of resolving 5 tuples, which will also 259 improve the scalability. 261 * Very flexible policy enforcement in various nodes and service 262 functions along the network path. 264 Furthermore, with such attribute, more new services could be enabled, 265 for example, 267 * Even more fine-granularity performance measurement could be 268 achieved and the granularity to be monitored and visualized can be 269 controllable, which is able to relieve the processing pressure on 270 the controller when it is facing the massive monitoring data. 272 * The policy execution on the service function can be based only on 273 this value and not based on 5-tuple, which can eliminate the need 274 of deep packet inspection. 276 * The underlay performance guarantee could be achieved for SD-WAN 277 overlay services, such as explicit traffic engineering path 278 satisfying SLA and selective visualized accurate performance 279 measurement. 281 6. Solution Gap Analysis 283 There are already some solutions specified in IETF, which use 284 identifier to perform traffic steering and service provisioning. 285 However, the existing solutions are specific to a particular scenario 286 or data plane. None of them is the same as APN and able to achieve 287 the same effects. 289 6.1. IPv6/MPLS Flow Label 291 [RFC6437] specifies the IPv6 flow label which enables the IPv6 flow 292 classification. However, the IPv6 flow label is mainly used for 293 Equal Cost Multipath Routing (ECMP) and Link Aggregation [RFC6438]. 295 Similarly, [RFC6391] describes a method of adding an additional Label 296 Stack Entry (LSE) at the bottom of the stack in order to facilitate 297 the load balancing of the flows within a pseudowire (PW) over the 298 available ECMPs. A similar design for general MPLS use has also been 299 proposed in [RFC6790] using the concept of Entropy Label. 301 6.2. SFC ServiceID 303 Subscriber Identifier and Performance Policy Identifier are specified 304 in [RFC8979]. These identifiers are carried only in the Network 305 Service Header (NSH) [RFC8300] Context Header, as shown in Figure 3, 306 while the APN attribute can be carried in various data plane 307 encapsulations. 309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Metadata Class | Type |U| Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 ~ Subscriber Identifier ~ 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Metadata Class | Type |U| Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 ~ Performance Policy Identifier ~ 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 3. Subscriber Identifier and Performance Policy Identifier 329 In this draft [RFC8979], the Subscriber Identifier carries an opaque 330 local identifier that is assigned to a subscriber by a network 331 operator, and the Performance Policy Identifier represents an opaque 332 value pointing to specific performance policy to be enforced. In 333 this way, in order to apply various policies in different nodes along 334 the network path onto a traffic flow altogether, e.g., at the headend 335 to steer into corresponding path, at the midpoint to collect 336 corresponding performance measurement data, and at the service 337 function to execute particular policies, those various policies would 338 have to be stacked in a list of TLVs at the headend, introducing 339 great complexities and big challenges on the hardware processing and 340 forwarding. 342 The APN attribute is treated as an opaque object in the network, to 343 which the network operator applies policies in various nodes/service 344 functions along the path and provide corresponding services. 346 6.3. IOAM Flow ID 348 A 32-bit Flow ID is specified in [I-D.ietf-ippm-ioam-direct-export], 349 which is used to correlate the exported data of the same flow from 350 multiple nodes and from multiple packets, while the APN attribute can 351 serve more various purposes. 353 6.4. Binding SID 355 The Binding SID (BSID) [RFC8402] is bound to an SR Policy, 356 instantiation of which may involve a list of SIDs. Any packets 357 received with an active segment equal to BSID are steered onto the 358 bound SR Policy. A BSID may be either a local or a global SID. 359 While the APN attribute is not bound to SR only, and it can be 360 carried in various data plane encapsulations. 362 6.5. FlowSpec Label 364 The flow specification (FlowSpec) [RFC5575] is actually an n-tuple 365 consisting of several matching criteria that can be applied to IP 366 traffic, which include elements such as source and destination 367 address prefixes, IP protocol, and transport protocol port numbers. 368 In BGP VPN/MPLS networks, BGP FlowSpec can be extended to identify 369 and change (push/swap/pop) the label(s) for traffic that matches a 370 particular FlowSpec rule in [I-D.ietf-idr-flowspec-mpls-match] and 371 [I-D.ietf-idr-bgp-flowspec-label]. In 372 [I-D.liang-idr-bgp-flowspec-route], BGP is used to distribute the 373 FlowSpec rule bound with label(s). While the APN attribute is not 374 bound to MPLS only, and it can be carried in various data plane 375 encapsulations. 377 6.6. Group Policy ID 379 The capabilities of the VXLAN-GPE protocol can be extended by 380 defining next protocol "shim" headers that are used to implement new 381 data plane functions. For example, Group Policy ID is carried in the 382 Group-Based Policy (GBP) Shim header [I-D.lemon-vxlan-lisp-gpe-gbp]. 383 GENEVE has similar ability as VXLAN-GPE to carry metadata. 385 6.7. Detnet Flow Identification 387 Identification and Specification of DetNet Flows is specified in 388 [RFC9016]. DetNet MPLS flows can be identified and specified by the 389 SLabel and the FLabelStack. The IP 6-tuple is used for DetNet IP 390 flow identification, which consists of SourceIpAddress, 391 DestinationIpAddress, Dscp, Protocol, SourcePort, and 392 DestinationPort. IPv6FlowLabel and IPSecSpi are additional 393 attributes that can be used for DetNet flow identification in 394 addition to the 6-tuple. Therefore, the Detnet IP Flow ID is logical 395 and there is no such Flow ID carried for Detnet, but only the 6-tuple 396 is directly used to identify the Detnet flows. 398 Only one exceptional case, in 399 [I-D.ietf-spring-sr-redundancy-protection], the 32-bit flow 400 identification (FID) identifies one specific Detnet flow of 401 redundancy protection. This FID is usually allocated from 402 centralized controller to the SR ingress node or redundancy node in 403 SR network. 405 6.8. Network Slicing Resource ID 407 In [I-D.dong-6man-enhanced-vpn-vtn-id], VTN Resource ID is a 4-octet 408 identifier which uniquely identifies the set of network resources 409 allocated to a VTN. For network slicing, the ID is used to indicate 410 the network resources to be allocated to the network slices and it is 411 not bound to any traffic flow. 413 6.9. Service Path ID 415 In [RFC8300], Service Path Identifier (SPI) uniquely identifies a 416 Service Function Path (SFP). Participating nodes MUST use this 417 identifier for SFP selection. The initial Classifier MUST set the 418 appropriate SPI for a given classification result. For SFC, the ID 419 is used to indicate a SF path and it is not bound to any traffic 420 flow. 422 6.10. Summary 424 The comparison of the identifiers for the typical network services 425 (incl. iOAM, Detnet, Network Slicing (NS), and Service Function 426 Chaining (SFC)) is shown in the following Table from different 427 aspects (incl. ID, Identification Object, Source (for generating the 428 ID), Configuration (Conf.) node, and Size). 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | ID | Identification Object | Source |Conf. node| Size | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | APN | APN ID | The flow that needs | 5-tuple|Controller|32bits| 434 | | | fine-granular services| Layer 2| |128b | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | iOAM | Flow ID | The flow that needs | - |Controller|32bits| 437 | | | performance monitoring| | Ingress | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |Detnet| Flow ID | The flow that needs | - |Controller| - | 440 | | (6-tuple) | Detnet services | | | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |Detnet| Flow ID | The redundant | - | Detnet |32bits| 443 | | | protection flow | |Controller| | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | NS |Resource ID| The network resources | |Controller|32bits| 446 | | | that are allocated to | - | | | 447 | | | network slices | | | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | SFC | SPI | The SF Path | - |Controller|24bits| 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | SFC |Performance| The performance policy| - |Controller| - | 452 | | Policy ID | | | | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Table 1. Comparison of the Identifiers 457 As driven by ever-emerging new 5G services, fine-granularity service 458 provisioning becomes urgent. The existing solutions are either 459 specific to a particular scenario or data plane. While APN aims to 460 define a generalized attribute used for fine-granularity service 461 provisioning, and can be carried in various data plane 462 encapsulations. 464 7. IANA Considerations 466 There are no IANA considerations in this document. 468 8. Acknowledgements 470 The authors would like to acknowledge Martin Vigoureux, Alvaro 471 Retana, Barry Leiba, Stefano Previdi, Adrian Farrel, and Daniel King 472 for their valuable review and comments. 474 9. Informative References 476 [I-D.brockners-ippm-ioam-vxlan-gpe] 477 Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, 478 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, 479 A., Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 480 Encapsulation for In-situ OAM Data", Work in Progress, 481 Internet-Draft, draft-brockners-ippm-ioam-vxlan-gpe-03, 4 482 November 2019, . 485 [I-D.dong-6man-enhanced-vpn-vtn-id] 486 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 487 "Carrying Virtual Transport Network Identifier in IPv6 488 Extension Header", Work in Progress, Internet-Draft, 489 draft-dong-6man-enhanced-vpn-vtn-id-05, 8 September 2021, 490 . 493 [I-D.ietf-idr-bgp-flowspec-label] 494 Liang, Q., Hares, S., You, J., Raszuk, R., and D. Ma, 495 "Carrying Label Information for BGP FlowSpec", Work in 496 Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec- 497 label-01, 6 December 2016, 498 . 501 [I-D.ietf-idr-flowspec-mpls-match] 502 Yong, L., Hares, S., Liang, Q., and J. You, "BGP Flow 503 Specification Filter for MPLS Label", Work in Progress, 504 Internet-Draft, draft-ietf-idr-flowspec-mpls-match-01, 6 505 December 2016, . 508 [I-D.ietf-ippm-ioam-direct-export] 509 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 510 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 511 OAM Direct Exporting", Work in Progress, Internet-Draft, 512 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 513 . 516 [I-D.ietf-sfc-serviceid-header] 517 Sarikaya, B., Hugo, D. V., and M. Boucadair, "Subscriber 518 and Performance Policy Identifier Context Headers in the 519 Network Service Header (NSH)", Work in Progress, Internet- 520 Draft, draft-ietf-sfc-serviceid-header-14, 11 December 521 2020, . 524 [I-D.ietf-spring-sr-redundancy-protection] 525 Geng, X., Chen, M., Yang, F., Garvia, P. C., and G. 526 Mishra, "SRv6 for Redundancy Protection", Work in 527 Progress, Internet-Draft, draft-ietf-spring-sr-redundancy- 528 protection-00, 23 September 2021, 529 . 532 [I-D.lemon-vxlan-lisp-gpe-gbp] 533 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 534 Policy Encoding with VXLAN-GPE and LISP-GPE", Work in 535 Progress, Internet-Draft, draft-lemon-vxlan-lisp-gpe-gbp- 536 02, 30 April 2019, . 539 [I-D.li-6man-app-aware-ipv6-network] 540 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 541 P., Cao, C., and K. Ebisawa, "Application-aware IPv6 542 Networking (APN6) Encapsulation", Work in Progress, 543 Internet-Draft, draft-li-6man-app-aware-ipv6-network-03, 544 22 February 2021, . 547 [I-D.li-apn-framework] 548 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 549 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 550 "Application-aware Networking (APN) Framework", Work in 551 Progress, Internet-Draft, draft-li-apn-framework-03, 24 552 May 2021, . 555 [I-D.li-apn-problem-statement-usecases] 556 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 557 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 558 "Problem Statement and Use Cases of Application-aware 559 Networking (APN)", Work in Progress, Internet-Draft, 560 draft-li-apn-problem-statement-usecases-04, 16 June 2021, 561 . 564 [I-D.liang-idr-bgp-flowspec-route] 565 Liang, Q. and J. You, "BGP FlowSpec based Multi- 566 dimensional Route Distribution", Work in Progress, 567 Internet-Draft, draft-liang-idr-bgp-flowspec-route-00, 20 568 October 2014, . 571 [I-D.peng-apn-security-privacy-consideration] 572 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 573 "APN Security and Privacy Considerations", Work in 574 Progress, Internet-Draft, draft-peng-apn-security-privacy- 575 consideration-02, 16 June 2021, 576 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 585 and D. McPherson, "Dissemination of Flow Specification 586 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 587 . 589 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 590 Regan, J., and S. Amante, "Flow-Aware Transport of 591 Pseudowires over an MPLS Packet Switched Network", 592 RFC 6391, DOI 10.17487/RFC6391, November 2011, 593 . 595 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 596 "IPv6 Flow Label Specification", RFC 6437, 597 DOI 10.17487/RFC6437, November 2011, 598 . 600 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 601 for Equal Cost Multipath Routing and Link Aggregation in 602 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 603 . 605 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 606 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 607 RFC 6790, DOI 10.17487/RFC6790, November 2012, 608 . 610 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 611 "Network Service Header (NSH)", RFC 8300, 612 DOI 10.17487/RFC8300, January 2018, 613 . 615 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 616 Decraene, B., Litkowski, S., and R. Shakir, "Segment 617 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 618 July 2018, . 620 [RFC8979] Sarikaya, B., von Hugo, D., and M. Boucadair, "Subscriber 621 and Performance Policy Identifier Context Headers in the 622 Network Service Header (NSH)", RFC 8979, 623 DOI 10.17487/RFC8979, February 2021, 624 . 626 [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 627 Fedyk, "Flow and Service Information Model for 628 Deterministic Networking (DetNet)", RFC 9016, 629 DOI 10.17487/RFC9016, March 2021, 630 . 632 [SD-WAN] MEF 70.1 Draft (R1), available at https://www.mef.net/wp- 633 content/uploads/2020/08/MEF-70-1-Draft-R1.pdf/, "SD-WAN 634 Service Attributes and Service Framework", August 2020. 636 Authors' Addresses 638 Shuping Peng 639 Huawei Technologies 640 Beijing 641 China 643 Email: pengshuping@huawei.com 645 Zhenbin Li 646 Huawei Technologies 647 Beijing 648 China 650 Email: lizhenbin@huawei.com 652 Gyan Mishra 653 Verizon Inc. 654 United States of America 656 Email: gyan.s.mishra@verizon.com