Subject: Re: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Nov 2017 10:36:23 +0800

Dear WG Chairs, et. al,
in their presentation in Singapore the iOAM team pointed to interest in
using the extra header right after the GENEVE encapsulation. I've looked at
their proposal and believe that the OOAM header, as proposed in
the draft-ooamdt-rtgwg-ooam-header, may suit iOAM as well as active OAM in
GENEVE. With that said, would the WG consider adoption
of draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv?

Regards,
Greg

On Fri, Mar 31, 2017 at 11:34 PM, Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> This email begins a two week poll for adoption of draft-ooamdt-rtgwg-ooam-header-03
> in the NVO3 working group.
>
>
>
> Please review the draft and send any comments to the NVO3 list.
>
> Please also indicate whether you support adoption of the draft as an NVO3
> working group document.
>
>
>
> Simultaneously, we are also poling for any IPR that may apply to the draft.
>
>
>
> Authors and contributors, are you aware of any IPR that applies to this
> draft?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details)?
>
> If you are listed as a document author or contributor, please respond to
>
> this email stating of whether or not you are aware of any relevant
>
> IPR. The response needs to be sent to the NVO3 WG mailing list. The
>
> document will not advance to the next stage until a response
>
> has been received from each author and each contributor.
>
>
>
> This poll closes on Friday 14th April 2017.
>
>
>
> Regards
>
>
>
> Matthew and Sam
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 17 Nov 2017 11:16:51 -0800

On Nov 16, 2017, at 6:36 PM, Greg Mirsky <[email-masked]> wrote:
> 
> Dear WG Chairs, et. al,
> in their presentation in Singapore the iOAM team pointed to interest in using the extra header right after the GENEVE encapsulation. I've looked at their proposal and believe that the OOAM header, as proposed in the draft-ooamdt-rtgwg-ooam-header, may suit iOAM as well as active OAM in GENEVE. With that said, would the WG consider adoption of draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv?

In draft-ooamdt-rtgwg-demand-cc-cv, I don't see a way an arbitrary-length payload can be sent, which is necessary to ensure the path MTU is sufficient to carry actual traffic.  Is there some other way to meet that need, perhaps with the "TLVs" field in Figure 1?

In draft-ooamdt-rtgwg-demand-cc-cv, its Security Considerations says it is 'highly unlikely' for an attacker to know the sender's Handle and Sequence number.  However, the I-D provides no guidance for how those values should be securely generated.  The document should provide some guidance such as that the Handle be a PRNG value, and perhaps also that the sequence number should start at a random value.

In draft-ooamdt-rtgwg-demand-cc-cv, it doesn't normatively say how the sequence number is supposed to be handled.  Does it *need* to increase monotonically, or can it be treated more like a transaction number (thus allowing random values to be assigned and mapped to the originating packet as desired).  Are there interoperability issues with an implementation handling this differently -- imagine if sender has one idea of what to do, but receiver or an on-path packet analyzer has a different expectation.

(I adjusted the subject line to reflect the call-for-adoption that I am responding to.  It was odd to see a call for adoption mention one I-D, but in the text it is calling for adoption of two I-Ds.)

-d

> 
> Regards,
> Greg
> 
> On Fri, Mar 31, 2017 at 11:34 PM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> This email begins a two week poll for adoption of draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group.
> 
>  
> 
> Please also indicate whether you support adoption of the draft as an NVO3 working group document.
> 
>  
> 
> Authors and contributors, are you aware of any IPR that applies to this draft?
> 
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> 
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 25 Nov 2017 15:49:12 -0800

Hi Dan,
thank you for your thorough review of the cc-cv draft and very helpful
comments. As I understand, the adoption call for both documents ran its
course and had not brought enough support from the WG. Please find my
answers and notes in-line tagged GIM>>.

Regards,
Greg

On Fri, Nov 17, 2017 at 11:16 AM, Dan Wing <[email-masked]> wrote:

