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