Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)
draft-ietf-ippm-ioam-data-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Al Morton <acm@research.att.com>, The IESG <iesg@ietf.org>, acm@research.att.com, draft-ietf-ippm-ioam-data@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Data Fields for In-situ OAM' to Proposed Standard (draft-ietf-ippm-ioam-data-17.txt)

The IESG has approved the following document:
- 'Data Fields for In-situ OAM'
  (draft-ietf-ippm-ioam-data-17.txt) as Proposed Standard

This document is the product of the IP Performance Measurement Working Group.

The IESG contact persons are Zaheduzzaman Sarker and Martin Duke.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/

Ballot Text

Technical Summary

   This memo describes a specific type of OAM capability intended to 
   operate within a network domain, and complements traditional 
   measurement tools for connectivity and route discovery (such as ping 
   and traceroute). This form is called In-situ-OAM, and the techniques 
   employed fall in the RFC 7799 category of Hybrid Type I (as a 
   combination of Active measurement using synthetic traffic and pure 
   Passive observations of user traffic, by adding measurement-specific 
   information to user traffic).  Packets with In-situ OAM encapsulation 
   record information as they traverse nodes within a specific network 
   domain. This information includes timestamps, identification of 
   interfaces, and other details that can assist with OAM activities 
   which include new ones, such as proof of transit (exactly which 
   nodes/interfaces were visited). The IOAM encapsulation will be added/
   removed at domain ingress/egress, may be added to all or a subset of 
   packets, and updated at all or a subset of transit nodes. IOAM 
   Namespaces provide another dimension of flexibility for actions. This 
   memo will be used a as a reference for additional RFCs that specify 
   encapsulations in a variety of protocols, such as Segment Routing, 
   Geneve, or IPv6.

Working Group Summary

   This work topic & proposal was bounced-around a bit before finding an 
   appropriate home in Transport Area and IPPM WG.

   Many of the details of IOAM data fields and operations were discussed 
   at length on e-mail and debated at side meetings. Further the 
   development used GitHub's capabilities to track issues and the 
   discussion to resolve each item.
   https://github.com/inband-oam/ietf/pulls?q=is%3Apr+is%3Aclosed

Document Quality

   This document provides a data model that will be used by various 
   encapsulations. One of these encapsulations (IPv6 options)  is 
   already adopted by IPPM and another (Geneve) is an individual draft.

Personnel

   The shepherd is Al Morton. The Responsible AD is Martin Duke.
   
   The IANA Experts for the registries in this document are Frank 
   Brockners <fbrockne@cisco.com> and Tal Mizrahi 
   <tal.mizrahi.phd@gmail.com>.

IESG Note
   
   There was a discussion in IETF Last Call about integrity protection 
   of IOAM. The result was that the authors submitted a separate draft, 
   which is being fast-tracked in IPPM, added an informative reference 
   to this draft.

RFC Editor Note