> their proposal and believe that the OOAM header, as proposed in the
> draft-ooamdt-rtgwg-ooam-header, may suit iOAM as well as active OAM in
> GENEVE. With that said, would the WG consider adoption of
> draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv?
>
> In draft-ooamdt-rtgwg-demand-cc-cv, I don't see a way an arbitrary-length
> payload can be sent, which is necessary to ensure the path MTU is
> sufficient to carry actual traffic.  Is there some other way to meet that
> need, perhaps with the "TLVs" field in Figure 1?
>
GIM>> You're correct, the plan is to use Payload type TLV to create test
packets of desired length.

>
> In draft-ooamdt-rtgwg-demand-cc-cv, its Security Considerations says it
> is 'highly unlikely' for an attacker to know the sender's Handle and
> Sequence number.  However, the I-D provides no guidance for how those
> values should be securely generated.  The document should provide some
> guidance such as that the Handle be a PRNG value, and perhaps also that the
> sequence number should start at a random value.
>
GIM>> Excellent, thank you! Will use your suggestions in the next version
of the draft.

>
> In draft-ooamdt-rtgwg-demand-cc-cv, it doesn't normatively say how the
> sequence number is supposed to be handled.  Does it *need* to increase
> monotonically, or can it be treated more like a transaction number (thus
> allowing random values to be assigned and mapped to the originating packet
> as desired).  Are there interoperability issues with an implementation
> handling this differently -- imagine if sender has one idea of what to do,
> but receiver or an on-path packet analyzer has a different expectation.
>
GIM>> Echo request/reply can be used as synthetic traffic to measure packet
loss. In such scenario the sequence number must be incremented for each
transmitted packet. I agree that statement that the sequence number is
monotonically increasing in course of the given test session is very
helpful and will add it in the next version. I think that should set
correct and unambiguous expectations on part of changes in the sequence
number at the receiver of echo request or on-path analyzer. The Handle has
been defined as transaction number, i.e. test session ID, and must remain
unchanged through the course of the particular test session.

> (I adjusted the subject line to reflect the call-for-adoption that I am
> responding to.  It was odd to see a call for adoption mention one I-D, but
> in the text it is calling for adoption of two I-Ds.)
>
> -d
>
>
> >
> > Regards,
> > Greg
> >
> > This email begins a two week poll for adoption of
> draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group.
> >
> >
> >
> > If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> >
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 04:56:33 +0000

On Nov 17, 2017, at 2:16 PM, Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 16, 2017, at 6:36 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG Chairs, et. al,
in their presentation in Singapore the iOAM team pointed to interest in using the extra header right after the GENEVE encapsulation. I've looked at their proposal and believe that the OOAM header, as proposed in the draft-ooamdt-rtgwg-ooam-header, may suit iOAM as well as active OAM in GENEVE.

As an author of iOAM, draft-ooamdt-rtgwg-ooam-header is not useful for iOAM. Instead, please see https://tools.ietf.org/html/draft-brockners-nvo3-ioam-geneve-00

All the overhead from draft-ooamdt-rtgwg-ooam-header is either duplicative or not useful.

With that said, would the WG consider adoption of draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv?

Procedurally, is this a WG-chair-issued adoption call?

Is this an NVO3 adoption call?

Thanks,

— Carlos.

-d

Regards,
Greg

On Fri, Mar 31, 2017 at 11:34 PM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
This email begins a two week poll for adoption of draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group.

Regards

Matthew and Sam

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Nov 2017 15:06:33 -0800

Hi Carlos,
I believe that you're co-author of the iOAM in SFC NSH draft as well. Section
4 <https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-00#section-4>
of the draft, in my understanding, indicates that the authors prefer using
not MD Type 2 but rather Next Protocol approach, which is very close in
"overhead" of the OOAM-DT proposal:

   2.  Encapsulation of IOAM data fields using the "Next Protocol"
       field.  Each IOAM data field option (trace, proof-of-transit, and
       edge-to-edge) would be specified by its own "next protocol".

   The second option has been chosen here, because it avoids the
   additional layer of TLV nesting that the use of NSH MD Type 2 would
   result in.  In addition, the second option does not constrain IOAM
   data to a maximum of 256 octets, thus allowing support for very large
   deployments.

