Subject: [OPSAWG] WG adoption poll for In-Situ OAM drafts

From: Zhoutianran <[email-masked]>
Date: Wed, 7 Dec 2016 06:36:42 +0000

Hi All,

In Seoul, we got enough interest on the In Situ OAM work and positive response on related drafts.
So this email starts a formal poll for adoption the following I-Ds.

https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt

To be efficient, we have the poll for three I-Ds in one thread. But you can give your opinion on each of them. And the result is per I-D.

The question is:
Do you think that the WG should adopt all or some of these drafts?

It would be helpful if you could indicate whether you have read the drafts. If "yes", would you like to review the drafts and help to improve the drafts? If "no", it is important that you provide reasons.

This poll will last for two weeks, ending on Tuesday, December 20.

Thanks,
Tianran & Warren

---

From: Joe Clarke <[email-masked]>
Date: Wed, 7 Dec 2016 10:34:34 -0500

On 12/7/16 01:36, Zhoutianran wrote:
> To be efficient, we have the poll for three I-Ds in one thread. But you
> can give your opinion on each of them. And the result is per I-D.
>
>
>
> The question is:

Yes, I support adoption of these drafts.  I think that perhaps PoT might 
fit better in opsec, but I have no strong objection to having all the 
work here.

>
>
>
> It would be helpful if you could indicate whether you have read the
> drafts. If "yes", would you like to review the drafts and help to
> improve the drafts? If "no", it is important that you provide reasons.

I have and I would be willing to help review.

Joe

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 7 Dec 2016 15:56:13 +0000

Hi,

Yes. I support the adoption of all 3 drafts as WG document.

Yes, I have read that and willing to review and improve.

Thanks,
Nagendra

From: OPSAWG <[email-masked]<mailto:[email-masked]>> on behalf of Zhoutianran <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 7, 2016 at 1:36 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi All,

The question is:

Thanks,
Tianran & Warren

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 14 Dec 2016 15:48:53 +0100

i am not sure if it is wise to adopt these 3 drafts as WG documents at this
point in time. At our WG session in Seoul, (when the WG chairs did a humm for
this in the session), I spoke up and stated that during the week in Seoul
there had been several presentations on inband OAM and Telemetry.
And I suggested that it might be wise to first analyze what is available and
already used or tested. Once we know that, we might be in a much better
position to determine which type of "inband OAM" or "Telemetry" mechanism makes
most sense.

My understanding of the humm in the WG was" "is this sort of work interesting
and do we as a WG want to work on thos". To that question, the humm seemed to
indicate that we indeed do fond the work relevant and interesting and that we
as the OPSAWG want to work on it. I took notes during our OPSAWG session in
Seoul, and I wrote down on this topic of inband OAM (and that has been posted
as draft minutes as well):

       Open question as where to land this work (OPS or TSV) ??

       Joel: the actual OAM methods vary on what the transport is.

       BW: there seem to be various telemetry ideas being presented at various places
           (WGs, RGs) should we get a summary of what is being discussed before we
            adopt a particular approach
       Daniel King: yes we have seen some in SDNRG
       Benoit: how do you get the data off the devices
               That is still to be decided
       Chairs: humm for: do we i(OPSAWG) want to work on telemetry
               conclusion: yes we do
       Benoit: there is a pub/subscribe which is related

So I find it a step too quick/fast to now determine which documents to adopt
as WG document. Let us get (from someone versen in the field of inband OAM
and telemetry) get a summary of the various types of work that has already been
presented/proposed in the IETF (and possibly at other places) and let us then
see if we can choose a way forward.

Bert

On 07/12/2016 07:36, Zhoutianran wrote:
> It would be helpful if you could indicate whether you have read the drafts. If "yes", would you like to review the drafts and help
> to improve the drafts? If "no", it is important that you provide reasons.
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Dec 2016 22:09:09 -0000

Hi Tianran,
 
I'm fairly much in agreement that this is a topic that should be worked on in
the IETF. 
 
I am somewhat nervous about the overlap between this and OAM work undertaken in
a number of working groups chiefly in the Routing Area, and I hope there can be
some careful coordination. 
 
