Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sun, 4 Jun 2017 12:37:09 +0000

Hi,
 
(1) whether you support addition of the following milestone to the IPPM charter:

Yes/Support
        
(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
Yes/Support.
    
    (3) whether you commit to reviewing the document if adopted
    Yes.
    
Thanks,
Nagendra    
    
    > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[email-masked]> wrote:
    > 
    > Dear IPPM WG,
    > 
    > we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
    > 
    > We appreciate your thoughts and comments.
    > 
    > Regards, Frank
    > 
    > _______________________________________________
    > ippm mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/ippm
    
    _______________________________________________
    ippm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ippm

---

From: Sarah B <[email-masked]>
Date: Mon, 5 Jun 2017 15:33:12 -0700

Hello,
	Although I do have reservations about this draft, I do think it deserves the chance to be worked on by the group and come to the penultimate consensus (or not) to move it forward to publication. That said, I do not believe the current charter allows this draft to come in; the charter is pretty clear that network OAM is out of scope, and so a charter change has to happen. If we recharter, are we planning to do so to accommodate this one draft, or future OAM work as well?
	Given Brian's Q's below:
	1. I support the addition of the milestone. I can't decide on another place to take this work; IPPM seems most apropos.
	2. I support the adoption of draft-brockners-etc as the basis document for the milestone
	3. I think there are minutes somewhere that signed me up for this reviewing already :)

Thanks
Sarah

> On May 30, 2017, at 1:17 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, IPPM,
> 
> At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
> 
> This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [email-masked] indicating:
> 
> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG
> 
> We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
> 
> Many thanks, best regards,
> 
> Brian (as IPPM co-chair)
> 
> 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 6 Jun 2017 02:02:58 +0000

Hi, Brian,

Thank you for driving this poll.

I clearly support this work and believe it will be IETF-cycles very well invested to advance and publish this work.

To that end, a couple of comments:

(1) I support the addition of a milestone to IPPM, to hat this work from. That may require a one-liner “recharter”, but let’s not bloat the process-ware.

However, a couple of comments:

Let’s change “inband OAM based” for “in-situ” or “hybrid model something”, or anything that does not causes potential confusion.

We could generalize “ measurement methodologies” as “ methodologies including performance measurement”.

I know the draft is now labeled as Experimental, but frankly this is no “research project”, and there’s no experiment per-se. Consequently, I’d support standards track.

(2) Definitely. draft-brockners-inband-oam-data continues to incorporate community feedback and review and is a solid starting point for said milestone.

Thanks,

— Carlos.

> On May 30, 2017, at 4:17 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, IPPM,
>

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 6 Jun 2017 10:55:58 +0000

Hello Brian/ all,
   As an implementer of the inband-oam-data draft (fd.io), I support the WG adoption of this document. I suggest that this be considered for Standards track instead of the experimental track since we have working code of IOAM across three different transport protocols (IPv6, VxLAN-GPE and NSH).
Thanks
Prasad

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Tuesday, May 30, 2017 1:48 PM
To: [email-masked]
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Tue, 6 Jun 2017 15:35:46 +0000

All,

   Having read the draft, I support the WG adoption of this document.  I
can review the document as needed, upon adoption.

Thanks
Srihari

>At our Chicago meeting, we decided we needed a single, cleaned-up
>document containing appropriate scoping and rationale in order to make a
>decision as to whether we'd like to adopt IOAM within IPPM. This revision
>of draft-brockners-inband-oam-data is that document.
>
>This message, therefore, starts a call for adoption on
>draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday
>20 June 2017. Please reply to [email-masked] indicating:
>
>(2) whether you support the adoption of
>draft-brockners-inband-oam-data-05 as the basis document for this
>milestone
>
>We are aware that there is an open question as to whether we can adopt
>draft-brockners-inband-oam-data under our current charter; we'd like to
>see if there is IPPM WG consensus on adoption before discussing a
>recharter, hopefully before Prague, though we can take face-to-face time
>in Prague for this if necessary. Our intention, as chairs, is to make the
>minimal necessary change to the charter should there be consensus for
>adoption. However, if you have particular opinions as to how this should
>be done, please also address these in your message.
>
>> we¹ve just posted an updated version of
>>draft-brockners-inband-oam-data:
>>https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is
>>to address the recent comments on the mailing list. The main change is
>>the verbiage around the need to ensure that IOAM data is kept within the
>>IOAM domain. In addition, several editorial nits have been cleaned up.
>>

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 8 Jun 2017 08:32:17 +0300

