Re: [ippm] IPPM - IOAM Side Meeting @IETF 104 - Updated Agenda

["Shwetha Bhandari (shwethab)" <[e-mail]>]

Here are my very drafty notes(not even close to accurate) from the side meetings. Other attendees can share theirs.

Side meeting 1: Monday
   Attendees: Tal Mizrahi , Ramesh Sivakolundu, Frank Brockners, Barak Gafni, Shwetha Bhandari, Haoyu song, Footer Foote, Mickey Speigel, Parvez Yegani, Jim Gong


  1.  Data fields – metrics collected and control of metrics collection
Active flag, Loopback flag, Immediate export to be separated to a dedicated draft(s).
Volunteer: Tal Mizrahi to initiate a draft and remove the references from the data draft.

  1.  Prioritization of the encap work:
     *   Barak : v4 and v6, everything else will ride on v4/v6
     *   Mickey : v4, v6, VxLAN-GPE
     *   Haoyu Song : v6, SRv6
     *   General opinion in the room seems to converge on v4, v6
  2.  Action/procedure for Immediate Export , Postcard based telemetry (PBT) , MTU handling while adding IOAM etc should be handled in the new IOAM data-control draft
  3.  Export data draft priority – take it up on opsawg mailing list
  4.  Simplify data draft – remove the flags: what else? Drop or clarify opaque snapshot field? Is length of opaque snapshot be a deployment consideration?

     *   Opinion in the room let the opaque snapshot as is.
     *   Flags – do we need more bits?
  1.  Trace option with Immediate Export flag vs a dedicated postcard-based-telemetry(PBT) Trace option

     *   Discussion on PBT option type – differences/similarity with the existing trace option – why existing trace option (preallocated/incremental) is not sufficient for PBT :
        *   Some of the fields in Trace option are not relevant for PBT mode (e.g. Remaining len)
        *   Additional data in the header to provide context for correlation will change the payload of trace option, a new option is better
     *   AI to edit the new PBT option to reuse the fields of Trace type header, remove fields that are not useful, add the context data that is needed for correlation in the PBT draft?  Haoyu Song volunteered to sketch this and send it out to the group. (We already see the discussion on IPPM)
     *   Further discussions needed following 6.2  to decide on how to update IOAM data draft, flags, define new option.
Side note: Can we fork the IOAM repo from<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2F&data=02%7C01%7Cgbarak%40mellanox.com%7Cb7a80b5a11134536813808d6b20759c9%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636892141977427420&sdata=XFEtFqGgEFEXKb%2F3WAe6%2Bl%2FUQhO5%2Fv1kxjnFKvgE90Q%3D&reserved=0> into IPPM wg git<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-ippm&data=02%7C01%7Cgbarak%40mellanox.com%7Cb7a80b5a11134536813808d6b20759c9%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636892141977437425&sdata=0L7VcEFKDeDboHuEGsAfmc%2F%2BNPUH6l21pdNgxeU4rxI%3D&reserved=0> for this work?


Side meeting 2: Tuesday

  Topic – prioritizing encapsulation for IOAM based on deployment experience:
   Jeff Tantasura (Apstra): VxLAN (vanilla) over IPv4 in DC for tracing and immediate export. For export of the collected data: Netflow less preferred for export   over GRPC.
Dmitry(Yandex) - Datacenter V6 – buffer and queue management in transit devices, export over GRPC
Diego Lopez (Telefonica) – NFV deployments  - VxLAN, MPLS for carrying the trace data – Export over GRPC
Haoyu Song (Huawei) : Carrier network, IOAM with SRv6, trace

Again: v4, v6 highest impact followed by VXLAN, SRv6,

Random comments:
Concerns about leaked packets out of the IOAM domain: do not assume UDP protocol number to map to VXlan or other tunnels to look for IOAM (RFC 7605)
Tom Herbert: How about the IPv4 extension header with IOAM?  https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-01
Greg Mirsky : Overhead of tracing w.r.t higher class of service
Jeff : Geneve in enterprise – Geneve deployments on the rise, should it be in the encapsulations to be tackled soon list?
Barak : If the problem is solved in the v4/v6 layer there is no need to do anything for overlays?
<general opinion> GRE not useful, native v4 solution needed.


Export of the IOAM data:
GRPC vs IPfix
After general discussion on feasibility framing raw IOAM data and some context into HTTPS(GRPC) for export to collector vs keeping it in simple IP/UDP or IPFIX for first level export, general opinion in the room tends to - it is a reasonable starting point to use for export.


IOAM Profile:
Tal described the IOAM profile https://tools.ietf.org/html/draft-mizrahi-ippm-ioam-profile-00.txt
Discussion on Yang to describe such a profile..


Performance and scaling discussion:
Writing metadata deep in the packet is expensive
Hardware parsing depth limitations demand minimizing data closer to the header. ECMP another consideration – L4 to be reachable for parsing engines within first x bits of the header..


Side meeting 3 : Wednesday
Topic: IFA & IOAM:

IFA drafts:
https://tools.ietf.org/html/draft-kumar-ippm-ifa-01.txt
https://tools.ietf.org/html/draft-kumar-mpls-mint-00.txt


  *   Namespace + Trace-type – the tuple defines how to interpret the IOAM node data collected.. seem to be an agreement on this being common grounds for IFA and IOAM
  *   Multiple namespaces within the same packet to support devices with different capabilities
     *   This is suboptimal for deployments (5G) that are sensitive to overhead of trace header/option length
     *   China mobile has a competing solution for MPLS to deal with low overhead- https://tools.ietf.org/id/draft-cheng-mpls-inband-pm-encapsulation-00.txt
  *   Another proposal for making lightweight IOAM https://tools.ietf.org/id/draft-li-spring-light-weight-srv6-ioam-00.txt
  *   Data draft: should we carve out tracing out as a separate draft from POT/E2E included... more discussion needed



Thanks,
Shwetha

From: ippm <[e-mail]> on behalf of "Ramesh Sivakolundu (sramesh)" <[e-mail]>
Date: Monday, March 25, 2019 at 6:19 PM
To: "[e-mail]" <[e-mail]>
Subject: [ippm] IPPM - IOAM Side Meeting @IETF 104 - Updated Agenda

Updated Agenda for Tuesday Side Meeting.

Agenda for  side meeting- Mon, March 25, 6:30pm – 8:00pm, Room Tyrolka


  1.  Data fields – metrics collected and control of metrics collection
  2.  Active flag – nomenclature and mode of operation.
  3.  Immediate Export  vs PBT – ways to correlate flows at the collector
  4.  V4 Options Discussion
  5.  Prioritize encapsulations to focus on.
  6.  Opaque State Snapshot – Schema ID vs Namespace ID

Agenda for side meeting - Tue, March 26, 6:30pm – 8:00pm, Room Tyrolka



  1.  IOAM Profile – use case
  2.  Prioritize encapsulations to focus on.
  3.  Performance / implementation considerations in IOAM

Agenda for side meeting - Wed, March 27, 1:30pm-3:00pm, Room TBD (Meet at Registration desk)



  1.  Spill over from Monday’s side meeting agenda
  2.  IFA proposal for data types and format.

-Ramesh