Subject: [ippm] IOAM drafts on data fields and encapsulation for IETF London

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 5 Mar 2018 10:29:24 +0000

FYI - A set of new IOAM related drafts have just been posted, including an updated version of the draft that defines IOAM data fields (draft-ietf-ippm-ioam-data-02.txt) and a group of drafts which tackle encapsulation of IOAM data fields into different protocols. We received guidance from the IPPM chairs to perform the work on IOAM encapsulation into the different protocols initially in the IPPM working group moving forward - as opposed to doing a tour across the various WGs which "own" the protocols. This should allow us to keep all the encapsulations consistent and in synch. Once the work is considered mature by IPPM WG, we'll then ask the different WGs that "own" the corresponding protocol for a review. The one exception to this process is NSH where we'll start within SFC WG right away, mostly because the NSH WG showed a lot of interest in the OAM topic, and OAM is also part of the SFC WG scope adjustment.

Here's the most recent status - with key news/updates highlighted

·       IOAM data fields (draft-ietf-ippm-ioam-data-02.txt<https://www.ietf.org/id/draft-ietf-ippm-ioam-data-02.txt>)

o   Following the discussion we had in Singapore, we introduced a new section on timestamp formats - allowing 1588/NTP/POSIX time stamps and harmonizing timestamp definition across trace and E2E options.

o   Working on a consistent way to encapsulate IOAM data fields, we arrived at defining an IOAM-Type data field and associated registry - to represent our 4 different IOAM types (preallocated trace option, incremental trace option, proof of transit, E2E). With that definition, we typically only need a single code point from protocols that we encapsulate IOAM data in. This greatly simplifies the IOAM encap drafts (see below)  - because from all the encapsulating protocols shown below we really only need a single code point.

·       Encapsulation of IOAM data fields

o   draft-weis-ippm-ioam-gre-00.txt<https://www.ietf.org/id/draft-weis-ippm-ioam-gre-00.txt>

§  New document which breaks out the GRE section of the old "draft-brockners-inband-oam-transport" into a dedicated document and reflects the new IOAM-Type.

o   draft-brockners-nvo3-ioam-geneve-00.txt<https://www.ietf.org/id/draft-brockners-nvo3-ioam-geneve-00.txt>

§  Re-submission of the earlier draft-brockners-nvo3-ioam-geneve-00.txt to reflect the move of the discussions to IPPM WG.

§  Updated to use the new IOAM-Type.

o   draft-brockners-ippm-ioam-vxlan-gpe-00.txt<https://www.ietf.org/id/draft-brockners-ippm-ioam-vxlan-gpe-00.txt>

§  Re-submission of the earlier draft-brockners-ioam-vxlan-gpe-00.txt to reflect the move of the discussions to IPPM WG.

§  Updated to use the new IOAM-Type.

o   draft-brockners-sfc-ioam-nsh-01.txt<https://www.ietf.org/id/draft-brockners-sfc-ioam-nsh-01.txt>

§  Updated to use the new IOAM-Type. (Document just mentioned for reasons of completeness here. Discussion will happen in NSH WG).

Thoughts and comments are greatly appreciated. We've already asked the chairs to allocated time on the agenda for draft-ietf-ippm-ioam-data-02, draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-nvo3-ioam-geneve-00, draft-weis-ippm-ioam-gre-00. Looking forward to a lively discussion in London.

Thanks much, Frank