Subject: [ippm] Vote at IPPM session

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Mar 2017 11:25:15 -0500

Dear Spencer, Brian and Bill,
I apologize but I've missed the exact question that all present at the IPPM
meeting were asked to vote on. Could you please kindly re-state it?

Regards,
Greg

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Mar 2017 18:49:27 +0200

hi Greg,

The hum we took was: Do you think that the IOAM draft(s) (in some form) should be brought into IPPM, regardless of charter (i.e., with the intention that the WG would recharter as necessary in order to allow the IOAM work to go forward in IPPM); second, we'd appreciate those who have concerns that caused them to hum against to bring those to the list for discussion.

Thanks, cheers,

Brian

> On 28 Mar 2017, at 18:25, Greg Mirsky <[email-masked]> wrote:
> 
> I apologize but I've missed the exact question that all present at the IPPM meeting were asked to vote on. Could you please kindly re-state it?
> 
> Regards,
> Greg
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Mar 2017 12:03:16 -0500

Hi Brian,
thank you for the most detailed clarification. My first concern is with the
scope of the question set to those present at the meeting. I find four
drafts related to iOAM:

   - draft-brockners-inband-oam-requirements
   - draft-brockners-inband-oam-transport
   - draft-brockners-inband-oam-data
   - draft-brockners-proof-of-transit

Out of these four drafts I see only draft-brockners-inband-oam-data as
being reasonably close to scope of IPPM WG, with or without re-chartering.
Other drafts, in my view, are too closely related to particular networking,
in fact, overlay networking, technologies so that their discussion is more
appropriate in respective WGs of the Routing Area (or in one of them taking
on that role). Thus my hum vote was out of concern with the question being
formulated too broadly and without, in my view, sufficient discussion by
the WG of relevance of each draft, not all of them as a package to IPPM WG.

Regards,
Greg

On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> hi Greg,
>
> The hum we took was: Do you think that the IOAM draft(s) (in some form)
> should be brought into IPPM, regardless of charter (i.e., with the
> intention that the WG would recharter as necessary in order to allow the
> IOAM work to go forward in IPPM); second, we'd appreciate those who have
> concerns that caused them to hum against to bring those to the list for
> discussion.
>
> Thanks, cheers,
>
> Brian
>
>
> > I apologize but I've missed the exact question that all present at the
> IPPM meeting were asked to vote on. Could you please kindly re-state it?
> >
> > Regards,
> > Greg

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Mar 2017 18:31:16 +0100

I also found the question a bit problematic and found myself inclined to hum both for and against.
 
My point (sadly I have made this point a couple of times now) is that the data format we work on, the encapsulations we define for different transports, and the whole proof of concept thing are all dependent on the scope of the problem we are trying to solve.
 
While we can all sort of agree roughly on the sort of problem we might be working on, there are some pretty large elephants on which we have yet to shed light.
The example I gave at the mic was a case raised by Mirja in the meeting, viz. if this a technique that is applied only at the start of some form of tunnel? That is, is the addition of OAM "overhead" *only* happening at the same time as addition of encapsulation overhead? As I recall (but I am old and prone to misremembering) the answer delivered to Mirja was "Yes, you could apply iOAM to tunnels" which, IMHO, was not an answer to her question.
 
So, I would really, really, like to see some WG somewhere adopt draft-brockners-inband-oam-requirements so that we can build consensus on the scope of the project. That will allow later work to move much more smoothly. I think Frank suggested that the IESG statement on requirements RFCs meant that we didn't need to do this and could either abandon the requirements work or progress the two in parallel. But I find that the potential variation in the solutions is so wide that without knowing what we are trying to achieve it is hard to say that adopting a particular draft as "a good starting point for future work in the working group" would be a good idea. 
 
To be clear, I am not saying that we have to publish a requirements RFC before we can start solutions work. I am saying that we must have consensus on scope before we progress solutions work.
 
Thanks,
Adrian
 