My feeling is that we should start with the requirements draft at once. I am
pretty sure that once inside the WG we can quickly get important input from
operators and bash it into shape.
 
I think that the data format document may be close to being ready for adoption,
but I think that there are some largish wrinkles that could do with being ironed
out first. Chief among these are:
- A thorough investigation of the numeric impact on the amount of data that can
be sent. In other words, the change to the effective MTU
- The Abstract specifically says how encapsulation will be managed for IPv6. Not
only does the document later say that this is out of scope, but the mechanism
proposed in the Abstract is one that worries me.
- I don't like that the OAM only works if every node on the path supports it. I
would like for us to achieve some form of comfortable b/w compatibility.
- As an "experiment" I would like to understand how the experiment would be
conducted and what would constitute success
 
Why do I think these points should be addressed before adoption? I am worried
that without looking at them first there will be an assumption that the
document's is already set and 'radical' changes cannot be made. I think that my
points can be handled by:
- Adding a section on "MTU Concerns" that provides a pointer to the relevant
part of the requirements draft, and offers up some basic maths on the expected
size of OAM information in a packet.
- Removing the offending text from the Abstract
- Adding a section on b/w compatibility (maybe just as a placeholder) and
cleaning up the text that requires every node on the path to support in-situ
OAM.
- Adding a section scoping the experiment that the authors think they want the
WG to perform.
 
As for the proof of transit work, I think it is a bit of a mess at the moment.
It seems to be growing new approaches and options, each with drawbacks and
issues. And I'm not clear on the objectives.  This might be handled as with the
previous document by describing and scoping the experiment, but as currently
written, it would appear that the intention is to research a number of potential
approaches to proof of transit rather than to experiment with a particular
protocol solution, and that might make the document better suited to the NMRG.
So I would like to apply a bit more caution to that document.
  
In any event, during the process of adoption, do you think you could cut down
the front page authors to a manageable number so that we know who is editing the
work going forward?
 
Thanks,
Adrian
 
