Internet DRAFT - draft-li-cross-ietf-area-work

draft-li-cross-ietf-area-work






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>>
+-------------------------------------------------------------------------+
| << Network Service Models>>                                             |
| +----------------+ +----------------+                                   |
| |      L3SM      | |     L2SM       |                                   |
| |  Service Model | |  Service Model |          .............            |
| +----------------+ +----------------+                                   |
+------------------------------------------------------------------------ +
  <<Network Resource Models>>
+------------------------------------------------------------------------ +
| << Network Resource Models >>                                           |
|      +------------+  +-------+  +----------------+   +------------+     |
|      |Network Topo|  | Tunnel|  |Path Computation|   |FM/PM/Alarm |     |
|      |   Models   |  | Models|  | API Models     |   | OAM  Models|...  |
|      +------------+  +-------+  +----------------+   +------------+     |
+-------------------------------------------------------------------------+
 --------------------------------------------------------------------------
 <Network Element Models>>
+-------------------------------------------------------------------------+
|  <<Composition 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,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.

   [RFC8199]  Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
              Classification", RFC 8199, DOI 10.17487/RFC8199, July
              2017, <https://www.rfc-editor.org/info/rfc8199>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [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,
              <https://www.rfc-editor.org/info/rfc8299>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

   [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, <https://www.rfc-editor.org/info/rfc8466>.

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]