And the Section 4 of the iOAM in GENEVE points to issues similar that
concern authors of the above mentioned SFC NSH draft - use of sub-TLVs,
length limitations. Though the text does not explicitly proposes to use the
Next Protocol field to identify iOAM and carry iOAM data after the GENEVE
header in its own header, I recall that it was noted in the presentation to
NVO3 WG in Singapore as one of options under consideration.

Regards,
Greg

On Sun, Nov 26, 2017 at 8:56 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>
> On Nov 17, 2017, at 2:16 PM, Dan Wing <[email-masked]> wrote:
>
> GENEVE.
> As an author of iOAM, draft-ooamdt-rtgwg-ooam-header is not useful for
> iOAM. Instead, please see https://tools.ietf.org/html/
> draft-brockners-nvo3-ioam-geneve-00
>
> With that said, would the WG consider adoption of

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 23:13:14 +0000

Greg,

On Nov 27, 2017, at 6:06 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
I believe that you're co-author of the iOAM in SFC NSH draft as well. Section 4<https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-00#section-4> of the draft, in my understanding, indicates that the authors prefer using not MD Type 2 but rather Next Protocol approach, which is very close in "overhead" of the OOAM-DT proposal

Not really. A next protocol pointing to an iOAM data field type has nothing to do with a next protocol pointing to a header of stuff, pointing to a next protocol, with that header having a variable length with flags including timestamps and more stuff.

:

And the Section 4 of the iOAM in GENEVE points to issues similar that concern authors of the above mentioned SFC NSH draft - use of sub-TLVs, length limitations. Though the text does not explicitly proposes to use the Next Protocol field to identify iOAM and carry iOAM data after the GENEVE header in its own header, I recall that it was noted in the presentation to NVO3 WG in Singapore as one of options under consideration.

It is always possible to add another level of indirection…

Best,

— Carlos.

Regards,
Greg

On Sun, Nov 26, 2017 at 8:56 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG Chairs, et. al,

Thanks,

— Carlos.

-d

Regards,
Greg

Regards

Matthew and Sam

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Nov 2017 15:47:21 -0800

Hi Carlos,
please find my follow-up in-line tagged GIM>>.

Regards,
Greg

On Mon, Nov 27, 2017 at 3:13 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Greg,
>
> On Nov 27, 2017, at 6:06 PM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> "overhead" of the OOAM-DT proposal
>
>
> Not really. A next protocol pointing to an iOAM data field type has
> nothing to do with a next protocol pointing to a header of stuff, pointing
> to a next protocol, with that header having a variable length with flags
> including timestamps and more stuff.
>
> GIM>> You misunderstand or misrepresent OOAM DT header, but that is not
the case here. Let's  look at the Option #2 for iOAM in SFC NSH. How the
actual payload type be identified if the Next Protocol of the SFC NSH
refers to iOAM? And where the total length of the iOAM be if someone wants
to skip iOAM data altogether to get to the payload instead of parsing the
TLVs? So, from my understanding of the Option #2, iOAM should have Next
Protocol and Length fields of its own. You may call it Mandatory TLV and
require be the very first TLV or call it iOAM header but the fact is that
they are, in my opinion, must haves for Option #2. And if that is the case,
how this iOAM construct is different from OOAM-DT header?

>> iOAM. Instead, please see https://tools.ietf.org/html/dr
>> aft-brockners-nvo3-ioam-geneve-00
>>
>> In draft-ooamdt-rtgwg-demand-cc-cv, I don't see a way an
>> arbitrary-length payload can be sent, which is necessary to ensure the path
>> MTU is sufficient to carry actual traffic.  Is there some other way to meet
>> that need, perhaps with the "TLVs" field in Figure 1?
>>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Nov 2017 22:47:31 -0500

Greg Mirsky <[email-masked]> writes:
> With that said, would the WG consider adoption

I'd like to see a clearer exposition the purposes that this draft
supports.  "OAM" means "operations, administration, and maintenance",
but it seems that the primary vision for this header is including
tracing and timing information in data packets (or what appear to be
data packets), and not handling broader administration tasks.

Also, section 4.1 uses the phrase "Next Prot field in the OOAM header is
set to None", but there is no "None" value in the IP protocol number
space.  You'll need a new IANA allocation for that.

Dale