From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 28 March 2017 18:03
To: Brian Trammell (IETF)
Cc: IPPM Chairs; [email-masked]
Subject: Re: [ippm] Vote at IPPM session
 
Hi Brian,
thank you for the most detailed clarification. My first concern is with the scope of the question set to those present at the meeting. I find four drafts related to iOAM:
*	draft-brockners-inband-oam-requirements
*	draft-brockners-inband-oam-transport
*	draft-brockners-inband-oam-data
*	draft-brockners-proof-of-transit
Out of these four drafts I see only draft-brockners-inband-oam-data as being reasonably close to scope of IPPM WG, with or without re-chartering. Other drafts, in my view, are too closely related to particular networking, in fact, overlay networking, technologies so that their discussion is more appropriate in respective WGs of the Routing Area (or in one of them taking on that role). Thus my hum vote was out of concern with the question being formulated too broadly and without, in my view, sufficient discussion by the WG of relevance of each draft, not all of them as a package to IPPM WG.
 
Regards,
Greg
 
On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) <[email-masked]> wrote:
hi Greg,

Thanks, cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Mar 2017 21:36:57 +0200

hi Adrian, Greg, all,

As chair... Indeed, we could (should) have asked a more precise
question, but given that we didn't really have a more precise intention,
beyond to determine the sense of the room about "does IOAM (in some
guise) fit in IPPM", this is precisely the discussion we were hoping to
start. :)

As an individual...

What I'm hearing from Greg: The information elements (and presumably,
how they can be used by devices on path to perform hybrid measurements)
is/may be in scope for IPPM, anything binding this to particular overlay
technologies is only in scope for the working groups with responsibility
for those technologies.

This seems reasonable to me. I will note that one reason that this set
of drafts has had a hard time finding a home is that it cuts across
areas in a way that it's pretty easy for each area to look at it and say
"interesting, maybe, related, maybe, but definitely not our problem".
Picking up a core *somewhere* then delegating more finely scoped work to
other WGs is one way to make this work.

What I'm hearing from Adrian: It's too early to talk about data models,
we don't know what the problem is yet. Let's define the problem (i.e.,
the metrics we want to define methodologies for, in IPPM terms) first,
so a good first step would be adopting the requirements document in IPPM.

This seems reasonable to me, as well. Whether or not publishing a
requirements document happens, adopting it to work on it seems like a
good way for the WG to determine if it'd like to bring other documents
later.

Cheers,

Brian

P.S. I'm about to head out on the travel that's the reason I'm not in
Chicago, so I'll return to this discussion in mid-April.