As a coauthor, I support the adoption of this draft, I support adding it to
the charter, and I am committed to take part in editing the document based
on the working group feedback.

Cheers,
Tal.

On Tue, May 30, 2017 at 11:17 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document
> containing appropriate scoping and rationale in order to make a decision as
> to whether we'd like to adopt IOAM within IPPM. This revision of
> draft-brockners-inband-oam-data is that document.
>
> recharter, hopefully before Prague, though we can take face-to-face time in
> Prague for this if necessary. Our intention, as chairs, is to make the
> adoption. However, if you have particular opinions as to how this should be
> done, please also address these in your message.
>
> > we’ve just posted an updated version of draft-brockners-inband-oam-data:
> to address the recent comments on the mailing list. The main change is the
> verbiage around the need to ensure that IOAM data is kept within the IOAM
> domain. In addition, several editorial nits have been cleaned up.
> >

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 9 Jun 2017 02:12:47 +0000

Hi All,

I have read all the draft-brockners-inband-oam-** series. I support the adoption.
I would like to review the documents if adopted.

Cheers,
Tianran

> Sent: Tuesday, May 30, 2017 4:18 PM
> To: [email-masked]
> containing appropriate scoping and rationale in order to make a decision
> as to whether we'd like to adopt IOAM within IPPM. This revision of
> see if there is IPPM WG consensus on adoption before discussing a recharter,
> hopefully before Prague, though we can take face-to-face time in Prague
> for this if necessary. Our intention, as chairs, is to make the minimal
> necessary change to the charter should there be consensus for adoption.
> However, if you have particular opinions as to how this should be done,
> please also address these in your message.
>

---

From: Nalini J Elkins <[email-masked]>
Date: Fri, 9 Jun 2017 02:44:22 +0000 (UTC)

All,

>1) whether you support addition of the following milestone to the IPPM charter:

> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

I support addition of this milestone.    

> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

Yes.  But, I have some comments as to the various data fields most of which I will save for the actual discussion of the draft.   For example, we may be able to
compress the number of fields.   I also need to think a bit more about time synchronization issues as well as the granularity of the timestamps. 

> (3) whether you commit to reviewing the document if adopted

Yes.   I commit to reviewing the document.  I have provided some comments to the authors in early versions of the document.   I found the other documents in this series helpful in 
understanding the data layout so it may be good to have pointers to them, possibly as white papers.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Brian Trammell (IETF) <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Tuesday, May 30, 2017 1:17 AM
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 9 Jun 2017 15:39:46 +0000

+1
  On  all three questions. 

 My additional comments   are:
  There are a few architectural and
  technical details to  be worked out, but this
 draft  proposes constructs and  metrics that would be
 very  valuable to network and  enterprise operators.  I
 would  look  forward to reviewing and assisting in any way
 I can  to  achieve such advancements in network
 management.  I  also foresee the information  &
 metrics to be delivered  by inband OAM,  as a great
 partner and supplement to what  PDM  purveys.  As an
 enterprise  operator,  I need PDM ASAP for the high level
 triage and  fault domain isolation it provides.    Later,
 (at least in  my chronological sequence of preferential
 events),  I would  like to then use Inband OAM, if the PDM
 triage results deem  those metrics to be necessary fault
 domain details I might  need to solve a problem or improve
 performance quickly.
Look forward to working together in this  regard as  well. 

Thanks, 
Mike

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Nalini J Elkins
Sent: Thursday, June 8, 2017 10:44 PM
To: Brian Trammell (IETF) <[email-masked]>; [email-masked]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

All,

 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

Greetings, IPPM,

Brian (as IPPM co-chair)

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 12 Jun 2017 17:59:17 -0700

Hi Brian,
thank you for listing all the questions so clearly. To me answer depends
upon where the required update of the IPPM WG charter takes us. In the
current version of the draft I see very little of performance measurement
support and no new performance metrics or significant benefits when
comparing to existing measurement methods to justify change to the charter.
Most of the functionality supported by current version of the draft, as it
appears, is to serve not performance measurement but network operation
(tracing flow, collecting buffer utilization statistics, etc.) One of the
use cases, proof of transit, is, in my view, in the same category. Thus, I
don't see much of relevance between draft-brockners-inband-oam-data-05 and
performance measurement, performance metrics whether in IP network or
overlay network that uses IP as transport. What the update of the WG
charter could be? To me it it the first priority question with all others
following it.
Couple comments on the draft:

   - I suggest updating the boilerplate and section Conventions to
   reference RFC 8174 and use the following:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <https://tools.ietf.org/html/bcp14> [RFC2119
