Subject: [nvo3] IETF101 NVO3 draft minutes posted

From: Ignas Bagdonas <[email-masked]>
Date: Thu, 29 Mar 2018 02:38:36 +0100

Working group,

Draft minutes for IETF101 NVO3 WG meeting have been posted at the 
meeting materials page.

https://datatracker.ietf.org/doc/minutes-101-nvo3/

Please take a look and provide any corrections if needed.

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 08:32:32 +0300

Hi Ignas,
another well-captured discussion, thank you. Few notes:

   - I believe that in discussion of OOAM Header "?/Cisco" should be Frank
   Brockners
   - would you consider splitting comments and responses with <CR><LF> to
   ease readability?

Kind regards,
Greg

On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <[email-masked]>
wrote:

> Working group,
>
> Draft minutes for IETF101 NVO3 WG meeting have been posted at the meeting
> materials page.
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 29 Mar 2018 11:56:39 +0000

Hi, Greg,

I was not in London, but if you do not mind, I will piggy back on this email to ask a couple of key questions that I still cannot figure out:

  1.  What is the objective of an OOAM, or what is purpose for adding an indirection, a shim, a nested header and additional lookup, to a bunch of encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header says “to ensure that OOAM control packets are in-band with user traffic and de-multiplex OOAM protocols.” But frankly I cannot make sense of that sentence. The same holds equally true without OOAM and this will not change the behavior of active OAM methods. Imagine the performance of BFD buried under redundant fields to parse.
  2.  Could you add an Implementation Status section [RFC 7942] to this document?

Thanks,

Carlos.

On Mar 29, 2018, at 1:32 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ignas,

  *   I believe that in discussion of OOAM Header "?/Cisco" should be Frank Brockners
  *   would you consider splitting comments and responses with <CR><LF> to ease readability?

Kind regards,
Greg

On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>> wrote:
Working group,

Draft minutes for IETF101 NVO3 WG meeting have been posted at the meeting materials page.

Thank you.

Ignas

_______________________________________________
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: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 29 Mar 2018 12:02:19 +0000

Apparently "?/Cisco" was Brian Weis (cc’ed), not me ;-)

Frank

From: nvo3 <[email-masked]> On Behalf Of Greg Mirsky
Sent: Donnerstag, 29. März 2018 07:33
To: Ignas Bagdonas <[email-masked]>
Cc: NVO3 <[email-masked]>
Subject: Re: [nvo3] IETF101 NVO3 draft minutes posted

Hi Ignas,

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 15:14:34 +0300