On 03/28/2017 07:31 PM, Adrian Farrel wrote:
> My point (sadly I have made this point a couple of times now) is that
> the data format we work on, the encapsulations we define for different
> transports, and the whole proof of concept thing are all dependent on
> the scope of the problem we are trying to solve.
> 
>  
> 
> While we can all sort of agree roughly on the sort of problem we might
> be working on, there are some pretty large elephants on which we have
> yet to shed light.
> 
> The example I gave at the mic was a case raised by Mirja in the meeting,
> viz. if this a technique that is applied only at the start of some form
> of tunnel? That is, is the addition of OAM "overhead" *only* happening
> at the same time as addition of encapsulation overhead? As I recall (but
> I am old and prone to misremembering) the answer delivered to Mirja was
> "Yes, you could apply iOAM to tunnels" which, IMHO, was not an answer to
> her question.
> 
>  
> 
> So, I would really, really, like to see some WG somewhere adopt
> draft-brockners-inband-oam-requirements so that we can build consensus
> on the scope of the project. That will allow later work to move much
> more smoothly. I think Frank suggested that the IESG statement on
> requirements RFCs meant that we didn't need to do this and could either
> abandon the requirements work or progress the two in parallel. But I
> find that the potential variation in the solutions is so wide that
> without knowing what we are trying to achieve it is hard to say that
> adopting a particular draft as "a good starting point for future work in
> the working group" would be a good idea.
> 
>  
> 
> To be clear, I am not saying that we have to publish a requirements RFC
> before we can start solutions work. I am saying that we must have
> consensus on scope before we progress solutions work.
> 
>  
> 
> Thanks,
> 
> Adrian
> 
>  
> 
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* 28 March 2017 18:03
> *To:* Brian Trammell (IETF)
> *Cc:* IPPM Chairs; [email-masked]
> *Subject:* Re: [ippm] Vote at IPPM session
> 
>  
> 
> Hi Brian,
> 
> thank you for the most detailed clarification. My first concern is with
> the scope of the question set to those present at the meeting. I find
> four drafts related to iOAM:
> 
> being reasonably close to scope of IPPM WG, with or without
> re-chartering. Other drafts, in my view, are too closely related to
> particular networking, in fact, overlay networking, technologies so that
> their discussion is more appropriate in respective WGs of the Routing
> Area (or in one of them taking on that role). Thus my hum vote was out
> of concern with the question being formulated too broadly and without,
> in my view, sufficient discussion by the WG of relevance of each draft,
> not all of them as a package to IPPM WG.
> 
>  
> 
> Regards,
> 
> Greg
> 
>  
> 
> On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF)
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> hi Greg,
> 
>> On 28 Mar 2017, at 18:25, Greg Mirsky <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 28 Mar 2017 17:52:06 -0500

Dear All,

> guise) fit in IPPM", this is precisely the discussion we were hoping to

That's what I was hoping for, and I haven't seen much mailing list traffic
on IOAM, so I'm assuming this was close to the first time many folks had
seen it. So, all is proceeding according to plan. See comments below.

> good way for the WG to determine if it'd like to bring other documents

Even though Brian said "as an individual", I would defer to him and to Bill
on the path forward, but (now I'M speaking as an individual), I think the
question Mirja asked is critical to answer. I'd have to check the tape, but
I thought I remembered Frank saying that this could be added by a host, and
that would open up a lot of security questions, so understanding the scope
would be an excellent thing.

I expect that if Frank could say "added by tunnel encapsulators at
encapsulation time with scope within a managed domain" (or not), that's
what the working group would what to know.

It's certainly what I was curious about ...

Now, back to speaking as the responsible AD ....

Please recognize that people aren't asking how IOAM could be used in
theory, but how the IESG should evaluate the draft for publication.

The various ADs would need to know where IOAM should be used, in order to
evaluate transport considerations, security considerations, and (likely)
operation considerations.

Does that make sense?

Thanks,

Spencer

---

From: Sarah B <[email-masked]>
Date: Tue, 28 Mar 2017 16:07:19 -0700

Given the lack of conversation on this, I thought I'd ask here, rather than in the room at the time.

I was a bit surprised at how many people were in favor of IOAM coming into IPPM. I wanted to ask the authors this: the in-room presentation started with the pitch that today, it's difficult to get a real read on your true speed, because some SPs prioritize websites like speedtest.net, and so you get false results (and often ludicrously favorable results, I might add :)). If SPs are willing to prioritize the probe traffic today, what makes us so sure they won't prioritize the IOAM traffic? Or, not enable this information at each hop (as an option, I realize) in the first place? Would that relegate the use(s) to tunnels only, where the tunnels are effectively host originated/terminated?

Thanks
Sarah

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 28 Mar 2017 23:30:01 +0000

Hi Sarah,

the whole point is that IOAM isn't probe traffic, but IOAM are data-fields that are carried within your live user traffic. We could consider adding IOAM meta-data to *all* your user traffic. If the SP would choose to prioritize IOAM tagged traffic, then all traffic would be prioritized. 

IOAM is a domain-focused feature, with "domain" being a set of network devices under a single administration, e.g. an Enterprise campus using physical connections between devices or an overlay network using virtual connections / tunnels for connectivity between devices.  In the latter case the statement about tunneling applies. As a consequence, you could consider IOAM be added at domain ingress and be removed at domain egress - so that it gives you visibility into the QoE that your live user traffic observes. Note that IOAM isn't exclusively focused on being added by tunnel endpoints. The operator of a domain could also choose to have hosts insert the IOAM data-fields into the traffic. The draft-brockners-inband-oam-transport sketches out a couple of ideas how IOAM data-fields could be transported by a variety of transport protocols - though those should be considered examples only, because the definition would need to happen in the WGs which define those transports.

Frank

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Sarah B
Sent: Dienstag, 28. März 2017 18:07
To: [email-masked]
Subject: [ippm] IOAM in IPPM

Thanks
Sarah

---

From: Sarah B <[email-masked]>
Date: Tue, 28 Mar 2017 16:42:37 -0700

Hi Frank,

> On Mar 28, 2017, at 4:30 PM, Frank Brockners (fbrockne) <[email-masked]> wrote:
> 
> Hi Sarah,
> 

I totally understand your point, you don't consider this probe traffic, thanks for clarifying. I do privately share the concern of exactly how much data you're adding to *all* of my user traffic though, and I do recall that you had a couple of options that didn't require that traffic be added to each packet, which I'd encourage you to explore.

> IOAM is a domain-focused feature, with "domain" being a set of network devices under a single administration, e.g. an Enterprise campus using physical connections between devices or an overlay netw…

I appreciate this point the more I read it; having it be domain specific, rather than Internet-wide (which, honestly, I had inferred from your presentation all the way to the end, when Brian actually asked about this :)) Thanks for calling that out here, perhaps that'll help folks who were uncomfortable with this work coming in.