From: OPSAWG [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: 07 December 2016 06:37
To: [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG adoption poll for In-Situ OAM drafts
 
Hi All,
 
In Seoul, we got enough interest on the In Situ OAM work and positive response
on related drafts.
So this email starts a formal poll for adoption the following I-Ds.

To be efficient, we have the poll for three I-Ds in one thread. But you can give
your opinion on each of them. And the result is per I-D.
 
The question is:
 
It would be helpful if you could indicate whether you have read the drafts. If
"yes", would you like to review the drafts and help to improve the drafts? If
"no", it is important that you provide reasons.

Thanks,
Tianran & Warren

---

From: Zhoutianran <[email-masked]>
Date: Fri, 16 Dec 2016 06:28:11 +0000

Hi Adrian,

Thanks for your comments. The poll is to collect various opinions from the WG.
I have some preliminary reply in line.

Best,
Tianran
From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, December 16, 2016 6:09 AM
To: Zhoutianran; [email-masked]
Cc: [email-masked]
Subject: RE: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi Tianran,

I'm fairly much in agreement that this is a topic that should be worked on in the IETF.

>> Agreed.

I am somewhat nervous about the overlap between this and OAM work undertaken in a number of working groups chiefly in the Routing Area, and I hope there can be some careful coordination.

>> I also asked the authors about this question. Especially there is an overlay OAM design team in routing area. Their drafts and outputs show they also want to standardize a common OAM header for various transport.

My feeling is that we should start with the requirements draft at once. I am pretty sure that once inside the WG we can quickly get important input from operators and bash it into shape.

I think that the data format document may be close to being ready for adoption, but I think that there are some largish wrinkles that could do with being ironed out first. Chief among these are:
- A thorough investigation of the numeric impact on the amount of data that can be sent. In other words, the change to the effective MTU
- The Abstract specifically says how encapsulation will be managed for IPv6. Not only does the document later say that this is out of scope, but the mechanism proposed in the Abstract is one that worries me.
- I don't like that the OAM only works if every node on the path supports it. I would like for us to achieve some form of comfortable b/w compatibility.
- As an "experiment" I would like to understand how the experiment would be conducted and what would constitute success

Why do I think these points should be addressed before adoption? I am worried that without looking at them first there will be an assumption that the document's is already set and 'radical' changes cannot be made. I think that my points can be handled by:
- Adding a section on "MTU Concerns" that provides a pointer to the relevant part of the requirements draft, and offers up some basic maths on the expected size of OAM information in a packet.
- Removing the offending text from the Abstract
- Adding a section on b/w compatibility (maybe just as a placeholder) and cleaning up the text that requires every node on the path to support in-situ OAM.
- Adding a section scoping the experiment that the authors think they want the WG to perform.

>> Thanks for your comments and suggestions.

As for the proof of transit work, I think it is a bit of a mess at the moment. It seems to be growing new approaches and options, each with drawbacks and issues. And I'm not clear on the objectives.  This might be handled as with the previous document by describing and scoping the experiment, but as currently written, it would appear that the intention is to research a number of potential approaches to proof of transit rather than to experiment with a particular protocol solution, and that might make the document better suited to the NMRG. So I would like to apply a bit more caution to that document.
>> In my opinion, the objective of the POT draft is to demonstrate a solution for an applicable use case with in-situ OAM.

In any event, during the process of adoption, do you think you could cut down the front page authors to a manageable number so that we know who is editing the work going forward?

>> I think 5 authors is preferred. But at least the authors can add "Ed." tag after the editors.

Thanks,
Adrian

From: OPSAWG [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: 07 December 2016 06:37
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi All,

The question is:

Thanks,
Tianran & Warren

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Dec 2016 09:46:51 +0000

On 15/12/2016 22:09, Adrian Farrel wrote:
> As for the proof of transit work, I think it is a bit of a mess at the 
> moment. It seems to be growing new approaches and options, each with 
> drawbacks and issues. And I'm not clear on the objectives. This might 
> be handled as with the previous document by describing and scoping the 
> experiment, but as currently written, it would appear that the 
> intention is to research a number of potential approaches to proof of 
> transit rather than to experiment with a particular protocol solution, 
> and that might make the document better suited to the NMRG. So I would 
> like to apply a bit more caution to that document.

I think that there are two proof of transit solutions needed. One for 
network operators for simple operational verification and one for 
commercial or regulatory situations. In the first case one can assume a 
benign environment and use a lightweight approach. In the other one must 
assume a hostile environment and apply a more stringent proof. Maybe one 
can be a variant of the other, but this should not be at the cost of 
performance and implementation expense.

- Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 21 Dec 2016 05:54:38 +0000

Hi, Tianran & Warren,

Yes, the WG should adopt these documents, and yes I have read them (and wrote some of them) [NB: I am a co-author]

These documents provide a well organized description of an operator-acknowledged problem space / opportunity space, and then follows to defining both data structures as well as mechanisms for proof of transit of a path or a service chain.

The previous two IETF meetings showed both interest and support for this work, as they are a collaborative product (operators + vendors).

To maximize the chances of interoperability, which clearly matters for real-time in-situ telemetry as an end-to-end solution, these Internet-Drafts would be best served by being hosted in the WG with deep knowledge, expertise, and experience in operational areas in a tech agnostic way, and continue as a product of an even tighter collaboration.

Looking at https://datatracker.ietf.org/wg/opsawg/charter/, these documents seem to squarely fall within scope. And in particular, this bar seems passed:

   The OPSAWG will undertake only work items that are proved to have at
   least a reasonable level of interest from the operators and users
   community and have a committed number of editors and reviewers. It is

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Dec 7, 2016, at 1:36 AM, Zhoutianran <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

The question is:

Thanks,
Tianran & Warren
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 21 Dec 2016 06:02:14 +0000

Hi, Bert,

Please find a couple of follow-ups inline.

—

On Dec 14, 2016, at 9:48 AM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:

Would it be possible for you to share pointers to  (at least a few of the several) specific presentations and Internet-Drafts that overlap with or complement this work?

Note that the title of this documents was renamed to “In-Situ” (with thanks to Erik Nordmark for the suggestion) so as to not confuse with the IETF definition of “inband”.

Since specific pointers on what’s available is a pre requisite to understanding the landscape, see above.

“Telemetry” is such a broadly defined word that invariably, there will be “telemetry work” everywhere. When we focus and narrow scope on the actual specifics of in-situ OAM, that does not seem to be the case anymore.

I do not believe the question is “does the WG want to take on telemetry”.

I believe it is a fair request to compare and contrast and understand a broader picture. But that request expects more specifics than a perhaps someone else should do it.

Given the very specific requirements detailed by operators and vendors in draft-brockners-inband-oam-requirements-02.txt, the fact that we had to create a new descriptor (i.e., “In-Situ”) for this approach, and lack of specifics, it seems to me that the area of in-situ OAM is non-overlapping with other “telemetry" potential work elsewhere.

Thanks,

— Carlos.

Bert

To be efficient, we have the poll for three I-Ds in one thread. But you can give your opinion on each of them. And the result is per
I-D.

The question is:

Thanks,
Tianran & Warren

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 21 Dec 2016 06:36:07 +0000

Hi Adrian,

Interesting thoughts, please see inline.

—

On Dec 15, 2016, at 5:09 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tianran,

I believe the potentially perceived overlap is not real, and I’m not nervous about it.

I understand the word “OAM” is overlapping with work happening elsewhere inside and outside the IETF. However, when we look right underneath the thin surface, the overlap quickly tends to zero.

Looking at the OAM work in the RTG Area, and in particular the RTG-AD chartered Design Team, it seems to extend as far as defining an OAM protocol indication header pre-pended to specific OAM probe packets, modeled after the MPLS G-ACh.

On the other hand, the Operators and HW/SW Vendors from draft-brockners-inband-oam-requirements narrowscope the problem/opportunity area quite early:

Abstract

   This document discusses the motivation and requirements for including
   specific operational and telemetry information into data packets
   while the data packet traverses a path between two points in the
   network.  This method is referred to as "in-situ" Operations,
   Administration, and Maintenance (OAM)

My read of this is that:
1. There’s no overlap.
2. The problem and solution spaces fall squarely within the scope at https://datatracker.ietf.org/wg/opsawg/charter/

I agree, and would add that all these documents have received substantial input from operators, which is another reason for getting even more at opsawg.

I believe that these are four great pieces of input, which should be ironed out with WG input as a WG document. And that:

as an adoption poll, this is an area that would use WG input once adopted.

This is a quick fix. But yes, needs to be fixed :-)

I would state this quite differently. iOAM does not stop working in a brownfield, or when only some nodes support it.

It is, as such, a backwards compatible approach, in which legacy nodes are transparent.

But for new features we need to have new code, and here a good thing is that there is running code.

The experiment is ongoing in FD.io<http://FD.io> and other places, and hopefully the IETF does not fall behind. But this does beg another question for the WG, which is regarding the best intended status, and we would like WG input for it.

Why do I think these points should be addressed before adoption? I am worried that without looking at them first there will be an assumption that the document's is already set and 'radical' changes cannot be made.

The question on adoption as you know is whether the document provides a solid basis as a starting point, not if it is fixed.

I think that my points can be handled by:

These seem to be all good areas to work on and add. And in fact would love to have your text on the MTU area.

That’s interesting, because the Abstract is here ask well quite prescriptive:

Abstract

   This document defines
   mechanisms to securely prove that traffic transited said defined
   path.  These mechanisms allow to securely verify whether, within a
   given path, all packets traversed all the nodes that they are
   supposed to visit.

But I do not disagree that this document is slightly different than the other two being polled. It is an add-on in a way.

As part of adoption this can be worked on as editors/contributors as guided by the Chairs / ADs.

Thanks!

— Carlos.

Thanks,
Adrian

Hi All,

The question is:

Thanks,
Tianran & Warren

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 21 Dec 2016 06:41:12 +0000

Thanks again, Tianran and Adrian.

Please find a couple additional comments inline.

—

On Dec 16, 2016, at 1:28 AM, Zhoutianran <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Best,
Tianran
To: Zhoutianran; [email-masked]<mailto:[email-masked]>

Hi Tianran,

>> Agreed.

+1.

>> I also asked the authors about this question. Especially there is an overlay OAM design team in routing area. Their drafts and outputs show they also want to standardize a common OAM header for va…

It is indeed a fair question and I appreciate seeing it explicitly. The common OAM header for OAM probes on disparate transports seems orthogonal to the in-situ OAM (iOAM) requirement and approach. The in-situ OAM work also has code at https://fd.io/.

>> Thanks for your comments and suggestions.

Indeed, thanks again Adrian.

>> In my opinion, the objective of the POT draft is to demonstrate a solution for an applicable use case with in-situ OAM.

That is correct.

>> I think 5 authors is preferred. But at least the authors can add “Ed.” tag after the editors.

This is solvable and we take guidance.

Thanks,

— Carlos.

Thanks,
Adrian

Hi All,

The question is:

Thanks,
Tianran & Warren

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 21 Dec 2016 12:42:50 +0100

Quick reply,
I am in the hospital at the moment awaiting heart surgery.
So I am not going to dig up the pointers now (maybe in a few weeks if still needed).
Hope you or someone else can find the relevant pointers.
In any event, I believe that Benoit and Adrian are aware of all the other ongoing work.

Sorry,
Bert

On 21/12/2016 07:02, Carlos Pignataro (cpignata) wrote:
> Carlos Pignataro, [email-masked] <mailto:[email-masked]>
>
> /“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."/
>
>> On Dec 14, 2016, at 9:48 AM, Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>>
> Note that the title of this documents was renamed to “In-Situ” (with thanks to Erik Nordmark for the suggestion) so as to not
> confuse with the IETF definition of “inband”.
>
> “Telemetry” is such a broadly defined word that invariably, there will be “telemetry work” everywhere. When we focus and narrow
> scope on the actual specifics of in-situ OAM, that does not seem to be the case anymore.
>
> I believe it is a fair request to compare and contrast and understand a broader picture. But that request expects more specifics
> than a perhaps someone else should do it.
>
> Given the very specific requirements detailed by operators and vendors in draft-brockners-inband-oam-requirements-02.txt, the fact
> that we had to create a new descriptor (i.e., “In-Situ”) for this approach, and lack of specifics, it seems to me that the area of
> in-situ OAM is non-overlapping with other “telemetry" potential work elsewhere.
>
> Thanks,
>
> — Carlos.
>
>> Bert
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 25 Dec 2016 22:23:18 -0000

And just replying to the other email in the branched thread...

>> I am somewhat nervous about the overlap between this and OAM work 
>> undertaken in a number of working groups chiefly in the Routing Area,
>> and I hope there can be some careful coordination. 
>
> I understand the word “OAM” is overlapping with work happening elsewhere inside
> and outside the IETF. However, when we look right underneath the thin surface, the
> overlap quickly tends to zero.
>
> Looking at the OAM work in the RTG Area, and in particular the RTG-AD chartered
> Design Team, it seems to extend as far as defining an OAM protocol indication
> header pre-pended to specific OAM probe packets, modeled after the MPLS G-ACh.

That's fine. And it really shouldn't be hard or time-consuming to close this loop.
Two groups of people doing work. One group looks at the other's work and says "no overlap." Let's just ask the other group (perhaps through an AD or a DT lead?)

[snip]

> I believe that these are four great pieces of input, which should be ironed out with
> WG input as a WG document.

On the whole I am not someone who believes we should try to polish a document before adoption. in fact that annoys me. But see my note below on why I think these things should be ironed out first.

We seem to agree that either fixes or some direction would be easy to apply, so perhaps we can work on that and then adopt?

> And that:
>> - A thorough investigation of the numeric impact on the amount of data that can be sent.
>>  In other words, the change to the effective MTU
>

So, I think you are saying that if, once adopted we found that this approach required adding 1024 bytes to every packet [deliberately crass example!] the WG would be happy to ditch a WG draft. My (sad) experience is that once a document is adopted it has a sad an unfortunate life of its own. 

But, hey, this one isn't hard to resolve. We have a packet format and some code. So it is going to be really easy to say (ball park) how many bytes we're talking of adding into a data packet, and (roughly) how many packets in a flow this would be done to. Then everyone can quickly see that they are OK with the idea and we can move forward.

>> - The Abstract specifically says how encapsulation will be managed for IPv6.
>> Not only does the document later say that this is out of scope, but the
>> mechanism proposed in the Abstract is one that worries me.
>

Good. So just do it :-)
But which way do you intend to fix it? Is v6 in or out of scope?

>> - I don't like that the OAM only works if every node on the path
>> supports it. I would like for us to achieve some form of comfortable
>> b/w compatibility.
>
> I would state this quite differently. iOAM does not stop working in a
> brownfield, or when only some nodes support it. 
>

That is entirely good and proper.

Apologies, I may have misread the last paragraph in section 3.  I can't otherwise find anything that firmly says what I thought I had read although 3.1 does say...
   "In-situ OAM tracing data" is expected to be collected at every node
   that a packet traverses, i.e., in a typical deployment all nodes in
   an in-situ OAM-domain would participate in in-situ OAM and thus be
   in-situ OAM transit nodes, in-situ OAM encapsulating or in-situ OAM
   decapsulating nodes.
...which is probably a little stronger than intended.

Anyway, it's enough that you say brownfield progressive deployment is intended. Hopefully adding that note to the document is easy and we can work on the details later.

> The experiment is ongoing in FD.io and other places, and hopefully the IETF does
> not fall behind. But this does beg another question for the WG, which is regarding
> the best intended status, and we would like WG input for it.

Yes, a good question.
And nothing prevents a WG moving a document from one status to another if there is consensus.

I think running code is great, but it doesn't quite answer the questions, "How will you judge the success of the experiment?" and, "What is the nature of the garden wall you mean to employ?" 

>> Why do I think these points should be addressed before adoption? I am worried that
>> without looking at them first there will be an assumption that the document's is already
>> set and 'radical' changes cannot be made. 
>

Agreed.
And I am not asking for a fixed document. I am just asking what our direction is intended to be?
I'm sure our intention is not simply to document some running code.

So it's just a matter of a few lines of text to make sure we're all aligned on purpose and then away we go.
Perhaps we have already spent longer discussing than it would have taken to tweak the document as I suggested...

>> - Adding a section on b/w compatibility (maybe just as a placeholder) and cleaning
>>   up the text that requires every node on the path to support in-situ OAM.

Hmmm. I could take a stab after the break, but don't let me be the bottleneck.
If you have the code running it will be really simple to say things like the following and fill in the blanks.

"OAM trace is likely to add n bytes per hop. As noted, the maximum diameter of the network should be known in advance because of the total data needed to capture a path trace across the OAM domain. A reasonable assumption might be that an in-situ OAM has diameter of x hops so that tracing the route would add nx bytes and therefore applying this approach in networks where the MTU is less than y would be ill advised.

Furthermore, it should be noted that if in-situ OAM is applied to all packets in a flow it will reduce throughput by the corresponding number of OAM bytes. Therefore it is important to consider whether in-situ OAM can be applied to a <threshold> and that <configuration>. However, proof of transit may need to be applied to all packets if it forms part of validating a service or ensuring security, and so both the MTU and throughput issue may apply.

Section 4.2 of [in-situ-reqs] discusses the implications for MTU of carrying in-situ OAM."

>> As for the proof of transit work, I think it is a bit of a mess at the moment. It 
>> seems to be growing new approaches and options, each with drawbacks and
>> protocol solution, and that might make the document better suited to the
>> NMRG. So I would like to apply a bit more caution to that document.
>

Per my other email, part of the problem is with the plurality of "mechanisms". Is the intention to research the different mechanisms and narrow down, or is it to have a single solution with multiple options depending on the precise features that the application demands?

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 25 Dec 2016 22:23:18 -0000

Oh, how I hate HTML emails!

Hi Carlos,

>> I also asked the authors about this question. Especially there is an overlay
>> OAM design team in routing area. Their drafts and outputs show they also
>> want to standardize a common OAM header for various transport. 
> 
> It is indeed a fair question and I appreciate seeing it explicitly. The common
> OAM header for OAM probes on disparate transports seems orthogonal to
> the in-situ OAM (iOAM) requirement and approach. 

So, I'm just wondering out loud...
If there is a common generic format for some OAM data being developed, would it be sensible to use any of the pieces that can be used? Perhaps there are none - should be easy to establish.

I suspect that what you are doing is distinct from any of the MPLS OAM developed over the last 5 years, but it may be worth consulting with them as to why they considered it necessary to use separate packets and not "overload" (apologies for the implicit negativity in that term) data packets.

> The in-situ OAM work also has code at https://fd.io/.

Good. Code is nice.

>>> My feeling is that we should start with the requirements draft at once.

[snip]

>>> I think that the data format document may be close to being ready for adoption

[snip]

>>> moment. It seems to be growing new approaches and options, 
>>> each with drawbacks and issues. And I'm not clear on the objectives.
>>> This might be handled as with the previous document by describing
>>> and scoping the experiment, but as currently written, it would appear
>>> that the intention is to research a number of potential approaches to
>>> proof of transit rather than to experiment with a particular protocol
>>> solution, and that might make the document better suited to the
>> In my opinion, the objective of the POT draft is to demonstrate a solution
>> for an applicable use case with in-situ OAM.
>
> That is correct. 

Weeeeeell, doesn't the current document describe a mechanism, an enhanced mechanism, a final version, and an alternative approach?

That would be very good if the intention is to kick some ideas around the park and see what stands up, what features work, and what additions we need. What we would need to do in that case is decide what our objectives are (trusted or non-trusted players, proof of order or just proof of transit, proof of adjacency / non-insertion, etc., etc.) so that we can work on the solution for our needs.

The feeling I get from the document is that it is (and has been for a few revisions) pushing ideas around to see what might be good and what needs more work. That is actually great, but (again) our assessment of what is "good" depends on what objectives we're trying to meet.  I suppose my nervousness may be that if we adopt this document as is, then weeding out features or approaches may be hard because their inclusion at the time of adoption could be claimed as consensus in the WG that they are things we should be doing. I would like us just to pause a moment and agree the objectives. Then we'd be good to go.

Cheers,
Adrian

---

From: Nobo Akiya <[email-masked]>
Date: Tue, 27 Dec 2016 13:37:39 +0900

Hi Tianran & Warren,

I agree with the intents/benefits that proposal can offer.

I do worry about added bytes required to every In Situ packet (i.e., MTU).

(1) Is the proposal being too flexible? For example, data like opaque
application data can be powerful, but it can easily eat up lots of MTU.
OAM-trace-type can complicate implementations as included data (and their
offset) can vary for each bit combinations.

(2) Are all data fields defined as right size? Considering that node ID is
defined as 24 bits and interface ID is defined as 16 bits, I'm assuming
that they are IDs defined by a centralized controller/orchestrator. If so,
do they really need all to be that large?

One thought is to start off with couple of "tight" data types (not flexible
& least bits required) which addresses majority and/or high priority use
cases. With this approach, it will also simplify the "error handlings"
which the documents are lacking (and needs some attention if documents are
adopted by the WG).

> Do you think that the WG should adopt all or some of these drafts?

RE:

Yes, I'd like to see this work moving forward.

RE: https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt

Yes, I'd like to see this work moving forward.

RE: https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt

No, I'm not quite sure why this document is needed.

> It would be helpful if you could indicate whether you have read the
drafts. If "yes", would you like to review the drafts and help to improve
the drafts?

Yes, I have read the documents. For the first two documents, I do plan to
further review.

Regards,

Nobo

On Wed, Dec 7, 2016 at 3:36 PM, Zhoutianran <[email-masked]> wrote:

> drafts. If "yes", would you like to review the drafts and help to improve
> the drafts? If "no", it is important that you provide reasons.
>
>
>