<https://tools.ietf.org/html/rfc2119>] [RFC8174
<https://tools.ietf.org/html/rfc8174>] when, and only when, they
      appear in all capitals, as shown here.

Resulting, do not use capitals but only lower case as this is Experimental
document. And because this is Experimental document, remove IANA
Consideration section.

In conclusion, I'd prefer to discuss the change to the WG charter before
updating Milestones and considering adoption of
the draft-brockners-inband-oam-data-05. As of now, I don't support either
as I don't see any relevance of the draft-brockners-inband-oam-data-05 to
the WG charter.

Regards,
Greg

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 18 Jun 2017 22:17:15 +0000

Hi Brian and IPPMers,

> From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
...
> 
> This message, therefore, starts a call for adoption on draft-brockners-
> inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017.
> Please reply to [email-masked] indicating:
> 
[ACM] 
Given that most have concluded that in-situ OAM is categorized as 
Hybrid Type I (according to RFC 7799), the I would say that this
statement in the charter is *pretty close*:

   Additional methods will be defined for the composition and calibration of
   IPPM-defined metrics, as well as active, passive and hybrid measurement
   methods for these metrics.

and I agree we can either adopt the draft now, or with a small tweak to
the charter text. The measurement methods mostly concern the data fields,
and do not define complete protocol solutions that will be subjected
to more complete review.

Question: In the proposed milestone text, was "inband" used to have 
generality before "in-situ" is considered and adopted?
I suggest s/inband/in-situ/ if the milestone and the
draft are adopted together, to have clear limits.

> 
> (2) whether you support the adoption of draft-brockners-inband-oam-data-
> 05 as the basis document for this milestone
[ACM] 
Yes, I support this draft in particular.

> (3) whether you commit to reviewing the document if adopted
[ACM] 
Yes, I attach a review of the first three sections, below.

regards,
Al

Internet-Draft           In-situ OAM Data Fields                May 2017

1.  Introduction

   This document defines data fields for "in-situ" Operations,
   Administration, and Maintenance (OAM).  In-situ OAM records OAM
   information within the packet while the packet traverses a particular
   network domain.  The term "in-situ" refers to the fact that the OAM
   data is added to the data packets rather than is being sent within
   packets specifically dedicated to OAM.  A discussion of the
   motivation and requirements for in-situ OAM can be found in
   [I-D.brockners-inband-oam-requirements].  In-situ OAM is to
   complement mechanisms such as Ping or Traceroute, or more recent
   active probing mechanisms as described in
[ACM]  Not clear to me why we need two different definitions of "type".
RFC7799 considers OAM measurements in its categorization. 
It would be good to include the specific phrases of the definitions
that place in-situ OAM in the Hybrid Type 1 Category, some of which
were exchanged in recent e-mail discussion of this draft.

   [I-D.lapukhov-dataplane-probe].  In terms of "active" or "passive"
   OAM, "in-situ" OAM can be considered a hybrid OAM type.  While no
   extra packets are sent, in-situ OAM adds information to the packets
   therefore cannot be considered passive.  In terms of the
   classification given in [RFC7799] in-situ OAM could be portrayed as
   "hybrid OAM, type 1". 