Finally, thanks for the quick replies, Frank. i appreciate them.

Thanks,
Sarah

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 29 Mar 2017 13:37:36 +0000

The discussion leaves me a little confused. Per Spencer’s note, it would indeed be good if Brian and Bill could provide guidance on the path forward.

My recollection of the discussion was pretty straight forward: Per the meeting agenda, the presentation and the discussion focused on draft-brockners-inband-oam-data, followed by an ask for adoption. At the end of the discussion we had a “in favor” hum for adoption. Hence IMHO all we’d need to do is confirm the decision on the list.
There were several questions related to scope and applicability in the WG discussion – and even more recently on the list. Those can easily be addressed by adding paragraph on applicability to draft-brockners-inband-oam-data – there isn’t a need for a dedicated requirements document. This paragraph could loan from draft-brockners-inband-oam-requirements – and clarify things like for example the domain-scope of IOAM. Starting off with exclusively working on a requirements document would be counter-productive. As stated during the WG meeting, chip makers put IOAM into silicon as we speak – hence now is the time to provide appropriate implementation guidance.

And another note on the “where could IOAM be applied” question discussed further below: Per what I mentioned to Sarah on the other thread: IOAM is a domain-focused feature, with "domain" being a set of network devices under a single administration, e.g. an Enterprise campus using physical connections between devices or an overlay network using virtual connections / tunnels for connectivity between devices.  In the latter case the statement about tunneling applies. As a consequence, you could consider IOAM be added at domain ingress and be removed at domain egress - so that it gives you visibility into the QoE that your live user traffic observes. IOAM isn't exclusively focused on being added by tunnel endpoints. The operator of a domain could also choose to have hosts insert the IOAM data-fields into the traffic. The draft-brockners-inband-oam-transport sketches out a couple of ideas how IOAM data-fields could be transported by a variety of transport protocols - though those should be considered examples only, because the definition would need to happen in the WGs which define those transports. Per what I said above, we’d obviously include those notes into the afore mentioned paragraph on applicability.

Thoughts?

Thanks, Frank

