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]
