idnits 2.17.1 draft-li-cross-area-ietf-work-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 : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 3 characters 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 (July 26, 2019) is 1737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-06 == Outdated reference: A later version (-13) exists of draft-ietf-opsawg-ntf-01 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-06 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-02 == Outdated reference: A later version (-03) exists of draft-li-6man-app-aware-ipv6-network-00 == Outdated reference: A later version (-03) exists of draft-li-nmrg-intent-classification-01 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-04 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-03 == Outdated reference: A later version (-07) exists of draft-wu-model-driven-management-virtualization-05 == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-03 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Informational July 26, 2019 5 Expires: January 27, 2020 7 Cross-Area Work in the IETF 8 draft-li-cross-area-ietf-work-00 10 Abstract 12 This document investigates the benefits of cross-area work in the 13 IETF. It is examines existing cross-area work and identifies other 14 possibilities for work that spans more than one area. The intention 15 is to help community members who focus their work within a specific 16 area to understand related work in other areas and to motivate 17 efficient cooperation across different areas in the IETF. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 27, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Network Intelligence/Telemetry . . . . . . . . . . . . . . . 6 64 5.1. Network Telemetry . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Network Intelligence . . . . . . . . . . . . . . . . . . 8 66 6. 5G Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Cross-layer Work . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Path-Aware Networking . . . . . . . . . . . . . . . . . . 9 69 7.2. Application-aware IPv6 Networking . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 With the development of new network technologies such as cloud 80 computing, 5G, IoT, etc., very many applications are carried over the 81 network. Each has different needs for network bandwidth, latency, 82 jitter, and packet loss, etc. 84 Work in the IETF is divided into Areas. The demands of the new 85 technologies motivates innovation and new architectures in multiple 86 network layers, and resulting cross-area work is increasing in the 87 IETF. Existing protocol practice shows that people who focus on one 88 specific area are sometimes not aware of related work in different 89 areas. Some cross-area work is not recognized until late in the 90 lifecycle so that useful experiences cannot be shared early in the 91 development. Fixing problems that are identified late can become 92 time consuming. 94 This document investigates the benefits of cross-area work in the 95 IETF. It is examines existing cross-area work and identifies other 96 possibilities for work that spans more than one area. The intention 97 is to help community members who focus their work within a specific 98 area to understand related work in other areas and to motivate 99 efficient cooperation across different areas in the IETF. 101 2. Terminology 103 SRv6: Segment Routing over IPv6 105 MPLS: Multi-Protocol Label Switch 107 3. SRv6 109 Segment Routing is an important networking technology developed in 110 the IETF. SRv6 is the Segment Routing deployed on the IPv6 data 111 plane[RFC8200] and SRv6 network programming 112 [I-D.ietf-spring-srv6-network-programming] is introduced to support 113 multiple services which have requirements on the SRv6 network. The 114 related areas and Working Groups for SRv6 are shown in Figure 1: the 115 work can be categorized into Basics, Encapsulations, Protocols, YANG, 116 Use cases, and Others. 118 --------------------------- SRv6 ---------------------------- 119 | | | | | | 120 | | | | | | 121 +------+ +------+ +---------+ +-----+ +---------+ +------+ 122 |Basics| |Encaps| |Protocols| |YANG | |Use Cases| |Others| 123 +------+ +------+ +---------+ +-----+ +---------+ +------+ 124 | | | | | | 125 RTG SPRING DETNET LSR YANG DETNET BFD 126 BIER BESS TEAS RTGWG 127 IDR SFC 128 PCE BIER 130 INT 6MAN 131 6LO 132 LPWAN 134 Figure 1: Related Areas/WGs for SRv6 136 The major IETF areas for SRv6 work are the RTG area and the INT area. 137 There is work in multiple working groups in the RTG area, and the 138 major work in the INT area includes the new IPv6 encapsulation and 139 the possible compression work on the IPv6 header. 141 4. YANG Models 143 Data models written in the YANG modelling language [RFC6020] can be 144 used for service and network management to provide a programmatic 145 approach for representing (virtual) services or networks and for 146 deriving configuration information that will be forwarded to network 147 and service components that are used to build and deliver the 148 service. 150 YANG module developers have taken both top-down and bottom-up 151 approaches to develop modules [RFC8199] and to establish a mapping 152 between network technology and customer requirements on the top or 153 abstracting common construct from various network technologies on the 154 bottom. There are many data models including configuration and 155 service models that have been specified or are being specified by the 156 IETF. They cover many of the networking protocols and techniques. 158 Figure 2 is from [I-D.wu-model-driven-management-virtualization] 159 provides and provides an overview of various macro-functional blocks 160 at different levels that articulate the various YANG data modules. 161 In this figure, example models developed in the IETF are layered as 162 Network Service Models, Network Resource Models, and Network Element 163 Models. The Network Element Models are further layered into 164 Composition Models and Function Models. 166 <> 167 +-------------------------------------------------------------------------+ 168 | << Network Service Models>> | 169 | +----------------+ +----------------+ | 170 | | L3SM | | L2SM | | 171 | | Service Model | | Service Model | ............. | 172 | +----------------+ +----------------+ | 173 +------------------------------------------------------------------------ + 174 <> 175 +------------------------------------------------------------------------ + 176 | << Network Resource Models >> | 177 | +------------+ +-------+ +----------------+ +------------+ | 178 | |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | | 179 | | Models | | Models| | API Models | | OAM Models|... | 180 | +------------+ +-------+ +----------------+ +------------+ | 181 +-------------------------------------------------------------------------+ 182 -------------------------------------------------------------------------- 183 > 184 +-------------------------------------------------------------------------+ 185 | <> | 186 | +-------------+ +---------------+ +----------------+ | 187 | |Device Model | |Logical Network| |Network Instance| | 188 | | | |Element Model | | Model | ... | 189 | +-------------+ +---------------+ +----------------+ | 190 |-------------------------------------------------------------------------| 191 | << Function Models>> | 192 |+---------++---------++---------++----------++---------++---------+ | 193 || || || ||Common || || OAM: | | 194 || Routing ||Transport|| Policy ||(interface||Multicast|| | | 195 ||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | | 196 || OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ... | 197 |+---------++---------++---------++----------++---------++---------+ | 198 +-------------------------------------------------------------------------+ 200 Figure 2: An overview of Layered YANG Modules 202 A Network Service Model [RFC8309] is a kind of high level data model. 203 It describes a service and the parameters of the service in a 204 portable way that can be used uniformly and independent of the 205 equipment and operating environment. In the OPS area, the Layer 206 Three Virtual Private Network Service Model (L3SM) [RFC8299] and the 207 Layer Two Virtual Private Network Service Model (L2SM) [RFC8466] 208 define L3VPN and L2VPN services that can be ordered by a customer 209 from a network operator. In the RTG area, the Virtual Network (VN) 210 model[I-D.ietf-teas-actn-vn-yang] provides a YANG data model 211 generally applicable to any mode of VN operation. 213 The category of Network Resource Models includes topology modules and 214 tunnel modules worked on in the RTG area, as well as the resource 215 management tool models worked in both the RTG and OPS areas. 217 A Network Element model is used to describe how a service can be 218 implemented by activating and tweaking a set of functions (enabled in 219 one or multiple devices, or hosted in cloud infrastructures) that are 220 involved in the delivery of the service. This includes various 221 models for individual protocols specified in the RTG, OPS, TSV, and 222 INT areas. 224 5. Network Intelligence/Telemetry 226 It is conceivable that an intent-driven autonomic network [RFC7575] 227 is the logical next step for network evolution following Software 228 Defined Network (SDN). This approach aims to reduce (or even 229 eliminate) human labor, make the most efficient usage of network 230 resources, and provide better services more aligned with customer 231 requirements. Although it takes time to reach the ultimate goal, the 232 journey has started nevertheless. 234 Network Intelligence and Telemetry are the cornerstone for the 235 intent-driven autonomic network. 237 5.1. Network Telemetry 239 Network telemetry has emerged as a mainstream technical term to refer 240 to the newer data collection and consumption techniques, 241 distinguishing itself from the conventional techniques for network 242 OAM. Network Telemetry acquires network data remotely for network 243 monitoring and operation. It addresses the current network operation 244 issues and enables smooth evolution toward intent-driven autonomous 245 networks. 247 The Network Telemetry Framework [I-D.ietf-opsawg-ntf] provides a 248 layered categorization for the telemetry technologies developed in 249 the IETF across areas including OPS, TSV (IPPM working group), RTG 250 (MPLS and NVO3 working groups), and INT (6MAN working group). The 251 categorization is shown in Figure 3. 253 +--------------+---------------+----------------+---------------+ 254 | | Management | Control | Forwarding | 255 | | Plane | Plane | Plane | 256 +--------------+---------------+----------------+---------------+ 257 | data Config. | gRPC, NETCONF,| NETCONF/YANG | NETCONF/YANG, | 258 | & subscrib. | YANG PUSH | | YANG FSM | 259 +--------------+---------------+----------------+---------------+ 260 | data gen. & | DNP, | DNP, | In-situ OAM, | 261 | processing | YANG | YANG | PBT, IPFPM, | 262 | | | | DNP | 263 +--------------+---------------+----------------+---------------+ 264 | data | gRPC, NETCONF | BMP, NETCONF | IPFIX | 265 | export | YANG PUSH | | | 266 +--------------+---------------+----------------+---------------+ 268 Figure 3: Layer Category of Network Telemetry Framework 270 The categories shown in Figure 3 are as follows: 272 - Management Plane Telemetry: This refers to work on the push 273 extensions for NETCONF [I-D.ietf-netconf-yang-push]. This work is 274 on-going in the NETCONF working group in the OPS area. 276 - Control Plane Telemetry: BGP is a very important protocol in the 277 control plane. The GROW working group in the OPS area is developing 278 the BGP Monitoring Protocol (BMP) [RFC7854] to monitor BGP sessions 279 and to provide a convenient interface for obtaining route views. 281 - Data Plane Telemetry: In-situ Flow Information Telemetry (IFIT) 282 [I-D.song-opsawg-ifit-framework] is a new proposal that enumerates 283 several key components and describes how they could be assembled to 284 achieve a complete solution for on-path user traffic telemetry in 285 carrier networks. It includes two major modes that are described in 286 further documents: Postcard mode in 287 [I-D.song-ippm-postcard-based-telemetry] and Passport mode in 288 [I-D.ietf-ippm-ioam-data]. 289 [I-D.zhou-ippm-enhanced-alternate-marking] proposes a lightweight way 290 to achieve most measurement requirements. In general, the basic 291 mechanism is discussed in the IPPM working group in the TSV area, and 292 specific encapsulations are discussed in the working groups dedicated 293 to the associated protocols including the 6MAN working group in the 294 INT area for IPv6 and SRv6, and the MPLS and NVO3 working groups in 295 the RTG area for MPLS and VXLAN. 297 5.2. Network Intelligence 299 Thanks to advances in computing and storage technologies, today's big 300 data analytics gives network operators an unprecedented opportunity 301 to gain network insights and move toward network autonomy. Some 302 operators have started to explore the application of Artificial 303 Intelligence (AI) to make sense of network data. Software tools can 304 use the network data to detect and react to network faults, 305 anomalies, and policy violations, as well as to predict future 306 events. In turn, the network policy can be updated for planning, 307 intrusion prevention, optimization, and self-healing. 309 This topic is relatively new and requires a central place for 310 discussion. The IRTF's Network Management Research Group (NMRG) 311 recently discussed Network Intent [I-D.li-nmrg-intent-classification] 312 while [I-D.kim-nmrg-rl] presents intelligent network management 313 scenarios based on reinforcement-learning approaches. 315 6. 5G Transport 317 As work on the requirements, architecture, and protocols to support 318 5G progress, cross-area work is gaining momentum to address major 319 requirements for transport systems to underlie 5G. This includes 320 work on network slicing, deterministic latency/low latency, etc. 322 1. Network Slicing 324 Transport network slicing involves work in the IETF RTG area and the 325 INT area. In the TEAS working group in the RTG area, 326 [I-D.ietf-teas-enhanced-vpn] specifies a framework for using 327 existing, modified, and potentially new networking technologies as 328 components to provide Enhanced Virtual Private Network (VPN+) 329 services to satisfy the network slicing requirement. SR is an 330 important transport technologies for network slicing and the SPRING 331 working group is also involved. 333 The DMM WG in the INT area focuses on the mobility work involved in 334 supporting end-to-end network slicing. When considering RAN slicing 335 and Mobile Core slicing, other SDOs (such as 3GPP and the BBF) are 336 also ntvolved, interacting with each other and with the IETF via 337 liasions. 339 2. Deterministic latency/Low latency 341 The main relevant WG is Detnet which belongs to the RTG area. The 342 technologies developed in the TSV area and the ART area can also 343 provide the latency service. 345 7. Cross-layer Work 347 Layering is an important network design principle. Cross-layer work 348 often gives rise to cross-area work. 350 As ideas around network services are progressing cross-layer work is 351 as an important research are such as path-aware networking in the 352 IRTF's Path Aware Networking Research Group (PANRG), and application- 353 aware IPv6 networking proposed by 354 [I-D.li-6man-app-aware-ipv6-network]. 356 7.1. Path-Aware Networking 358 Work on the path-aware network is being done in the PANRG. The 359 Internet architecture assumes a division between the end-to-end 360 functionality of the transport layer and the properties of the path 361 between endpoints. Increased diversity in access networks, and 362 ubiquitous mobile connectivity, have made this architecture's 363 assumptions about paths less tenable. Multipath protocols taking 364 advantage of this mobile connectivity begin to show us a way forward: 365 if endpoints cannot control the path, at least they can determine the 366 properties of the path by choosing among paths available to them. 367 The PANRG aims to support research in bringing path awareness to 368 transport and application layer protocols, and to bring research in 369 this space to the attention of the Internet engineering and protocol 370 design community. 372 The group's scope overlaps with existing IETF and IRTF efforts (and 373 also with some past efforts). Of the existing overlaps, the group 374 collaborates with working groups and research groups chartered to 375 work on multipath transport protocols (MPTCP, QUIC, TSVWG), 376 congestion control in multiply-connected environments (ICCRG), and 377 alternate routing architectures (e.g., PCE and LISP). The charter is 378 also related to the questions discussed in a number of past BoF 379 sessions, e.g. SPUD, PLUS, and BANANA. 381 7.2. Application-aware IPv6 Networking 383 [I-D.li-6man-app-aware-ipv6-network] proposes possible work on 384 application-aware IPv6 networking (APN6). As the Internet continues 385 to develop, the decoupling of applications from network transport 386 causes the operation actions on service provider networks to be 387 pipelined which becomes the bottleneck of network service deployment. 388 Moreover, a multitude of applications with varying needs for network 389 bandwidth, latency, jitter, and packet loss are being carried over 390 the IP network. However it is hard for the network to learn the 391 applications' service requirements which make it difficult for an 392 operator to provide truly fine-grain traffic operations for the 393 applications and to guarantee their SLA requirements. APN6 aims to 394 make use of an IPv6 extensions header to convey the application 395 related information including its requirements along with the packet 396 to tell the network how to adjust the network resources to facilitate 397 the deployment of services. 399 The scope of the work overlaps with existing IETF and IRTF efforts 400 including, but not limited to, multiple working groups in RTG area, 401 the 6MAN working group in the INT area, and the IRTF's ICNRG and 402 PANRG. 404 8. IANA Considerations 406 This document makes no request of IANA. 408 9. Security Considerations 410 Security is a fundamental part of all work done at the IETF. At the 411 least this requires security considerations to be part of every RFC 412 published, and attention should also be given to privacy 413 requirements. This work is usually supported by reviews from 414 security experts on the Security Directorate and is a good example of 415 cross-area work. Furthermore, when major new technologies are being 416 developed within the IETF it is possible to ask for security advisors 417 to be appointed for working groups. And from time to time, new work 418 needs to be spun up in the SEC area to support demands from new 419 protocols. 421 10. References 423 10.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 10.2. Informative References 432 [I-D.ietf-ippm-ioam-data] 433 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 434 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 435 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 436 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 437 data-06 (work in progress), July 2019. 439 [I-D.ietf-netconf-yang-push] 440 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 441 draft-ietf-netconf-yang-push-25 (work in progress), May 442 2019. 444 [I-D.ietf-opsawg-ntf] 445 Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and 446 A. Wang, "Network Telemetry Framework", draft-ietf-opsawg- 447 ntf-01 (work in progress), June 2019. 449 [I-D.ietf-spring-srv6-network-programming] 450 Filsfils, C., Camarillo, P., Leddy, J., 451 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 452 Network Programming", draft-ietf-spring-srv6-network- 453 programming-01 (work in progress), July 2019. 455 [I-D.ietf-teas-actn-vn-yang] 456 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 457 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 458 teas-actn-vn-yang-06 (work in progress), July 2019. 460 [I-D.ietf-teas-enhanced-vpn] 461 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 462 Framework for Enhanced Virtual Private Networks (VPN+) 463 Service", draft-ietf-teas-enhanced-vpn-02 (work in 464 progress), July 2019. 466 [I-D.kim-nmrg-rl] 467 Kim, M., Han, Y., and Y. Hong, "Intelligent Reinforcement- 468 learning-based Network Management", draft-kim-nmrg-rl-05 469 (work in progress), July 2019. 471 [I-D.li-6man-app-aware-ipv6-network] 472 Li, Z., Peng, S., Xie, C., and L. Cong, "Application-aware 473 IPv6 Networking", draft-li-6man-app-aware-ipv6-network-00 474 (work in progress), July 2019. 476 [I-D.li-nmrg-intent-classification] 477 Li, C., Cheng, Y., Strassner, J., Havel, O., LIU, W., 478 Martinez-Julia, P., Nobre, J., and D. Lopez, "Intent 479 Classification", draft-li-nmrg-intent-classification-01 480 (work in progress), July 2019. 482 [I-D.song-ippm-postcard-based-telemetry] 483 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 484 "Postcard-based On-Path Flow Data Telemetry", draft-song- 485 ippm-postcard-based-telemetry-04 (work in progress), June 486 2019. 488 [I-D.song-opsawg-ifit-framework] 489 Song, H., Li, Z., Zhou, T., Qin, F., Shin, J., and J. Jin, 490 "In-situ Flow Information Telemetry Framework", draft- 491 song-opsawg-ifit-framework-03 (work in progress), July 492 2019. 494 [I-D.wu-model-driven-management-virtualization] 495 Wu, Q., Boucadair, M., Jacquenet, C., Contreras, L., 496 Lopez, D., Xie, C., Cheng, W., and Y. Lee, "A Framework 497 for Automating Service and Network Management with YANG", 498 draft-wu-model-driven-management-virtualization-05 (work 499 in progress), July 2019. 501 [I-D.zhou-ippm-enhanced-alternate-marking] 502 Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and 503 Z. Li, "Enhanced Alternate Marking Method", draft-zhou- 504 ippm-enhanced-alternate-marking-03 (work in progress), 505 July 2019. 507 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 508 the Network Configuration Protocol (NETCONF)", RFC 6020, 509 DOI 10.17487/RFC6020, October 2010, 510 . 512 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 513 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 514 Networking: Definitions and Design Goals", RFC 7575, 515 DOI 10.17487/RFC7575, June 2015, 516 . 518 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 519 Monitoring Protocol (BMP)", RFC 7854, 520 DOI 10.17487/RFC7854, June 2016, 521 . 523 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 524 Classification", RFC 8199, DOI 10.17487/RFC8199, July 525 2017, . 527 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 528 (IPv6) Specification", STD 86, RFC 8200, 529 DOI 10.17487/RFC8200, July 2017, 530 . 532 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 533 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 534 DOI 10.17487/RFC8299, January 2018, 535 . 537 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 538 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 539 . 541 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 542 Data Model for Layer 2 Virtual Private Network (L2VPN) 543 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 544 2018, . 546 Author's Address 548 Zhenbin Li 549 Huawei Technologies 550 Huawei Bld., No.156 Beiqing Rd. 551 Beijing 100095 552 China 554 Email: lizhenbin@huawei.com