From: ippm [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Dienstag, 28. März 2017 17:52
To: Brian Trammell (IETF) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>; [email-masked]
Subject: Re: [ippm] Vote at IPPM session

Dear All,

On Tue, Mar 28, 2017 at 2:36 PM, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
hi Adrian, Greg, all,

That's what I was hoping for, and I haven't seen much mailing list traffic on IOAM, so I'm assuming this was close to the first time many folks had seen it. So, all is proceeding according to plan. See comments below.

As an individual...

Even though Brian said "as an individual", I would defer to him and to Bill on the path forward, but (now I'M speaking as an individual), I think the question Mirja asked is critical to answer. I'd have to check the tape, but I thought I remembered Frank saying that this could be added by a host, and that would open up a lot of security questions, so understanding the scope would be an excellent thing.

I expect that if Frank could say "added by tunnel encapsulators at encapsulation time with scope within a managed domain" (or not), that's what the working group would what to know.

Please recognize that people aren't asking how IOAM could be used in theory, but how the IESG should evaluate the draft for publication.

The various ADs would need to know where IOAM should be used, in order to evaluate transport considerations, security considerations, and (likely) operation considerations.

Does that make sense?

Thanks,

Spencer

Cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 29 Mar 2017 13:47:32 -0500

I'll go back to "let the chairs chair IPPM" mode, but I do want to thank
Frank for clarifying the scope for IOAM, and for quick responses.

I expect that's a critical point for people who are looking at IOAM.

Spencer

On Mar 28, 2017 6:42 PM, "Sarah B" <[email-masked]> wrote:

> > the whole point is that IOAM isn't probe traffic, but IOAM are
> data-fields that are carried within your live user traffic. We could
> consider adding IOAM meta-data to *all* your user traffic. If the SP would
> choose to prioritize IOAM tagged traffic, then all traffic would be
> prioritized.
> >
>
> I totally understand your point, you don't consider this probe traffic,
> thanks for clarifying. I do privately share the concern of exactly how much
> data you're adding to *all* of my user traffic though, and I do recall that
> you had a couple of options that didn't require that traffic be added to
> each packet, which I'd encourage you to explore.
>
> > IOAM is a domain-focused feature, with "domain" being a set of network
> devices under a single administration, e.g. an Enterprise campus using
> physical connections between devices or an overlay network using virtual
> connections / tunnels for connectivity between devices.  In the latter case
> the statement about tunneling applies. As a consequence, you could consider
> IOAM be added at domain ingress and be removed at domain egress - so that
> it gives you visibility into the QoE that your live user traffic observes.
> Note that IOAM isn't exclusively focused on being added by tunnel
> endpoints. The operator of a domain could also choose to have hosts insert
> the IOAM data-fields into the traffic. The draft-brockners-inband-oam-transport
> sketches out a couple of ideas how IOAM data-fields could be transported by
> a variety of transport protocols - though those should be considered
> examples only, because the definition would need to happen in the WGs which
> define those transports.
> >
>
> I appreciate this point the more I read it; having it be domain specific,
> rather than Internet-wide (which, honestly, I had inferred from your
> presentation all the way to the end, when Brian actually asked about this
> :)) Thanks for calling that out here, perhaps that'll help folks who were
> uncomfortable with this work coming in.
>
> > I was a bit surprised at how many people were in favor of IOAM coming
> into IPPM. I wanted to ask the authors this: the in-room presentation
> started with the pitch that today, it's difficult to get a real read on
> your true speed, because some SPs prioritize websites like speedtest.net,
> and so you get false results (and often ludicrously favorable results, I
> might add :)). If SPs are willing to prioritize the probe traffic today,
> what makes us so sure they won't prioritize the IOAM traffic? Or, not
> enable this information at each hop (as an option, I realize) in the first
> place? Would that relegate the use(s) to tunnels only, where the tunnels
> are effectively host originated/terminated?
> >
> > Thanks
> > Sarah
> >

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 29 Mar 2017 21:51:01 +0200

hi Frank, all,

