Re: [Ioam] IOAM in IPPM

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Al,

thanks for your notes - please see inline (..FB:)

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[e-mail]] 
Sent: Donnerstag, 16. Februar 2017 19:57
To: Frank Brockners (fbrockne) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: IOAM in IPPM

Hi Frank and numerous IOAM co-authors, 

(with due respect to the charter discussion thread)

When I saw the IOAM mailing list announced a few weeks back I looked-in and saw that there were several terms used to categorize this type of measurement method (in-situ, in-band, etc.).
I planned to send a pointer to the definitions of categories IPPM (and IETF) agreed when new methods began to appear, so I'll do it now: https://tools.ietf.org/html/rfc7799

>From the slides and the early sections of the draft, it appears what you propose here is a Hybrid Type I method (Augmentation or modification of the stream of interest).
This proposal has much in common with the PDM Destination Option Header: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-07
which we knew about and classified in the RFC:
https://tools.ietf.org/html/rfc7799#section-4.2

   This method processes a user traffic stream and adds "fields which
   are dedicated to measurement" (the measurement intent is made clear
   in the title of this option).

...FB: Yes. In-situ OAM would be "Hybrid OAM, Type 1" - we also mention this explicitly in the requirements draft and refer to RFC7799, see section 1 in https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02#page-3

It may be useful to look at the points about MTU made in section 4.2. It seems that the user traffic entering the in-situ domain will need to leave significant space for the various data format fields that would be added. If this topic has already been discussed, I hope you'll summarize it here for the IPPM crowd and/or provide good pointers.

...FB: In-situ OAM information requires space in the packet - and the in-situ OAM needs to have appropriate MTU support. A discussion on MTU and packet-size is found in the requirements draft in section 4.2, see https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02#page-12

Another goal of Hybrid measurement is that modified traffic and unmodified traffic would be treated as the *same* class of traffic by the network. Otherwise, one advantage over active measurement methods would be lost.  We described this problem at the end of page 7 in RFC 7799: 

      Hybrid Methods of measurement that augment or modify packets of a
      "class C" in a host should produce results equivalent to Passive
      Methods of Measurement when hosts accessing and links transporting
      these packets along the path (other than those performing
      augmentation/modification) treat packets from both categories of
      methods (with and without the augmentation/modification) as the
      same "class C".  The Passive Methods of Measurement represent the
      Ground Truth when comparing results between Passive and Hybrid
      Methods, and this comparison should be conducted to confirm the
      "class C" treatment.

I wonder if you have considered this comparison/constraint yet during the IOAM format and measurement development. It would likely be useful to cover this topic on IPPM list.

...FB: This is a very worthwhile comment and has been briefly raised before during discussions in OPSAWG at the last IETF. There is no easy answer to the question: "Will a packet which is added in-situ OAM data be treated the same as if it would not be added in-situ OAM data?", because it'll likely depend on implementation details as well as the encapsulation used. Example: There are implementations which forward packets differently in case an IPv6 extension header is present in the packet - while not the case for all implementations, some have that behavior. Now if IOAM would be added as an extension header and it would be the only extension header present in the packet, some implementations might indeed change their forwarding behavior. Hence it is important to make sure that for the IOAM domain you indeed have nodes which conform to the assumption that forwarding behavior will not change when IOAM data is added to the packet.
What this leads to is probably another requirement we need to take into consideration - and that we should add to the requirements draft: E.g. something like "The addition of IOAM data-records should not change the way packets are forwarded *within* the IOAM domain."


Thoughts?

Thanks, Frank


thanks and regards,
Al

> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Frank Brockners
> (fbrockne)
> Sent: Thursday, February 16, 2017 12:07 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [ippm] IOAM in IPPM
> 
> Dear IPPM WG,
> 
> following the recommendation from the IPPM chairs (see also Brian's 
> email below) as well as ADs involved (see also Alvaro's email below) 
> the discussions on in-situ OAM (IOAM), we'd like the IPPM WG to 
> consider adopting the IOAM work, especially the definition of formats 
> and associated procedures for in-situ OAM, including mechanisms for 
> capturing path and path-traversal related information as well as 
> procedures to employ, configure, trigger, and export the embedded 
> telemetry information. For this we'd suggest to adopt
> https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a 
> starting point for the work of IPPM on IOAM. Like Brian noted, IPPM WG 
> already focusses on hybrid measurements (e.g. those enabled by the 
> similar draft-ietf-ippm-6man-pdm-option), hence IOAM would be a 
> natural complement and addition to that work and would benefit from 
> all earlier work on metrics etc.
> 
> Background on In-situ OAM: In-situ OAM provides real-time telemetry of 
> individual data packets and flows. It is based on telemetry 
> information which is embedded within live user traffic, where "live user traffic"
> means packets originated and terminated at the application layer. For 
> more information on in-situ OAM, you could refer to the requirements 
> draft we posted (draft-brockners-inband-oam-requirements-02), or check 
> out the presentations we gave at IETF 96 and 97:
> https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf and
> https://www.ietf.org/proceedings/97/slides/slides-97-opsawg-in-situ-oa
> m-
> 00.PDF
> 
> Appreciate your thoughts and support :-).
> 
> Thanks, Frank
> 
> -----Original Message-----
> From: Brian Trammell (IETF) [mailto:[e-mail]]
> Sent: Donnerstag, 16. Februar 2017 16:13
> To: Frank Brockners (fbrockne) <[e-mail]>
> Subject: IOAM in IPPM
> 
> Hi, Frank,
> 
> As we discussed today, please do introduce your draft 
> (draft-brockners-
> inband-oam-data-00) to the IPPM mailing list. Given our recent focus 
> on hybrid measurements (e.g. those enabled by the similar 
> draft-ietf-ippm- 6man-pdm-option), I'd like to start a discussion 
> there about considering the draft for adoption within IPPM.
> 
> Thanks, cheers,
> 
> Brian
> 
> -----Original Message-----
> From: Ioam [mailto:[e-mail]] On Behalf Of Alvaro Retana
> (aretana)
> Sent: Donnerstag, 16. Februar 2017 17:58
> To: [e-mail]
> Subject: [Ioam] IOAM Work Moving Forward
> 
> Hi!
> 
> First of all, thank you all for the interest expressed in this topic 
> and the discussions about the charter.
> 
> As you know, one of the discussions resulting from the Internal Review 
> of the proposed IOAM charter was whether the work was already within 
> the ippm WG scope or not.  Over the last couple of days, I have dug 
> deeper into that question with the Transport ADs and the ippm WG 
> Chairs, and our conclusion is that there is significant overlap 
> between the current ippm Charter and the proposed IOAM work.  Enough 
> to justify moving the work forward in the ippm WG and not splintering 
> a related effort into a new WG.
> 
> I have then stopped the chartering effort for a new WG.  The 
> proponents will start discussions on the ippm list soon - please join 
> if you're not there already.  I will keep this list open for a couple more days.
> 
> Clearly there is interest in developing this cross-area work in the 
> IETF.  I hope that you will continue to participate as the topic 
> progresses on the ippm WG.  It is important that this type of 
> cross-area efforts be properly discussed and that we don't create more 
> silos.  I realize it took us a couple of tries to find what I think is 
> a stable home for the IOAM work - I know that the open discussion has 
> only helped the overall process.
> 
> Thanks!
> 
> Alvaro.