Hi Carlos,
I believe that introduction of the OAM Header with demultiplexing OAM
functions through use of Msg Type will enable use of non-IP encapsulation,
including for BFD and Echo Request/Reply (more on options to demultiplex
active OAM functions could be found in draft-wang-sfc-multi-layer-oam
<https://datatracker.ietf.org/doc/draft-wang-sfc-multi-layer-oam/>). And I
see ability to use non-IP encapsulation as more significant improvement
even with relative cost of introducing OAM Header.
Thank you for your reference to RFC 7942. I will discuss your suggestion
with co-authors and we'll consider adding such section.

Regards,
Greg

On Thu, Mar 29, 2018 at 2:56 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, Greg,
>
> I was not in London, but if you do not mind, I will piggy back on this
> email to ask a couple of key questions that I still cannot figure out:
>
>    1. What is the objective of an OOAM, or what is purpose for adding an
>    indirection, a shim, a nested header and additional lookup, to a bunch of
>    encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header says
>    “to ensure that OOAM control packets are in-band with user traffic and
>    de-multiplex OOAM protocols.” But frankly I cannot make sense of that
>    sentence. The same holds equally true without OOAM and this will not change
>    the behavior of active OAM methods. Imagine the performance of BFD buried
>    under redundant fields to parse.
> On Mar 29, 2018, at 1:32 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Ignas,
>    - I believe that in discussion of OOAM Header "?/Cisco" should be
>    Frank Brockners

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 29 Mar 2018 12:21:16 +0000

Hi Greg,

Thank you for the quick response!

On Mar 29, 2018, at 8:14 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
I believe that introduction of the OAM Header with demultiplexing OAM functions through use of Msg Type will enable use of non-IP encapsulation, including for BFD and Echo Request/Reply (more on options to demultiplex active OAM functions could be found in draft-wang-sfc-multi-layer-oam<https://datatracker.ietf.org/doc/draft-wang-sfc-multi-layer-oam/>).

non-IP BFD works well already without this additional overhead. Each tunneling/encap has appropriate demos capabilities already.

Still, a header for demultiplexing (a protocol ID) for encapsulations that already have a protocol ID seems unnecessary. Further, it carries timestamps and flags for “capabilities”. So it is an OAM in its own to carry OAM.

The complete proposition sounds triply duplicative.

And I see ability to use non-IP encapsulation as more significant improvement even with relative cost of introducing OAM Header.
Thank you for your reference to RFC 7942. I will discuss your suggestion with co-authors and we'll consider adding such section.

Thank you. Look forward to seeing the Implementation Status.

Carlos.

Regards,
Greg

On Thu, Mar 29, 2018 at 2:56 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Greg,

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 15:30:52 +0300

Hi Carlos,
as pointed in draft-wang-sfc-multi-layer-oam direct use of Net Protocol
field in encapsulation requires the code point for each OAM function, e.g.
BFD, Echo Request/Reply, PM, and etc.

Regards,
Greg

On Thu, Mar 29, 2018 at 3:21 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Mar 29, 2018, at 8:14 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> <https://datatracker.ietf.org/doc/draft-wang-sfc-multi-layer-oam/>).
>
>
> non-IP BFD works well already without this additional overhead. Each
> tunneling/encap has appropriate demos capabilities already.
>
> Still, a header for demultiplexing (a protocol ID) for encapsulations that
> already have a protocol ID seems unnecessary. Further, it carries
> timestamps and flags for “capabilities”. So it is an OAM in its own to
> carry OAM.
>
> And I see ability to use non-IP encapsulation as more significant
> improvement even with relative cost of introducing OAM Header.
>>    - would you consider splitting comments and responses with <CR><LF>
>>    to ease readability?
>>
>> Kind regards,
>> Greg
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 29 Mar 2018 12:39:41 +0000

Greg,

Scanning through it, that draft concerns itself with SFC only.

But regardless, it emphasizes the point of when this OOAM idea breaks: each encapsulation has different allocation strategy. Some encaps have already an OAM bit, which when set, can open the whole range of PIDs for OAM types.

Other encaps much rather *have* different code points for BFD and for others. Because there is space, and much rather NOT do a double lookup to figure out what OAM it actually is.

I still do not see the problem attempted to be solved.

Thanks,

Carlos.

On Mar 29, 2018, at 8:30 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
as pointed in draft-wang-sfc-multi-layer-oam direct use of Net Protocol field in encapsulation requires the code point for each OAM function, e.g. BFD, Echo Request/Reply, PM, and etc.

Regards,
Greg

On Thu, Mar 29, 2018 at 3:21 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 16:37:53 +0300

Hi Carlos,
indeed, parts of the draft are specific to SFC but discussion on options
for supporting active OAM, I believe, is applicable to overlays
(encaps/tnneling) in general.
Applicability or suitability of the OAM Header to particular encapsulation,
in my view, depedns not whether the encapsulation uses OAM bit but how it
defines identification of active OAM packet. After the London meeting we
have iOAM proposals for several encapsulations, including SFC NSH and
Geneve, that propose use iOAM as value of Next Protocol field of the
encapsulation and transparent to O-bit value.

Regards,
Greg

On Thu, Mar 29, 2018 at 3:39 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> But regardless, it emphasizes the point of when this OOAM idea breaks:
> each encapsulation has different allocation strategy. Some encaps have
> already an OAM bit, which when set, can open the whole range of PIDs for
> OAM types.
>
> Other encaps much rather *have* different code points for BFD and for
> others. Because there is space, and much rather NOT do a double lookup to
> figure out what OAM it actually is.
>
> On Mar 29, 2018, at 8:30 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
>> Still, a header for demultiplexing (a protocol ID) for encapsulations
>> that already have a protocol ID seems unnecessary. Further, it carries
>>>    1. What is the objective of an OOAM, or what is purpose for adding
>>>    an indirection, a shim, a nested header and additional lookup, to a bunch
>>>    of encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header
>>>    says “to ensure that OOAM control packets are in-band with user traffic and
>>> On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <[email-masked]
>>> > wrote:
>>>
>>>> Working group,
>>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 29 Mar 2018 13:45:08 +0000

Greg,

Thanks for the quick response.

I fail to see how OOAM (targeting active OAM) and IOAM (hybrid in-situ OAM) relate to each other. Let’s not try to conflate different problem spaces into a spaghetti.

As a separate topic, I also do not see the need for an extra OOAM overhead lookup and indirection — and considering your point of all encaps being different, seems not useful both in theory and practice.

Thanks,

Carlos.

On Mar 29, 2018, at 9:37 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
indeed, parts of the draft are specific to SFC but discussion on options for supporting active OAM, I believe, is applicable to overlays (encaps/tnneling) in general.
Applicability or suitability of the OAM Header to particular encapsulation, in my view, depedns not whether the encapsulation uses OAM bit but how it defines identification of active OAM packet. After the London meeting we have iOAM proposals for several encapsulations, including SFC NSH and Geneve, that propose use iOAM as value of Next Protocol field of the encapsulation and transparent to O-bit value.

Regards,
Greg

On Thu, Mar 29, 2018 at 3:39 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 16:48:10 +0300

Hi Carlos,
would you kindly point to the definition that explains how active OAM is
identified in, for example, SFC NSH and Geneve.
Thank you in advance.

Regards,
Greg

On Thu, Mar 29, 2018 at 4:45 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I fail to see how OOAM (targeting active OAM) and IOAM (hybrid in-situ
> OAM) relate to each other. Let’s not try to conflate different problem
> spaces into a spaghetti.
>
> As a separate topic, I also do not see the need for an extra OOAM overhead
> lookup and indirection — and considering your point of all encaps being
> different, seems not useful both in theory and practice.
>
> Thanks,
>
> Carlos.
>
>
> On Mar 29, 2018, at 9:37 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> Applicability or suitability of the OAM Header to particular
> encapsulation, in my view, depedns not whether the encapsulation uses OAM
> bit but how it defines identification of active OAM packet. After the
> London meeting we have iOAM proposals for several encapsulations, including
> SFC NSH and Geneve, that propose use iOAM as value of Next Protocol field
> of the encapsulation and transparent to O-bit value.
>
> Regards,
> Greg
>
>>>> On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <
>>>> [email-masked]> wrote:
>>>>
>>>>> Working group,
>>>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 29 Mar 2018 15:19:25 +0000

Hi, Greg,

Thank you for the quick reply. However, your response is both a red herring and a false cause. Additionally, the conversation does feel like déjà vu...

Whichever way SFC NSH and Geneve choose to identify OAM is not relevant to my comments below. They can choose to use an O bit present in the encapsulation for active OAM, and the PID for different OAMs, or any other way that does not require two lookups. I doubt that there is a lot of intersection between BIER MPLS, GRE, and NSH for OAM. And if you further consider other overlay protocols, the intersection is null.

But my point was to pose for the WG’s consideration a couple of questions I had asked in the past and not to engage in a rat-hole:
1. Why would anyone need an OOAM
2. What is the implementation status and plan.

As such, I’ll close the thread from my end.

Many Thanks,

Carlos.

On Mar 29, 2018, at 9:48 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
would you kindly point to the definition that explains how active OAM is identified in, for example, SFC NSH and Geneve.
Thank you in advance.

Regards,
Greg

On Thu, Mar 29, 2018 at 4:45 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 31 Mar 2018 00:07:35 +0300

Hi Carlos,
you've asked

1. Why would anyone need an Overlay OAM, [i.e. Why need for OAM in NVO3,
SFC and etc.]

I'd refer to comment Alia made at the NVO3 WG meeting during the discussion
of this proposal:

Alia: I would like to reiterate - I am very
happy to see the discussion happening, this is something that WG was working
for 3-4 years. We need this. VXLAN has been deployed for a very long time, and
Geneve is coming. Let’s get this done.

So, my answer
Because it's about time we do better job by developing networks accompanied
with the toolset to run, diagnose and troubleshoot them. And that, IMHO,
requires comprehensive OAM tools, including active and hybrid.

Regards,
Greg

On Thu, Mar 29, 2018 at 6:19 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, Greg,
>
> Thank you for the quick reply. However, your response is both a red
> herring and a false cause. Additionally, the conversation does feel
> like déjà vu...
>
> Whichever way SFC NSH and Geneve choose to identify OAM is not relevant to
> my comments below. They can choose to use an O bit present in the
> encapsulation for active OAM, and the PID for different OAMs, or any other
> way that does not require two lookups. I doubt that there is a lot of
> intersection between BIER MPLS, GRE, and NSH for OAM. And if you further
> consider other overlay protocols, the intersection is null.
>
> But my point was to pose for the WG’s consideration a couple of questions
> I had asked in the past and not to engage in a rat-hole:
> On Mar 29, 2018, at 9:48 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
>> As a separate topic, I also do not see the need for an extra OOAM
>> overhead lookup and indirection — and considering your point of all encaps
>> being different, seems not useful both in theory and practice.
>>
>> Thanks,
>>
>> Carlos.
>>
>>
>>>> Thank you for your reference to RFC 7942. I will discuss your
>>>> suggestion with co-authors and we'll consider adding such section.
>>>>
>>>>
>>>>>    - would you consider splitting comments and responses with
>>>>>    <CR><LF> to ease readability?
>>>>>
>>>>> Kind regards,
>>>>> Greg
>>>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 30 Mar 2018 21:19:17 +0000

Hi, Greg — I agree with all of that, none of which talks about, points to, or explains why OOAM! :-)

I asked a specific focused question. No answer about what problem OOAM solves...

You will have a hard time finding disagreement with rah-rah and generic statements. Yes, let’s dramatically improve the visibility, operations, and automation of networks and architectures.

No reason, however, to add extra overhead headers to BIER, Geneve, SFC, what else?

Reminds me of… https://xkcd.com/927/

— Carlos.

On Mar 30, 2018, at 5:07 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
you've asked
1. Why would anyone need an Overlay OAM, [i.e. Why need for OAM in NVO3, SFC and etc.]
I'd refer to comment Alia made at the NVO3 WG meeting during the discussion of this proposal:

So, my answer
Because it's about time we do better job by developing networks accompanied with the toolset to run, diagnose and troubleshoot them. And that, IMHO, requires comprehensive OAM tools, including active and hybrid.

Regards,
Greg

On Thu, Mar 29, 2018 at 6:19 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Greg,

Many Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 30 Mar 2018 21:24:43 +0000

Hi, Greg,

A quick followup, I just realized two things:

I realized that I also asked a 2nd question:
2. What is the implementation status and plan?

Perhaps you missed it or skipped it over reading it?

I just also realized that my words and intention are completely twisted in your paraphrasing, changing the meaning of my comment! :-(
I did not say “ Why need for OAM in NVO3, SFC and etc”.
I said/meant “Why need a common extra header to prepend to the OAMs of oil-and-water tunneling technologies?"

I agree we need OAM for those — I do not see OOAM’s place, hence I am just asking trying to understand.

Thanks,

Carlos.

Hi Carlos,
you've asked

So, my answer

Regards,
Greg

Many Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 31 Mar 2018 00:52:54 +0300

Hi Carlos,
you may be surprised to check BIER OAM, section 3.1 of draft-ietf-bier-ping
<https://tools.ietf.org/html/draft-ietf-bier-ping-03> to be precise, as it
defines the header for active BIER OAM.

Regards,
Greg

PS. You're co-authored BIER ping draft.

On Sat, Mar 31, 2018 at 12:19 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> You will have a hard time finding disagreement with rah-rah and generic
> statements. Yes, let’s dramatically improve the visibility, operations, and
> automation of networks and architectures.
>
> On Mar 30, 2018, at 5:07 PM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> you've asked
>
> Because it's about time we do better job by developing networks
> accompanied with the toolset to run, diagnose and troubleshoot them. And
> that, IMHO, requires comprehensive OAM tools, including active and hybrid.
>
> Regards,
> Greg
>
>
>
>> Whichever way SFC NSH and Geneve choose to identify OAM is not relevant
>> to my comments below. They can choose to use an O bit present in the
>>>> as pointed in draft-wang-sfc-multi-layer-oam direct use of Net
>>>> Protocol field in encapsulation requires the code point for each OAM
>>>> function, e.g. BFD, Echo Request/Reply, PM, and etc.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>>>> I was not in London, but if you do not mind, I will piggy back on
>>>>>> this email to ask a couple of key questions that I still cannot figure out:
>>>>>>
>>>>>>    1. What is the objective of an OOAM, or what is purpose for
>>>>>>    adding an indirection, a shim, a nested header and additional lookup, to a
>>>>>>    bunch of encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 30 Mar 2018 23:16:24 +0000

Hi, Greg,

Not surprised. But for the record, and my last email on this thread:

You kept dodging the questions and chose to NOT answer either of them. This was intended as a quick and painless Echo/Reply email exchange, single round-trip, and the evasiveness and avoiding-the-issue non-answers turned it into a TCP interaction! RST!

Enjoy your weekend,

Carlos.

On Mar 30, 2018, at 5:52 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
you may be surprised to check BIER OAM, section 3.1 of draft-ietf-bier-ping<https://tools.ietf.org/html/draft-ietf-bier-ping-03> to be precise, as it defines the header for active BIER OAM.

Regards,
Greg

On Sat, Mar 31, 2018 at 12:19 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Greg — I agree with all of that, none of which talks about, points to, or explains why OOAM! :-)

— Carlos.

Hi Carlos,
you've asked

So, my answer

Regards,
Greg

Many Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Thanks,

Carlos.

Hi Carlos,

Regards,
Greg

Hi Carlos,

Carlos.

Regards,
Greg

Thanks,

Carlos.

Hi Ignas,

Kind regards,
Greg

Thank you.

Ignas