Briefly -- I'm off for zero email vacation through mid-April in a few hours...

> On 29 Mar 2017, at 15:37, Frank Brockners (fbrockne) <[email-masked]> wrote:
> 
> 

From what was reported to me -- audio wasn't great -- there was more "opposed" hum than we generally like to hear in IPPM, which is why Bill asked for the discussion on the dissent to move to the list.

> There were several questions related to scope and applicability in the WG discussion – and even more recently on the list. Those can easily be addressed by adding paragraph on applicability to draft-brockners-inband-oam-data – there isn’t a need for a dedicated requirements document.

I tend to agree with this, although "a paragraph" seems a little thin to me. I think there were some valid points made in that discussion about the scope of the proposal that should be addressed: is IOAM meant for use tunnel-end-to-tunnel-end environment,  end-host-to-end-host, within a single network and/or across the Internet.  What I would suggest is adding a section to the data model draft on applicability and assumptions about the environment -- both about the devices adding IOAM signals to traffic as well as those consuming these signals from the wire and analyzing them (possibly with the cooperation of devices not on the wire) -- submitting a new revision, and we can run a more formal adoption call on that.

Cheers,

Brian

> This paragraph could loan from draft-brockners-inband-oam-requirements – and clarify things like for example the domain-scope of IOAM. Starting off with exclusively working on a requirements document would be counter-productive. As stated during the WG meeting, chip makers put IOAM into silicon as we speak – hence now is the time to provide appropriate implementation guidance.
> 
> On Tue, Mar 28, 2017 at 2:36 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> hi Adrian, Greg, all,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Mar 2017 22:32:00 +0100

> > There were several questions related to scope and applicability in the WG
> discussion – and even more recently on the list. Those can easily be addressed by
> adding paragraph on applicability to draft-brockners-inband-oam-data – there
> isn’t a need for a dedicated requirements document.
> 
> I tend to agree with this, although "a paragraph" seems a little thin to me. I think
> there were some valid points made in that discussion about the scope of the
> proposal that should be addressed: is IOAM meant for use tunnel-end-to-tunnel-
> end environment,  end-host-to-end-host, within a single network and/or across
> the Internet.  What I would suggest is adding a section to the data model draft on
> applicability and assumptions about the environment -- both about the devices
> adding IOAM signals to traffic as well as those consuming these signals from the
> wire and analyzing them (possibly with the cooperation of devices not on the
> wire) -- submitting a new revision, and we can run a more formal adoption call on
> that.

Although I was one of the people raising the "need" for the scope and requirements, I don't have a strong leading on whether this needs to be in a separate document on folded into the data format document. So Brian's proposal would work for me.

Thus, I'd love to see this scoping text drafted and floated to the list as an email or in a revision of the data format document.

Cheers,
Adrian

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 29 Mar 2017 23:10:51 +0000

