Blog
Hello! I’m Hirochika Asai, working as a researcher at Preferred Networks (PFN). I joined PFN from this April. Today, I briefly report the 99th meeting of the Internet Engineering Task Force (IETF) (IETF 99) in this post. I participated in IETF 99, held at Hilton Prague, Prague, Czech. It was the first attendance to the IETF meetings from PFN.
First of all, I introduce general information about the IETF and its meetings. The IETF is an open and voluntary community that develops Internet standards. According to the statement of the IETF [1];
The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
The IETF standards are published as Request for Comments (RFC). RFCs can be categorized into two categories, standards track and non-standards track. Standards track RFCs are classified as Proposed Standard, Draft Standard, or Internet Standard. Non-standards track RFCs are either of Informational, Experimental, or Historic. The details of the standardization process are summarized in RFC 2026 [2]. Internet Standard is the final state of standards-track RFCs. However, it is a long journey to be Internet Standard from Proposed Standard. For example, Internet Protocol version 6 (IPv6) was first published as Proposed Standard in RFC 1883 [3] in 1995, and was eventually published as Internet Standard in RFC 8200 [4] in 2017. It took more than twenty years! Here, as an aside, joke RFCs, such as “IP over avian carriers” [RFC 1149], that some of you may have heard are non-standards track RFCs because they have not passed the process for standards track.
The IETF holds three meetings a year; generally once in North America, once in Europe, and once in Asia, each of which consists of one-day tutorial and five-day 5–8 parallel track working group (WG) sessions. The IETF does not require any membership. Therefore, each participant attends the meetings as an individual, although they are generally funded by their employers, organizations, or sponsors. In the meetings, the IETF takes the rough consensus basis for decision making. One of the symbolic phrases in the IETF is:
We reject kings, presidents and voting. We believe in rough consensus and running code. –– David D. Clark
The IETF does not take a vote on any actions of decision making. Instead, “humming” has been used to get consensus of the community. WG chairs would ask the attendees to hum if they are affirmative/negative (or any other actions) to a certain proposal or a request. WG chairs decide whether the proposal or request gets consensus or not from the volume of humming. They never count the number of people humming. This is why the decision making process in the IETF is called rough consensus.
IETF 99 had 1860 registrations including remote participation, and 1231 attendees showed up on site. Many discussions have been made during IETF 99. Here, I’ll take a look at one of the meeting slots, Operations and Management Area Working Group (OPSAWG) joint meeting with Operations and Management Area (OPSAREA). I focus on it because they have been my main field. Ten items have been presented in this meeting. The following is the list of the presented items in this two-hour slot of the meeting.
- Joe Clarke, yangcatalog.org development
- Benoit Claise, How the IETF needs to evolve
- Richard Barnes, Semantic Versioning and Structure for IETF Specifications
- Eliot Lear, Manufacturer Usage Description Specification
- Qin Wu, Service Models Explained
- Zhenqiang Li, Export BGP community information in IPFIX
- Zhenqiang Li, Extended Length Message Support for IPFIX
- Haoyu Song, Requirements for Interactive Query with Dynamic Network Probes
- Mohamed Boucadair, YANG Data Model for NAT
- Nicola Sambo, Extending YANG for events, actions, and finite state machine
Six items out of these ten are on YANG models, while two are about extensions of the IP Flow Information Export (IPFIX) protocol. YANG is a data modeling language collectively used over NETCONF, which is a network configuration protocol. Network devices had been configured via command line interfaces (CLIs) for long years. Therefore, it had been hard to achieve automation of network operations. Although, a protocol and data models to operate network devices, called Simple Network Management Protocol (SNMP) and Management Information Base (MIB), have been used to collect statistical data from network devices, any actions from the collected data had been generally performed not via SNMP/MIB but by operators. Moreover, back in 2014, the Internet Engineering Steering Group (IESG) announced the statement [5] that recommended to switch writable MIB to NETCONF/YANG. YANG has been promoted since then. In addition to this background, automation of network operations has recently been emphasized. Thus, YANG is one of the main topics of OPSAWG/OPSAREA.
As an example of YANG models, the following is part of the YANG model for interface management defined in RFC 7223:
module ietf-interfaces {
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
import ietf-yang-types {
prefix yang;
}
container interfaces {
description
"Interface configuration parameters.";
list interface {
key "name";
leaf name {
type string;
description "...";
}
leaf description {
type string;
description "...";
}
}
}
}
}
A data model is defined as a module with namespace. This part of the YANG model defines the list of interfaces in the container named “interfaces” with the attributes of an interface such “name” and “description”. The attributes of “name” and “description” are represented as string.
This YANG model is derived from the MIB module for interface groups is defined in RFC 2863:
IF-MIB DEFINITIONS ::= BEGIN --- IMPORTS snipped... ifMIB MODULE-IDENTITY ::= { mib-2 31 } ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { interfaces 2 } ifEntry OBJECT-TYPE SYNTAX IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { ifIndex } ::= { ifTable 1 } IfEntry ::= SEQUENCE { ifIndex InterfaceIndex, ifDescr DisplayString } ifIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { ifEntry 1 } ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { ifEntry 2 } END
Although YANG is more sophisticated than MIB, they have some similarity. One major difference between YANG and MIB is that YANG allows to have lists in a list, while MIB does not allow tables in a table. This is because MIB modules represent the hierarchy by numerical object identifiers (OIDs) including table indices.
One interesting proposal on YANG models in this meeting was presented by Joe Clarke. As the number of YANG models has been growing up, it is essential to implement some mechanisms that users easily search, browse, and validate YANG models. He and other volunteers implemented a repository of YANG models, yangcatalog.org, in the hackathon event held on the day before the IETF meeting.
Another majority of OPSAWG/OPSAREA was about IPFIX. Zhengjang Li proposed an extension to export BGP community information in IPFIX. Since the community information might exceed the allowed size of IPFIX messages, he also proposed to update the IPFIX message format to support larger packets.
In this way, many proposals have been discussed in the IETF meetings to make the Internet work better. From the PFN’s viewpoint, the Internet is a key technology. Obviously, the Internet is the indispensable infrastructure for Edge Heavy Computing. In addition, PFN aims at automation of the network operations and management using machine learning. I think OPSAWG/OPSAREA is the right place to work such automation techniques as NETCONF/YANG is one of the interfaces between network devices and the automation platform. Therefore, I’ll keep my eyes on this WG as well as other related WGs such as Network Management Research Group and (Proposed) Intelligence-Defined Network WG.
Yet another mission of mine in the IETF is building and operating the network of the IETF meeting. I have worked for the network operation center (NOC) of the IETF meetings since IETF 90 in 2014. This meeting was my tenth meeting as a NOC volunteer. I’m responsible for the meeting wireless infrastructure there. We came into the meeting venue one week before the meeting commenced, and setup and deployed our network devices including routers, switches, and wireless access points so that attendees could work and achieve high productivity from the first day of the meeting. Here’s a photo of our wireless access points, baby switches, and cables before their deployment.
Wireless access points, baby switches, and cables to be deployed in the meeting space.
Our NOC work was reported by IAD/IAOC in the IETF plenary session as shown in the photo attached below. I’m so happy to work with the skilled professionals in this best team. It was great time for me. However, real network operations are sometimes daunting. In particular, troubleshooting of our system and optimization of wireless infrastructure always take our time. I would really like to contribute the network operations and management community by developing automation techniques and make the Internet work better.
NOC Members reported by IAD/IAOC in the IETF plenary session.
Next meeting, IETF 100, will be held from November 11th to 17th, 2017, in Singapore.
References
[1] https://ietf.org/
[2] S. Bradner, “The Internet Standards Process – Revision 3,” RFC 2026 (BCP 9), 1996
[3] S. Deering et al, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 1883, 1995
[4] S. Deering et al, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 8200, 2017
[5] https://www.ietf.org/iesg/statement/writable-mib-module.html
Area
Tag
