Network Working Group Z. Li Internet-Draft Huawei Technologies Intended status: Informational July 8, 2019 Expires: January 9, 2020 Cross-Area Work in IETF draft-li-cross-ietf-area-work-00 Abstract This document investigates the possible existing cross-area work in IETF. It is expected to help the community members who focus on the specific area to understand more related work in other areas and motivate efficient cooperation across different areas in IETF. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Li Expires January 9, 2020 [Page 1] Internet-Draft IETF Cross-Area Work July 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Network Intelligence/Telemetry . . . . . . . . . . . . . . . 6 5.1. Network Telemetry . . . . . . . . . . . . . . . . . . . . 6 5.2. Network Intelligence . . . . . . . . . . . . . . . . . . 7 6. 5G Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Cross-layer Work . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Path-Aware Networking . . . . . . . . . . . . . . . . . . 9 7.2. Application-aware IPv6 Networking . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction As the development of new network technologies such as cloud computing, 5G, IoT, etc., multitudes of applications are carried over the network, which have various needs for network bandwidth, latency, jitter, and packet loss, etc. This motivates innovation and design in multiple network layers and the cross-area work is increasing in IETF. Existing protocol practice shows people who focus on the specific area traditionally are sometimes not aware of related work in different areas. Some cross-area work is recognized late in the lifecycle so that useful experiences cannot be shared at the early time. Fixing problems become time consuming. This document investigates the possible existing cross-area work in IETF. It is expected to help the community members who focus on the specific area to understand more related work in other areas and motivate efficient cooperation across different areas in IETF. Li Expires January 9, 2020 [Page 2] Internet-Draft IETF Cross-Area Work July 2019 2. Terminology SRv6: Segment Routing over IPv6 MPLS: Multi-Protocol Label Switch 3. SRv6 Segment Routing is an important network transport technologies developed in IETF. SRv6 is the Segment Routing deployed on the IPv6 data plane[RFC8200] and SRv6 network programming [I-D.ietf-spring-srv6-network-programming] is introduced to support multiple services which have requirements on the new encapsulation for the IPv6 extensions header. The related areas and WGs for SRv6 is shown in Figure 1 and can be categorized into Basics, Encapsulations, Protocols, YANG, Use cases, and Others. --------------------------- SRv6 ---------------------------- | | | | | | | | | | | | +------+ +------+ +---------+ +-----+ +---------+ +------+ |Basics| |Encaps| |Protocols| |YANG | |Use Cases| |Others| +------+ +------+ +---------+ +-----+ +---------+ +------+ | | | | | | RTG SPRING DETNET LSR YANG DETNET BFD BIER BESS TEAS RTGWG IDR SFC PCE BIER INT 6MAN 6LO LPWAN Figure 1: Related Areas/WGs for SRv6 The major areas for SRv6 includes RTG area and INT area. There is multiple work in the RTG area and the major work in the INT area includes the new IPv6 encapsulation and the possible compression work on the IPv6 header. 4. YANG Models YANG data models for service and network management provides a programmatic approach for representing (virtual) services or networks and deriving configuration information that will be forwarded to Li Expires January 9, 2020 [Page 3] Internet-Draft IETF Cross-Area Work July 2019 network and service components that are used to build and deliver the service. YANG module developers have taken both top-down and bottom-up approaches to develop modules [RFC8199] and to establish a mapping between network technology and customer requirements on the top or abstracting common construct from various network technologies on the bottom. There are many data models including configuration and service models that have been specified or are being specified by the IETF. They cover many of the networking protocols and techniques. In Figure 1 [I-D.wu-model-driven-management-virtualization] provides an overview of various macro-functional blocks at different levels that articulate the various YANG data modules. In this figure, example models developed in IETF are layered as Network Service Models, Network Resource Models and Network Element Models. Li Expires January 9, 2020 [Page 4] Internet-Draft IETF Cross-Area Work July 2019 <> +-------------------------------------------------------------------------+ | << Network Service Models>> | | +----------------+ +----------------+ | | | L3SM | | L2SM | | | | Service Model | | Service Model | ............. | | +----------------+ +----------------+ | +------------------------------------------------------------------------ + <> +------------------------------------------------------------------------ + | << Network Resource Models >> | | +------------+ +-------+ +----------------+ +------------+ | | |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | | | | Models | | Models| | API Models | | OAM Models|... | | +------------+ +-------+ +----------------+ +------------+ | +-------------------------------------------------------------------------+ -------------------------------------------------------------------------- > +-------------------------------------------------------------------------+ | <> | | +-------------+ +---------------+ +----------------+ | | |Device Model | |Logical Network| |Network Instance| | | | | |Element Model | | Model | ... | | +-------------+ +---------------+ +----------------+ | |-------------------------------------------------------------------------| | << Function Models>> | |+---------++---------++---------++----------++---------++---------+ | || || || ||Common || || OAM: | | || Routing ||Transport|| Policy ||(interface||Multicast|| | | ||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | | || OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ... | |+---------++---------++---------++----------++---------++---------+ | +-------------------------------------------------------------------------+ Figure 2: An overview of Layered YANG Modules Network Service Model [RFC8309] is a kind of high level data model. It describes a service and the parameters of the service in a portable way that can be used uniformly and independent of the equipment and operating environment. In OPS area L3SM [RFC8299] and L2SM [RFC8466] define the L3VPN and L2VPN service ordered by a customer from a network operator. In RTG area, VN model [I-D.ietf-teas-actn-vn-yang] provides a YANG data model generally applicable to any mode of Virtual Network (VN) operation. Network Resource Model includes topology modules and tunnel modules worked in RTG area, as well as the resource management tool models worked in both RTG and OPS area. Li Expires January 9, 2020 [Page 5] Internet-Draft IETF Cross-Area Work July 2019 Network Element model is used to describe how a service can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. This includes various models for individual protocols specified in RTG, OPS, TSV, INT areas. 5. Network Intelligence/Telemetry It is conceivable that an intent-driven autonomic network [RFC7575] is the logical next step for network evolution following Software Defined Network (SDN), aiming to reduce (or even eliminate) human labor, make the most efficient usage of network resources, and provide better services more aligned with customer requirements. Although it takes time to reach the ultimate goal, the journey has started nevertheless. Network Intelligence and Telemetry are the cornerstone for the intent-driven autonomic network. 5.1. Network Telemetry Network telemetry has emerged as a mainstream technical term to refer to the newer data collection and consumption techniques, distinguishing itself from the convention techniques for network OAM. Network Telemetry acquires network data remotely for network monitoring and operation. It addresses the current network operation issues and enables smooth evolution toward intent-driven autonomous networks. Network Telemetry Framework [I-D.ietf-opsawg-ntf] provide a layered category for the telemetry technologies developed in IETF across areas including OPS, TSV (IPPM), RTG(MPLS/VXLAN), INT(6MAN), etc. Li Expires January 9, 2020 [Page 6] Internet-Draft IETF Cross-Area Work July 2019 +--------------+---------------+----------------+---------------+ | | Management | Control | Forwarding | | | Plane | Plane | Plane | +--------------+---------------+----------------+---------------+ | data Config. | gRPC, NETCONF,| NETCONF/YANG | NETCONF/YANG, | | & subscrib. | YANG PUSH | | YANG FSM | +--------------+---------------+----------------+---------------+ | data gen. & | DNP, | DNP, | In-situ OAM, | | processing | YANG | YANG | PBT, IPFPM, | | | | | DNP | +--------------+---------------+----------------+---------------+ | data | gRPC, NETCONF | BMP, NETCONF | IPFIX | | export | YANG PUSH | | | +--------------+---------------+----------------+---------------+ Figure 3: Layer Category of Network Telemetry Framework - Management Plane Telemetry: The management plane telemetry mainly refers work on the push extensions for NETCONF [I-D.ietf-netconf-yang-push]. This work is on going in the NETCONF working group in the OPS area. - Control Plane Telemetry: On the control plane, BGP is a very important protocol. GROW working group in the OPS area is now developing the BGP Monitoring Protocol (BMP) [RFC7854] to monitor BGP sessions and intended to provide a convenient interface for obtaining route views. - Data Plane Telemetry: In-situ Flow Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] enumerates several key components and describes how these components are assembled to achieve a complete working solution for on-path user traffic telemetry in carrier networks. It includes two major modes: Postcard mode [I-D.song-ippm-postcard-based-telemetry] and Passport mode [I-D.ietf-ippm-ioam-data]. [I-D.zhou-ippm-enhanced-alternate-marking] also provides a light weight way to achieve most measurement requirements. In general, the basic mechanism is discussed in IPPM working group in TSV area, and the specific encapsulations are discussed in the transport protocol related working groups including 6MAN WG in the INT area and MPLS/ VXLAN in the RTG area, 5.2. Network Intelligence Thanks to the advance of the computing and storage technologies, today's big data analytics gives network operators an unprecedented opportunity to gain network insights and move towards network autonomy. Some operators start to explore the application of Li Expires January 9, 2020 [Page 7] Internet-Draft IETF Cross-Area Work July 2019 Artificial Intelligence (AI) to make sense of network data. Software tools can use the network data to detect and react on network faults, anomalies, and policy violations, as well as predicting future events. In turn, the network policy updates for planning, intrusion prevention, optimization, and self-healing may be applied. This is relatively new and requires central controller. In NMRG Network Intent [I-D.li-nmrg-intent-classification] was discussed. Recently, [I-D.kim-nmrg-rl] presents intelligent network management scenarios based on reinforcement-learning approaches. 6. 5G Transport As the 5G is progressing, the cross-area work is being done for the major requirement including network slicing, deterministic latency/ low latency, etc. 1. Network Slicing The transport network slicing involves the IETF RTG area and the INT area. In the RTG area [I-D.ietf-teas-enhanced-vpn] specifies a framework for using existing, modified and potential new networking technologies as components to provide an Enhanced Virtual Private Networks (VPN+) services to satisfy the network slicing requirement. SR is an important transport technologies for network slicing and the SPRING WG is involved. For the end-to-end network slicing, the DMM WG in the INT area focuses on the mobility work is involved. When considering the RAN slicing and Mobile core slicing, the SDOs such as 3GPP and BBF are also interact with each other via liasions. 2. Deterministic latency/Low latency The main relevant WG is Detnet which belongs to the RTG area. The technologies developed in the TSV area and the ART area can also provide the latency service. 7. Cross-layer Work Cross-layer work is part of the cross-area work. Layering is an important network design principle. However, as the network services are progressing cross-layer work is emerging such as the path-aware networking in PANRG and the application-aware IPv6 networking proposed by [I-D.li-6man-app-aware-ipv6-network]. Li Expires January 9, 2020 [Page 8] Internet-Draft IETF Cross-Area Work July 2019 7.1. Path-Aware Networking The work on the path-aware network is being done in PANRG. The Internet architecture assumes a division between the end-to-end functionality of the transport layer and the properties of the path between the endpoints. Increased diversity in access networks, and ubiquitous mobile connectivity, have made this architecture's assumptions about paths less tenable. Multipath protocols taking advantage of this mobile connectivity begin to show us a way forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available to them. The PANRG aims to support research in bringing path awareness to transport and application layer protocols, and to bring research in this space to the attention of the Internet engineering and protocol design community. The group's scope overlaps with existing IETF and IRTF efforts (and also with some past efforts. Of the existing overlaps, the group will collaborate with WGs and RGs chartered to work on multipath transport protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments (ICCRG), and alternate routing architectures (e.g. LISP). The charter is also related to the questions discussed in a number of past BoF sessions, e.g. SPUD, PLUS, BANANA). 7.2. Application-aware IPv6 Networking [I-D.li-6man-app-aware-ipv6-network] proposes the possible work on the application-aware IPv6 networking (APN6). As the Internet is progressing, the decoupling of applications and network transport causes the service provider network pipelined which becomes the bottleneck of the network service development. Moreover a multitude of applications are being carried over the IP network which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. However the network is hard to learn the applications' service requirements which cause it is difficult to provide truly fine-granular traffic operations for the applications and guarantee their SLA requirements. The Application-aware IPv6 Networking is to make use of IPv6 extensions header to convey the application related information including its requirements along with the packet to the network so to facilitate the service deployment and network resources adjustment. The scope of the work overlaps with existing IETF and IRTF efforts includes but not limited to multiple WGs in the RTG area, 6MAN in the INT area, ICNRG, PANRG, etc. Li Expires January 9, 2020 [Page 9] Internet-Draft IETF Cross-Area Work July 2019 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations This document makes no request of security. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-06 (work in progress), July 2019. [I-D.ietf-netconf-yang-push] Clemm, A. and E. Voit, "Subscription to YANG Datastores", draft-ietf-netconf-yang-push-25 (work in progress), May 2019. [I-D.ietf-opsawg-ntf] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", draft-ietf-opsawg- ntf-01 (work in progress), June 2019. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network- programming-01 (work in progress), July 2019. [I-D.ietf-teas-actn-vn-yang] Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Yoon, "A Yang Data Model for VN Operation", draft-ietf- teas-actn-vn-yang-06 (work in progress), July 2019. Li Expires January 9, 2020 [Page 10] Internet-Draft IETF Cross-Area Work July 2019 [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Networks (VPN+) Service", draft-ietf-teas-enhanced-vpn-02 (work in progress), July 2019. [I-D.kim-nmrg-rl] Kim, M., Han, Y., and Y. Hong, "Intelligent Reinforcement- learning-based Network Management", draft-kim-nmrg-rl-05 (work in progress), July 2019. [I-D.li-6man-app-aware-ipv6-network] Li, Z., Peng, S., Xie, C., and L. Cong, "Application-aware IPv6 Networking", draft-li-6man-app-aware-ipv6-network-00 (work in progress), July 2019. [I-D.li-nmrg-intent-classification] Li, C., Cheng, Y., Strassner, J., Havel, O., Xu, W., and W. LIU, "Intent Classification", draft-li-nmrg-intent- classification-00 (work in progress), April 2019. [I-D.song-ippm-postcard-based-telemetry] Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path Flow Data Telemetry", draft-song- ippm-postcard-based-telemetry-04 (work in progress), June 2019. [I-D.song-opsawg-ifit-framework] Song, H., Li, Z., Zhou, T., Qin, F., Shin, J., and J. Jin, "In-situ Flow Information Telemetry Framework", draft- song-opsawg-ifit-framework-02 (work in progress), June 2019. [I-D.wu-model-driven-management-virtualization] Wu, Q., Boucadair, M., Jacquenet, C., Contreras, L., Lopez, D., Xie, C., Cheng, W., and Y. Lee, "A Framework for Automating Service and Network Management with YANG", draft-wu-model-driven-management-virtualization-05 (work in progress), July 2019. [I-D.zhou-ippm-enhanced-alternate-marking] Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and Z. Li, "Enhanced Alternate Marking Method", draft-zhou- ippm-enhanced-alternate-marking-03 (work in progress), July 2019. Li Expires January 9, 2020 [Page 11] Internet-Draft IETF Cross-Area Work July 2019 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . Author's Address Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li Expires January 9, 2020 [Page 12]