> From: ippm [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, March 29, 2017 5:32 PM
> To: 'Brian Trammell (IETF)'; 'Frank Brockners (fbrockne)'
> Cc: 'IPPM Chairs'; [email-masked]
> > proposal that should be addressed: is IOAM meant for use tunnel-end- to-tunnel-
> Although I was one of the people raising the "need" for the scope and
> requirements, I don't have a strong leading on whether this needs to be
> in a separate document on folded into the data format document. So
> Brian's proposal would work for me.
> 
> Thus, I'd love to see this scoping text drafted and floated to the list
> as an email or in a revision of the data format document.
> 
> Cheers,
> Adrian
[ACM] 

+1 for adding a Scope section to
https://tools.ietf.org/html/draft-brockners-inband-oam-data-02

I felt that I understood the scope going into the discussion Monday
and the applicable (restricted) domain (I did the homework, 
the single draft Frank introduced on the mailing list was [0] ).

Some additional questions have been raised (e.g., "where will 
OAM be inserted and removed?") and I'd like to see those items 
sorted-out before we go very far (the advantage of wider review).

The requirements draft only came-up when I asked some questions
on the list. Frank mentioned that the our list discussion on equivalent 
treatment of OAM & non-OAM packets ("class C") was added to the
requirements document, and that should move to -oam-data- too.
 
It would be good to have a version of the scope to review ASAP.

thanks and regards,
Al

[0] https://tools.ietf.org/html/draft-brockners-inband-oam-data-02

> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=GaqucztK57fTj3vyYcMnHG9YKL1
> tVkASQ5C3Kh63ooA&s=MesM6BFZyEkVPqsGq2Ho4LKS_A4ntf5X5hL0Sx0Rsdc&e=

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 31 Mar 2017 14:27:47 +0000

Thanks for the suggestions and comments. We've posted a new revision of draft-brockners-inband-oam-data.
https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt includes section 3 on Scope, Applicability, and Assumptions, capturing the discussion we had in the WG meeting and on the list. We've also updated the introduction to refer to RFC7799 and classify in-situ OAM appropriately as hybrid, type-1 OAM.

For everyone's benefit, here is a quote of the new section 3:

3.  Scope, Applicability, and Assumptions

   In-situ OAM deployment assumes a set of contraints, 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,
   VXLAN-GPE, Geneve, IPv6, or IPv4.  Encapsulation details for these
   different transport protocols are outside the scope of this document.

   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 perimiter or edge.  The operator
   of such a domain MUST put provisions in place to ensure that in-situ
   OAM data stays within the specific domain only (i.e., does not leak
   beyond the edge) and consider potential impact of IOAM to ECMP
   processing, path MTU and ICMP message handling.

   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.

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

Thoughts/comments? With these changes, are we able to kick-off an adoption call?

Thanks, Frank

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Mittwoch, 29. März 2017 18:11
To: [email-masked]; 'Brian Trammell (IETF)' <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>
Cc: 'IPPM Chairs' <[email-masked]>; [email-masked]
Subject: RE: [ippm] Vote at IPPM session

> > discussion – and even more recently on the list. Those can easily be 
> > addressed by adding paragraph on applicability to 
> > draft-brockners-inband-oam-data – there isn’t a need for a dedicated requirements document.
> >
> > I tend to agree with this, although "a paragraph" seems a little 
> > thin to me. I think there were some valid points made in that 
> > discussion about the scope of the proposal that should be addressed: 
> > is IOAM meant for use tunnel-end- to-tunnel- end environment,  
> > end-host-to-end-host, within a single network and/or across the 
> > Internet.  What I would suggest is adding a section to the data 
> > model draft on applicability and assumptions about the environment 
> > -- both about the devices adding IOAM signals to traffic as well as 
> > those consuming these signals from the wire and analyzing them 
> > (possibly with the cooperation of devices not on the
> > wire) -- submitting a new revision, and we can run a more formal 
> > adoption call on that.
> 
> requirements, I don't have a strong leading on whether this needs to 
> be in a separate document on folded into the data format document. So 
> Thus, I'd love to see this scoping text drafted and floated to the 
> list as an email or in a revision of the data format document.
> 
> Cheers,
> Adrian
[ACM] 

I felt that I understood the scope going into the discussion Monday and the applicable (restricted) domain (I did the homework, the single draft Frank introduced on the mailing list was [0] ).

Some additional questions have been raised (e.g., "where will OAM be inserted and removed?") and I'd like to see those items sorted-out before we go very far (the advantage of wider review).

The requirements draft only came-up when I asked some questions on the list. Frank mentioned that the our list discussion on equivalent treatment of OAM & non-OAM packets ("class C") was added to the requirements document, and that should move to -oam-data- too.

thanks and regards,
Al

> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=GaqucztK57fTj3vyYcMnHG9YK
> L1 tVkASQ5C3Kh63ooA&s=MesM6BFZyEkVPqsGq2Ho4LKS_A4ntf5X5hL0Sx0Rsdc&e=