[ACM] s/hybrid OAM, type 1/Hybrid Type 1/
I suggest to resist the urge to use double-quotes when indicating terms
that have formal definitions elsewhere. The definitions are primarily for 
active/passive/hybrid *methods* of measurement (and for *metrics*, although
I'm not sure we need to define metrics yet.)
   "In-situ" mechanisms do not require extra
   packets to be sent and hence don't change the packet traffic mix
   within the network.  In-situ OAM mechanisms can be leveraged where
   mechanisms using e.g.  ICMP do not apply or do not offer the desired
   results, such as proving that a certain traffic flow takes a pre-
   defined path, SLA verification for the live data traffic, detailed
   statistics on traffic distribution paths in networks that distribute
   traffic across multiple paths, or scenarios in which probe traffic is
   potentially handled differently from regular data traffic by the
   network devices.

2.  Conventions

[ACM] no comments this section

3.  Scope, Applicability, and Assumptions

   In-situ OAM deployment assumes a set of constraints, requirements,
   and guiding principles which are described in this section.

   Scope: This document defines the data fields and associated data
   types for in-situ OAM.  The in-situ OAM data field can be transported
   by a variety of transport protocols, including NSH, Segment Routing,
[ACM] s/transport/network/
? In IETF, transport protocols are UDP and TCP (and QUIC)

   Geneve, IPv6, or IPv4.  Encapsulation details for these different
   transport protocols are outside the scope of this document.
[ACM] s/Encapsulation/Specification/
Clearly, some of the protocols mentioned above perform encapsulation
of other protocol headers. This memo describes the additional fields
to insert when forming a new header, or optional fields to insert in
an *existing* header (e.g., IPv4 and IPv6). I think the Scope 
should clearly indicate that these two possibilities are included.

   Deployment domain (or scope) of in-situ OAM deployment: IOAM is a
   network domain focused feature, with "network domain" being a set of
   network devices or entities within a single administration.  For
   example, a network domain can include an enterprise campus using
   physical connections between devices or an overlay network using
   virtual connections / tunnels for connectivity between said devices.
   A network domain is defined by its perimeter or edge.  Designers of
   carrier protocols for IOAM must specify mechanisms to ensure that in-
[ACM] s/must/MUST/  
   situ OAM data stays within an IOAM domain.  In addition, the operator
   of such a domain is expected to put provisions in place to ensure
   that IOAM data does not leak beyond the edge of an IOAM domain, e.g.
   using for example packet filtering methods.  The operator should
   consider potential operational impact of IOAM to mechanisms such as
   ECMP processing (e.g. load-balancing schemes based on packet length
   could be impacted by the increased packet size due to IOAM), path MTU
   (i.e. ensure that the MTU of all links within a domain is
   sufficiently large to support the increased packet size due to IOAM)
   and ICMP message handling (i.e. in case of a native IPv6 transport,
   IOAM support for ICMPv6 Echo Request/Reply could desired which would
   translate into ICMPv6 extensions to enable IOAM data fields to be
   copied from an Echo Request message to an Echo Reply message).

[ACM] Comments on the control point definition below...
   In-situ OAM control points: IOAM data fields are added to or removed
   from the live user traffic by the devices which form the edge of a
   domain.  Devices within an IOAM domain can update and/or add IOAM
   data-fields.  Domain edge devices can be hosts or network devices.

   Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on
   all or only on subsets of the live user traffic.  It SHOULD be
   possible to enable in-situ OAM on a selected set of traffic (e.g.,
   per interface, based on an access control list or flow specification
   defining a specific set of traffic, etc.)  The selected set of
   traffic can also be all traffic.

   Encapsulation independence: Data formats for in-situ OAM SHOULD be
   defined in a transport-independent manner.  In-situ OAM applies to a
   variety of encapsulating protocols.  A definition of how IOAM data
   fields are carried by different transport protocols is outside the
   scope of this document.

   Layering: If several encapsulation protocols (e.g., in case of
   tunneling) are stacked on top of each other, in-situ OAM data-records
   could be present at every layer.  The behavior follows the ships-in-
   the-night model.

   Combination with active OAM mechanisms: In-situ OAM should be usable
   for active network probing, enabling for example a customized version
   of traceroute.  Decapsulating in-situ OAM nodes may have an ability
   to send the in-situ OAM information retrieved from the packet back to
   the source address of the packet or to the encapsulating node.
[ACM] I'd like to see a slightly more complete naming scheme for
the nodes participating in IOAM methods. You already define 
*IOAM control points* above which seem to be the originators and terminators
of the inserted IOAM fields. These nodes are sometimes encapsulating and 
decapsulating nodes, but not always (I think, see comment on IPv4+v6).
There are also nodes which participate in the IOAM methods located
internal to the administrative/IOAM domain. I suggest that:
"Devices within an IOAM domain can update and/or add IOAM data-fields."
could have a different name that distinguishes their role.
For a given path, these devices are simply members of the IOAM domain
and perform a subset of the IOAM functions. 
Although the role of these devices could change with a different path,
there could also be devices (or functions) that are always intended to
be internal to the IOAM domain, and need only a subset of 
IOAM capabilities. 
I'll let the authors name these "members-only" nodes, but I think
this role is useful to distinguish. My guess is that there will be
a linkage between these roles and the three main types of in-situ data 
defined elsewhere.

   In-situ OAM implementation: The IOAM data-field definitions take the
   specifics of devices with hardware data-plane and software data-plane
   into account.

-=-=-=-=-=-=-=-=-=-=-

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 20 Jun 2017 07:48:36 +0000

Hi Carlos,

on your note: " I know the draft is now labeled as Experimental, but frankly this is no “research project”, and there’s no experiment per-se. Consequently, I’d support standards track.".

IMHO it does make sense to move to standards tacks, because we already have a few implementations, including the open source implementation in FD.io. And just recently, Broadcom and Netronome published a video featuring their IOAM implementation: https://www.youtube.com/watch?v=j9FbD4a3F4E  

Regards, Frank 

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Dienstag, 6. Juni 2017 04:03
To: Brian Trammell (IETF) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

Hi, Brian,

Thanks,

— Carlos.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 20 Jun 2017 17:58:53 +0200

Greetings, all,

This call for adoption is concluded.

It appears from the discussion that there is broad but not unanimous support for adoption of this document, but some concerns about how exactly the charter would need to be modified to bring this work into IPPM. In any case, there appears to be more than enough support to investigate a rechartering. The chairs will work with the authors and the working group to suggest a charter revision for discussion at our face-to-face meeting in Prague.

Cheers,

Brian

> On 30 May 2017, at 10:17, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, IPPM,
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Sun, 25 Jun 2017 23:54:38 +0000

Hi Al,

thanks a lot for your comments. While integrating your comments into the doc, a question on the roles of IOAM nodes arose. So far we have

* IOAM encapsulating nodes (nodes which add IOAM container(s) )
* IOAM decapsulating nodes (nodes which removed IOAM container(s) )
* IOAM transit nodes (nodes which update/add IOAM data fields )

You suggest to add another role for "Devices within an IOAM domain can update and/or add IOAM data-fields.". What isn't entirely clear to me is how those devices would differ from IOAM transit nodes. Could you detail your thinking a bit more?

Thanks, Frank

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Sonntag, 18. Juni 2017 15:17
To: Brian Trammell (IETF) <[email-masked]>; [email-masked]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

Hi Brian and IPPMers,

...
> draft-brockners- inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017.
> (1) whether you support addition of the following milestone to the 
> IPPM
> charter:
> 
[ACM]
Given that most have concluded that in-situ OAM is categorized as Hybrid Type I (according to RFC 7799), the I would say that this statement in the charter is *pretty close*:

and I agree we can either adopt the draft now, or with a small tweak to the charter text. The measurement methods mostly concern the data fields, and do not define complete protocol solutions that will be subjected to more complete review.

Question: In the proposed milestone text, was "inband" used to have generality before "in-situ" is considered and adopted?
I suggest s/inband/in-situ/ if the milestone and the draft are adopted together, to have clear limits.

> draft-brockners-inband-oam-data-
[ACM]

[ACM]

regards,
Al

1.  Introduction

   active probing mechanisms as described in [ACM]  Not clear to me why we need two different definitions of "type".
It would be good to include the specific phrases of the definitions that place in-situ OAM in the Hybrid Type 1 Category, some of which were exchanged in recent e-mail discussion of this draft.

[ACM] s/hybrid OAM, type 1/Hybrid Type 1/ I suggest to resist the urge to use double-quotes when indicating terms that have formal definitions elsewhere. The definitions are primarily for active/passive/hybrid *methods* of measurement (and for *metrics*, although I'm not sure we need to define metrics yet.)

2.  Conventions

   Scope: This document defines the data fields and associated data
   types for in-situ OAM.  The in-situ OAM data field can be transported
   by a variety of transport protocols, including NSH, Segment Routing, [ACM] s/transport/network/ ? In IETF, transport protocols are UDP and TCP (and QUIC)

   Geneve, IPv6, or IPv4.  Encapsulation details for these different
   transport protocols are outside the scope of this document.
[ACM] s/Encapsulation/Specification/
Clearly, some of the protocols mentioned above perform encapsulation of other protocol headers. This memo describes the additional fields to insert when forming a new header, or optional fields to insert in an *existing* header (e.g., IPv4 and IPv6). I think the Scope should clearly indicate that these two possibilities are included.

   carrier protocols for IOAM must specify mechanisms to ensure that in- [ACM] s/must/MUST/  

   Combination with active OAM mechanisms: In-situ OAM should be usable
   for active network probing, enabling for example a customized version
   of traceroute.  Decapsulating in-situ OAM nodes may have an ability
   to send the in-situ OAM information retrieved from the packet back to
   the source address of the packet or to the encapsulating node.
[ACM] I'd like to see a slightly more complete naming scheme for the nodes participating in IOAM methods. You already define *IOAM control points* above which seem to be the originators and terminators of the inserted IOAM fields. These nodes are sometimes encapsulating and decapsulating nodes, but not always (I think, see comment on IPv4+v6).
There are also nodes which participate in the IOAM methods located internal to the administrative/IOAM domain. I suggest that:
"Devices within an IOAM domain can update and/or add IOAM data-fields."
could have a different name that distinguishes their role.
For a given path, these devices are simply members of the IOAM domain and perform a subset of the IOAM functions. 
Although the role of these devices could change with a different path, there could also be devices (or functions) that are always intended to be internal to the IOAM domain, and need only a subset of IOAM capabilities. 
I'll let the authors name these "members-only" nodes, but I think this role is useful to distinguish. My guess is that there will be a linkage between these roles and the three main types of in-situ data defined elsewhere.

-=-=-=-=-=-=-=-=-=-=-

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 26 Jun 2017 02:09:23 +0000

Hi Frank,

I didn't see IOAM transit nodes as far as I read this time,
and it seems to the class of node I was looking for.

problem solved,
Al

> From: Frank Brockners (fbrockne) [mailto:[email-masked]]
> Sent: Sunday, June 25, 2017 7:55 PM
> To: MORTON, ALFRED C (AL); Brian Trammell (IETF); [email-masked]
> Subject: RE: [ippm] Adoption call for draft-brockners-inband-oam-data
> 
> Hi Al,
> 
> thanks a lot for your comments. While integrating your comments into the
> doc, a question on the roles of IOAM nodes arose. So far we have
> 
> You suggest to add another role for "Devices within an IOAM domain can
> update and/or add IOAM data-fields.". What isn't entirely clear to me is
> how those devices would differ from IOAM transit nodes. Could you detail
> your thinking a bit more?
> 
> Thanks, Frank
> 
> Given that most have concluded that in-situ OAM is categorized as Hybrid
> Type I (according to RFC 7799), the I would say that this statement in
> the charter is *pretty close*:
> 
> the charter text. The measurement methods mostly concern the data
> fields, and do not define complete protocol solutions that will be
> subjected to more complete review.
> 
>    active probing mechanisms as described in [ACM]  Not clear to me why
> we need two different definitions of "type".
> It would be good to include the specific phrases of the definitions that
> place in-situ OAM in the Hybrid Type 1 Category, some of which were
> exchanged in recent e-mail discussion of this draft.
> 
> [ACM] s/hybrid OAM, type 1/Hybrid Type 1/ I suggest to resist the urge
> to use double-quotes when indicating terms that have formal definitions
> elsewhere. The definitions are primarily for active/passive/hybrid
> *methods* of measurement (and for *metrics*, although I'm not sure we
> need to define metrics yet.)
> [ACM] s/transport/network/ ? In IETF, transport protocols are UDP and
> TCP (and QUIC)
> 
> Clearly, some of the protocols mentioned above perform encapsulation of
> other protocol headers. This memo describes the additional fields to
> insert when forming a new header, or optional fields to insert in an
> *existing* header (e.g., IPv4 and IPv6). I think the Scope should
> clearly indicate that these two possibilities are included.
> 
> [ACM] I'd like to see a slightly more complete naming scheme for the
> nodes participating in IOAM methods. You already define *IOAM control
> points* above which seem to be the originators and terminators of the
> inserted IOAM fields. These nodes are sometimes encapsulating and
> be internal to the IOAM domain, and need only a subset of IOAM
> capabilities.
> I'll let the authors name these "members-only" nodes, but I think this
> role is useful to distinguish. My guess is that there will be a linkage
> between these roles and the three main types of in-situ data defined
> elsewhere.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=m9voi8xLya6TPBn3_IgFJ6xDUD-
> YWwoQjZVXMruwhKw&s=jRJum_v8Peo66n9djtVCTImXZTtDJ00vljvEc10ZHkk&e=

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 27 Jun 2017 00:55:26 +0000

Thanks Al for the review and support!

I agree with s/inband/in-situ/

Although as you point out, the sentence in the existing charter seems to cover for “definition of hybrid methods”.

Thanks!

— Carlos.

> On Jun 18, 2017, at 6:17 PM, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> 
> Hi Brian and IPPMers,
>