idnits 2.17.1 draft-peng-apn-scope-gap-analysis-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 16, 2020) is 1227 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8300' is mentioned on line 289, but not defined == Unused Reference: 'I-D.peng-apn-security-privacy-consideration' is defined on line 433, but no explicit reference was found in the text == 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-02 == Outdated reference: A later version (-03) exists of draft-li-6man-app-aware-ipv6-network-02 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-01 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-01 == Outdated reference: A later version (-02) exists of draft-peng-apn-security-privacy-consideration-00 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 11 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: June 19, 2021 December 16, 2020 7 APN Scope and Gap Analysis 8 draft-peng-apn-scope-gap-analysis-00 10 Abstract 12 The APN work in IETF is focused on developing a framework and set of 13 mechanisms to derive, convey and use an identifier to allow for 14 implementing fine-grain user-, application-, and service-level 15 requirements at the network layer. This document describes the scope 16 of the APN work and the solution gap analysis. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 19, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. APN Framework and Scope . . . . . . . . . . . . . . . . . . . 3 61 4. Example Use Case and Existing Issues . . . . . . . . . . . . 4 62 5. Basic Solution and Benefits . . . . . . . . . . . . . . . . . 5 63 6. Solution Gap Analysis . . . . . . . . . . . . . . . . . . . . 6 64 6.1. IPv6/MPLS Flow Label . . . . . . . . . . . . . . . . . . 6 65 6.2. SFC ServiceID . . . . . . . . . . . . . . . . . . . . . . 7 66 6.3. IOAM Flow ID . . . . . . . . . . . . . . . . . . . . . . 8 67 6.4. Binding SID . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.5. FlowSpec Label . . . . . . . . . . . . . . . . . . . . . 8 69 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Informative References . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Application-aware Networking (APN) is introduced in 78 [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. 79 APN conveys an identifier along with data packets into network 80 [I-D.li-6man-app-aware-ipv6-network] and make the network aware of 81 fine-grain user-, application-, and service-level requirements. 83 Such identifier is acquired, constructed in a structured value, and 84 then encapsulated in the packets. Such structured value is treated 85 as an opaque object in the network, to which the network operator 86 applies policies in various nodes/service functions along the path 87 and provide corresponding services. The identifier may represent the 88 application traffic of a particular user but does not identify the 89 actual user nor the actual application for network operators. 91 The example use-case presented in this draft further expands on the 92 rationale for such identifier and how it can be derived and used in 93 that specific context. 95 This document describes the scope of the APN work and the solution 96 gap analysis. 98 2. Terminologies 100 APN: Application-aware Networking 102 CPE: Customer Premises Equipment 104 DPI: Deep Packet Inspection 106 OS: Operating System 108 3. APN Framework and Scope 110 The APN framework is introduced in [I-D.li-apn-framework], as shown 111 in the Figure 1. 113 +-----+ +-----+ 114 |App x|-\ /-|App x| 115 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 116 \-|App- | | Application-aware | |App- |-/ 117 |aware|---| Network |---|aware| 118 /-|Edge | | Service Provisioning | |Edge |-\ 119 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 120 |App y|-/ | | \-|App y| 121 +-----+ |<--- Network Operator Controlled --->| +-----+ 122 Limited Domain 124 Figure 1. APN Framework and Scope 126 With APN, the identifier is added to the data packets (e.g. in the 127 IPv6 extensions headers [I-D.li-6man-app-aware-ipv6-network]) and 128 delivered to the network, wherein, according to this identifier, 129 corresponding network services are provisioned. 131 The identifier can be added either directly by the application (e.g. 132 App x in the Figure 1) or at the network edge devices (i.e. App- 133 aware Edge in the Figure 1), named as host-side solution and network- 134 side solution, respectively. 136 With the host-side solution, after the identifier is obtained by 137 application, it will be added to the data packets during its 138 encapsulation process going through the protocol stack in the OS. 139 The host-side solution may require an update of the underlying 140 operating system in order to allow the application element to pass 141 the identifier to the socket service when building the packet header. 143 With the network-side solution, the identifier is added according to 144 the configured policy at the network edge device. For the APN work 145 to be conducted in IETF, we will focus on the network-side solution. 147 APN works within a limited trusted domain. Typically, an APN domain 148 is defined as a Network Operator controlled limited domain (see 149 Figure 1), in which MPLS, VXLAN, SR/SRv6 and other tunnel 150 technologies are adopted to provide network services. 152 4. Example Use Case and Existing Issues 154 To be more specific and more concrete, here we use SD-WAN as an 155 example use case to further expand on the rationale for such 156 identifier and how it can be derived and used in that specific 157 context. 159 In the case of SD-WAN, an enterprise usually buys WAN services from 160 an SD-WAN provider for its employees to access the applications in 161 the Cloud, and then the SD-WAN provider may buy WAN lines from a 162 network operator. The enterprise may know what applications will use 163 the SD-WAN services but it will only provide the 5 tuples of those 164 applications to the SD-WAN provider. So the SD-WAN provider does not 165 know what applications it is actually serving. And then, the SD-WAN 166 provider would usually buy WAN services from Network Operator. It 167 will only provide 5 tuples to the Network Operator and the service 168 performance requirements for steering their customer's traffic. In 169 this way, the Network Operator does not know anything else about the 170 traffic except the 5 tuples and requirements. Nowadays, SD-WAN is 171 usually using 5-tuple to steer the traffic into corresponding WAN 172 lines across the Network Operator's network [SD-WAN]. 174 However, there are two main issues in the current SD-WAN deployments. 176 1) It is complicated and hard to resolve the 5 tuples. Even worse, 177 with the traffic being all encrypted, it becomes impossible to obtain 178 any transport layer information. Moreover, in the IPv6 data plane, 179 with the extension headers being added before the upper layer, in 180 some implementations it becomes very difficult and even impossible to 181 obtain transport layer information because that information is so 182 deep in the packet. So there is no 5 tuples anymore, and maybe only 183 2 tuples are available. 185 2) Currently there is still no way to apply various policies in 186 different nodes along the network path onto a traffic flow 187 altogether, that is, at the headend to steer into corresponding path, 188 at the midpoint to collect corresponding performance measurement 189 data, and at the service function to execute particular policies. 190 Maybe we could stack those various policies in a list of TLVs at the 191 headend. However, it is going to introduce great complexities and 192 impose big challenges on the hardware processing and forwarding. 194 5. Basic Solution and Benefits 196 With APN, at the edge node, i.e. CPE, of the SD-WAN (see Figure 2), 197 the 5-tuple, plus information related to user or application 198 requirements is constructed into a structured value. Please note, 199 here the structured value is just a bit string and does not indicate 200 actual application or user identification. This information is only 201 meaningful for the network operators to apply various policies in 202 different nodes/service functions, which can be enforced from the 203 Controllers. 205 +-----------------+ 206 +---------|SD-WAN Controller|---------+ 207 | +--------|--------+ | 208 | | | 209 | +-------|-------+ | 210 | |SDN Controller| | 211 | +-------|-------+ | 212 +-----+ | | | +-----+ 213 |App x|-\ | | | /-|App x| 214 +-----+ | +--|--+ +-----------|-----------+ +--|--+ | +-----+ 215 \-| | | Application-aware | | |-/ 216 |CPE 1|---| Network |---|CPE 2| 217 /-| | | Service Provisioning | | |-\ 218 +-----+ | +-----+ +-----------------------+ +-----+ | +-----+ 219 |App y|-/ | | \-|App y| 220 +-----+ |<--- Network Operator Controlled --->| +-----+ 221 Limited Domain 223 Figure 2. SD-WAN using the APN Framework 225 With such identifier in the network, we can easily solve the two 226 issues above-mentioned. We will not need to resolve the 5-tuple and 227 perform the deep inspection any more. This structured value is 228 encapsulated in the IP layer and can be easily read by the routers 229 and service functions. If the data plane is SRv6, for example, such 230 identifier can be encapsulated in an SRH TLV where it represents the 231 policy corresponding to the application requirements. 233 Since this identifier is taken as an object to the network, the 234 network operators will simply place the policies in the nodes/service 235 functions where this indicated traffic will go through, and the 236 corresponding node/service function will just apply policies for this 237 object. This can be easily done by utilizing this structured value, 238 which is not possible with any current existing mechanism. 240 Such structured value will also bring other benefits, for example, 242 o Improve the forwarding performance since it will only use 1 field 243 in the IP layer instead of resolving 5 tuples, which will also 244 improve the scalability. 246 o Very flexible policy enforcement in various nodes and service 247 functions along the network path. 249 Furthermore, with such structured value, more new services could be 250 enabled, for example, 252 o Even more fine-granularity performance measurement could be 253 achieved and the granularity to be monitored and visualized can be 254 controllable, which is able to relieve the processing pressure on 255 the controller when it is facing the massive monitoring data. 257 o The policy execution on the service function can be only based on 258 this value and not based on 5-tuple, which can eliminate the need 259 of deep packet inspection. 261 o The underlay performance guarantee could be achieved for SD-WAN 262 overlay services, such as explicit traffic engineering path 263 satisfying SLA and selective visualized accurate performance 264 measurement. 266 6. Solution Gap Analysis 268 There are already some solutions specified in IETF, which use 269 identifier to perform traffic steering and service provisioning. 270 However, none of them is the same as APN and able to achieve the same 271 effects. 273 6.1. IPv6/MPLS Flow Label 275 [RFC6437] specifies the IPv6 flow label which enables the IPv6 flow 276 classification. However, the IPv6 flow label is mainly used for 277 Equal Cost Multipath Routing (ECMP) and Link Aggregation [RFC6438]. 279 Similarly, [RFC6391] describes a method of adding an additional Label 280 Stack Entry (LSE) at the bottom of the stack in order to facilitate 281 the load balancing of the flows within a pseudowire (PW) over the 282 available ECMPs. A similar design for general MPLS use has also been 283 proposed in [RFC6790] using the concept of Entropy Label. 285 6.2. SFC ServiceID 287 Subscriber Identifier and Performance Policy Identifier are specified 288 in [I-D.ietf-sfc-serviceid-header]. These identifiers are carried 289 only in the Network Service Header (NSH) [RFC8300] Context Header, as 290 shown in Figure 3, while the APN identifier can be carried in various 291 data plane encapsulations. 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Metadata Class | Type |U| Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 ~ Subscriber Identifier ~ 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Metadata Class | Type |U| Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 ~ Performance Policy Identifier ~ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 3. Subscriber Identifier and Performance Policy Identifier 313 In this draft [I-D.ietf-sfc-serviceid-header], the Subscriber 314 Identifier carries an opaque local identifier that is assigned to a 315 subscriber by a network operator, and the Performance Policy 316 Identifier represents an opaque value pointing to specific 317 performance policy to be enforced. In this way, in order to apply 318 various policies in different nodes along the network path onto a 319 traffic flow altogether, e.g., at the headend to steer into 320 corresponding path, at the midpoint to collect corresponding 321 performance measurement data, and at the service function to execute 322 particular policies, those various policies would have to be stacked 323 in a list of TLVs at the headend, introducing great complexities and 324 big challenges on the hardware processing and forwarding. 326 The APN identifier, which is a structured value, is treated as an 327 opaque object in the network, to which the network operator applies 328 policies in various nodes/service functions along the path and 329 provide corresponding services. The identifier may represent the 330 application traffic of a particular user but does not identify the 331 actual user nor the actual application for network operators. 333 6.3. IOAM Flow ID 335 A 32-bit Flow ID is specified in [I-D.ietf-ippm-ioam-direct-export], 336 which is used to correlate the exported data of the same flow from 337 multiple nodes and from multiple packets, while the APN identifier 338 can serve more various purposes. 340 6.4. Binding SID 342 The Binding SID (BSID) [RFC8402] is bound to an SR Policy, 343 instantiation of which may involve a list of SIDs. Any packets 344 received with an active segment equal to BSID are steered onto the 345 bound SR Policy. A BSID may be either a local or a global SID. 346 While the APN identifier is not bound to SRv6 only, and it can be 347 carried in various data plane encapsulations. 349 6.5. FlowSpec Label 351 The flow specification (FlowSpec) [RFC5575] is actually an n-tuple 352 consisting of several matching criteria that can be applied to IP 353 traffic, which include elements such as source and destination 354 address prefixes, IP protocol, and transport protocol port numbers. 355 In BGP VPN/MPLS networks, BGP FlowSpec can be extended to identify 356 and change (push/swap/pop) the label(s) for traffic that matches a 357 particular FlowSpec rule in [I-D.ietf-idr-flowspec-mpls-match] and 358 [I-D.ietf-idr-bgp-flowspec-label]. In 359 [I-D.liang-idr-bgp-flowspec-route], BGP is used to distribute the 360 FlowSpec rule bound with label(s). While the APN identifier is not 361 bound to MPLS only, and it can be carried in various data plane 362 encapsulations. 364 6.6. Summary 366 As driven by ever-emerging new 5G services, fine-granularity service 367 provisioning becomes urgent. The existing solutions are either 368 specific to a particular scenario or data plane. While APN aims to 369 define a generalized identifier used for fine-granularity service 370 provisioning, and can be carried in various data plane 371 encapsulations. 373 7. IANA Considerations 375 There are no IANA considerations in this document. 377 8. Acknowledgements 379 The authors would like to acknowledge Martin Vigoureux, Alvaro 380 Retana, Barry Leiba, Stefano Previdi, Adrian Farrel, and Daniel King 381 for their valuable review and comments. 383 9. Informative References 385 [I-D.ietf-idr-bgp-flowspec-label] 386 liangqiandeng, l., Hares, S., You, J., Raszuk, R., and d. 387 danma@cisco.com, "Carrying Label Information for BGP 388 FlowSpec", draft-ietf-idr-bgp-flowspec-label-01 (work in 389 progress), December 2016. 391 [I-D.ietf-idr-flowspec-mpls-match] 392 Yong, L., Hares, S., liangqiandeng, l., and J. You, "BGP 393 Flow Specification Filter for MPLS Label", draft-ietf-idr- 394 flowspec-mpls-match-01 (work in progress), December 2016. 396 [I-D.ietf-ippm-ioam-direct-export] 397 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 398 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 399 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 400 export-02 (work in progress), November 2020. 402 [I-D.ietf-sfc-serviceid-header] 403 Sarikaya, B., Hugo, D., and M. Boucadair, "Service 404 Function Chaining: Subscriber and Performance Policy 405 Identification Variable-Length Network Service Header 406 (NSH) Context Headers", draft-ietf-sfc-serviceid-header-14 407 (work in progress), December 2020. 409 [I-D.li-6man-app-aware-ipv6-network] 410 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 411 P., Liu, C., and K. Ebisawa, "Application-aware IPv6 412 Networking (APN6) Encapsulation", draft-li-6man-app-aware- 413 ipv6-network-02 (work in progress), July 2020. 415 [I-D.li-apn-framework] 416 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 417 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 418 aware Networking (APN) Framework", draft-li-apn- 419 framework-01 (work in progress), September 2020. 421 [I-D.li-apn-problem-statement-usecases] 422 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 423 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 424 Statement and Use Cases of Application-aware Networking 425 (APN)", draft-li-apn-problem-statement-usecases-01 (work 426 in progress), September 2020. 428 [I-D.liang-idr-bgp-flowspec-route] 429 Liang, Q. and J. You, "BGP FlowSpec based Multi- 430 dimensional Route Distribution", draft-liang-idr-bgp- 431 flowspec-route-00 (work in progress), October 2014. 433 [I-D.peng-apn-security-privacy-consideration] 434 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 435 "APN Security and Privacy Considerations", draft-peng-apn- 436 security-privacy-consideration-00 (work in progress), 437 September 2020. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 445 and D. McPherson, "Dissemination of Flow Specification 446 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 447 . 449 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 450 Regan, J., and S. Amante, "Flow-Aware Transport of 451 Pseudowires over an MPLS Packet Switched Network", 452 RFC 6391, DOI 10.17487/RFC6391, November 2011, 453 . 455 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 456 "IPv6 Flow Label Specification", RFC 6437, 457 DOI 10.17487/RFC6437, November 2011, 458 . 460 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 461 for Equal Cost Multipath Routing and Link Aggregation in 462 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 463 . 465 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 466 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 467 RFC 6790, DOI 10.17487/RFC6790, November 2012, 468 . 470 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 471 Decraene, B., Litkowski, S., and R. Shakir, "Segment 472 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 473 July 2018, . 475 [SD-WAN] MEF 70.1 Draft (R1), available at https://www.mef.net/wp- 476 content/uploads/2020/08/MEF-70-1-Draft-R1.pdf/, "SD-WAN 477 Service Attributes and Service Framework", August 2020. 479 Authors' Addresses 481 Shuping Peng 482 Huawei Technologies 483 Beijing 484 China 486 Email: pengshuping@huawei.com 488 Zhenbin Li 489 Huawei Technologies 490 Beijing 491 China 493 Email: lizhenbin@huawei.com