Network Working Group Z. Li
Internet-Draft Huawei Technologies
Intended status: Informational July 26, 2019
Expires: January 27, 2020
Cross-Area Work in the IETF
draft-li-cross-area-ietf-work-00
Abstract
This document investigates the benefits of cross-area work in the
IETF. It is examines existing cross-area work and identifies other
possibilities for work that spans more than one area. The intention
is to help community members who focus their work within a specific
area to understand related work in other areas and to motivate
efficient cooperation across different areas in the 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 27, 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
Li Expires January 27, 2020 [Page 1]
Internet-Draft Cross-Area IETF Work July 2019
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Network Intelligence/Telemetry . . . . . . . . . . . . . . . 6
5.1. Network Telemetry . . . . . . . . . . . . . . . . . . . . 6
5.2. Network Intelligence . . . . . . . . . . . . . . . . . . 8
6. 5G Transport . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Cross-layer Work . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
With the development of new network technologies such as cloud
computing, 5G, IoT, etc., very many applications are carried over the
network. Each has different needs for network bandwidth, latency,
jitter, and packet loss, etc.
Work in the IETF is divided into Areas. The demands of the new
technologies motivates innovation and new architectures in multiple
network layers, and resulting cross-area work is increasing in the
IETF. Existing protocol practice shows that people who focus on one
specific area are sometimes not aware of related work in different
areas. Some cross-area work is not recognized until late in the
lifecycle so that useful experiences cannot be shared early in the
development. Fixing problems that are identified late can become
time consuming.
This document investigates the benefits of cross-area work in the
IETF. It is examines existing cross-area work and identifies other
possibilities for work that spans more than one area. The intention
Li Expires January 27, 2020 [Page 2]
Internet-Draft Cross-Area IETF Work July 2019
is to help community members who focus their work within a specific
area to understand related work in other areas and to motivate
efficient cooperation across different areas in the IETF.
2. Terminology
SRv6: Segment Routing over IPv6
MPLS: Multi-Protocol Label Switch
3. SRv6
Segment Routing is an important networking technology developed in
the 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 SRv6 network. The
related areas and Working Groups for SRv6 are shown in Figure 1: the
work 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 IETF areas for SRv6 work are the RTG area and the INT area.
There is work in multiple working groups 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.
Li Expires January 27, 2020 [Page 3]
Internet-Draft Cross-Area IETF Work July 2019
4. YANG Models
Data models written in the YANG modelling language [RFC6020] can be
used for service and network management to provide a programmatic
approach for representing (virtual) services or networks and for
deriving configuration information that will be forwarded to 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.
Figure 2 is from [I-D.wu-model-driven-management-virtualization]
provides and 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 the IETF are layered as
Network Service Models, Network Resource Models, and Network Element
Models. The Network Element Models are further layered into
Composition Models and Function Models.
Li Expires January 27, 2020 [Page 4]
Internet-Draft Cross-Area IETF 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
A 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 the OPS area, the Layer
Three Virtual Private Network Service Model (L3SM) [RFC8299] and the
Layer Two Virtual Private Network Service Model (L2SM) [RFC8466]
define L3VPN and L2VPN services that can be ordered by a customer
from a network operator. In the RTG area, the Virtual Network (VN)
model[I-D.ietf-teas-actn-vn-yang] provides a YANG data model
generally applicable to any mode of VN operation.
Li Expires January 27, 2020 [Page 5]
Internet-Draft Cross-Area IETF Work July 2019
The category of Network Resource Models includes topology modules and
tunnel modules worked on in the RTG area, as well as the resource
management tool models worked in both the RTG and OPS areas.
A 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 delivery of the service. This includes various
models for individual protocols specified in the RTG, OPS, TSV, and
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). This approach aims 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 conventional 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.
The Network Telemetry Framework [I-D.ietf-opsawg-ntf] provides a
layered categorization for the telemetry technologies developed in
the IETF across areas including OPS, TSV (IPPM working group), RTG
(MPLS and NVO3 working groups), and INT (6MAN working group). The
categorization is shown in Figure 3.
Li Expires January 27, 2020 [Page 6]
Internet-Draft Cross-Area IETF 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
The categories shown in Figure 3 are as follows:
- Management Plane Telemetry: This refers to 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: BGP is a very important protocol in the
control plane. The GROW working group in the OPS area is developing
the BGP Monitoring Protocol (BMP) [RFC7854] to monitor BGP sessions
and to provide a convenient interface for obtaining route views.
- Data Plane Telemetry: In-situ Flow Information Telemetry (IFIT)
[I-D.song-opsawg-ifit-framework] is a new proposal that enumerates
several key components and describes how they could be assembled to
achieve a complete solution for on-path user traffic telemetry in
carrier networks. It includes two major modes that are described in
further documents: Postcard mode in
[I-D.song-ippm-postcard-based-telemetry] and Passport mode in
[I-D.ietf-ippm-ioam-data].
[I-D.zhou-ippm-enhanced-alternate-marking] proposes a lightweight way
to achieve most measurement requirements. In general, the basic
mechanism is discussed in the IPPM working group in the TSV area, and
specific encapsulations are discussed in the working groups dedicated
to the associated protocols including the 6MAN working group in the
INT area for IPv6 and SRv6, and the MPLS and NVO3 working groups in
the RTG area for MPLS and VXLAN.
Li Expires January 27, 2020 [Page 7]
Internet-Draft Cross-Area IETF Work July 2019
5.2. Network Intelligence
Thanks to advances in computing and storage technologies, today's big
data analytics gives network operators an unprecedented opportunity
to gain network insights and move toward network autonomy. Some
operators have started to explore the application of Artificial
Intelligence (AI) to make sense of network data. Software tools can
use the network data to detect and react to network faults,
anomalies, and policy violations, as well as to predict future
events. In turn, the network policy can be updated for planning,
intrusion prevention, optimization, and self-healing.
This topic is relatively new and requires a central place for
discussion. The IRTF's Network Management Research Group (NMRG)
recently discussed Network Intent [I-D.li-nmrg-intent-classification]
while [I-D.kim-nmrg-rl] presents intelligent network management
scenarios based on reinforcement-learning approaches.
6. 5G Transport
As work on the requirements, architecture, and protocols to support
5G progress, cross-area work is gaining momentum to address major
requirements for transport systems to underlie 5G. This includes
work on network slicing, deterministic latency/low latency, etc.
1. Network Slicing
Transport network slicing involves work in the IETF RTG area and the
INT area. In the TEAS working group in the RTG area,
[I-D.ietf-teas-enhanced-vpn] specifies a framework for using
existing, modified, and potentially new networking technologies as
components to provide Enhanced Virtual Private Network (VPN+)
services to satisfy the network slicing requirement. SR is an
important transport technologies for network slicing and the SPRING
working group is also involved.
The DMM WG in the INT area focuses on the mobility work involved in
supporting end-to-end network slicing. When considering RAN slicing
and Mobile Core slicing, other SDOs (such as 3GPP and the BBF) are
also ntvolved, interacting with each other and with the IETF 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.
Li Expires January 27, 2020 [Page 8]
Internet-Draft Cross-Area IETF Work July 2019
7. Cross-layer Work
Layering is an important network design principle. Cross-layer work
often gives rise to cross-area work.
As ideas around network services are progressing cross-layer work is
as an important research are such as path-aware networking in the
IRTF's Path Aware Networking Research Group (PANRG), and application-
aware IPv6 networking proposed by
[I-D.li-6man-app-aware-ipv6-network].
7.1. Path-Aware Networking
Work on the path-aware network is being done in the PANRG. The
Internet architecture assumes a division between the end-to-end
functionality of the transport layer and the properties of the path
between 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:
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
collaborates with working groups and research groups chartered to
work on multipath transport protocols (MPTCP, QUIC, TSVWG),
congestion control in multiply-connected environments (ICCRG), and
alternate routing architectures (e.g., PCE and LISP). The charter is
also related to the questions discussed in a number of past BoF
sessions, e.g. SPUD, PLUS, and BANANA.
7.2. Application-aware IPv6 Networking
[I-D.li-6man-app-aware-ipv6-network] proposes possible work on
application-aware IPv6 networking (APN6). As the Internet continues
to develop, the decoupling of applications from network transport
causes the operation actions on service provider networks to be
pipelined which becomes the bottleneck of network service deployment.
Moreover, a multitude of applications with varying needs for network
bandwidth, latency, jitter, and packet loss are being carried over
the IP network. However it is hard for the network to learn the
applications' service requirements which make it difficult for an
operator to provide truly fine-grain traffic operations for the
Li Expires January 27, 2020 [Page 9]
Internet-Draft Cross-Area IETF Work July 2019
applications and to guarantee their SLA requirements. APN6 aims to
make use of an IPv6 extensions header to convey the application
related information including its requirements along with the packet
to tell the network how to adjust the network resources to facilitate
the deployment of services.
The scope of the work overlaps with existing IETF and IRTF efforts
including, but not limited to, multiple working groups in RTG area,
the 6MAN working group in the INT area, and the IRTF's ICNRG and
PANRG.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
Security is a fundamental part of all work done at the IETF. At the
least this requires security considerations to be part of every RFC
published, and attention should also be given to privacy
requirements. This work is usually supported by reviews from
security experts on the Security Directorate and is a good example of
cross-area work. Furthermore, when major new technologies are being
developed within the IETF it is possible to ask for security advisors
to be appointed for working groups. And from time to time, new work
needs to be spun up in the SEC area to support demands from new
protocols.
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.
Li Expires January 27, 2020 [Page 10]
Internet-Draft Cross-Area IETF Work 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.
[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., LIU, W.,
Martinez-Julia, P., Nobre, J., and D. Lopez, "Intent
Classification", draft-li-nmrg-intent-classification-01
(work in progress), July 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.
Li Expires January 27, 2020 [Page 11]
Internet-Draft Cross-Area IETF Work July 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-03 (work in progress), July
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.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
Li Expires January 27, 2020 [Page 12]
Internet-Draft Cross-Area IETF Work July 2019
[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 27, 2020 [Page 13]