Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Frank Brockners (fbrockne)]

Hi Greg,

it depends on the individual encapsulation, i.e. the parent protocol used. IOAM 
data encapsulation depends on what the parent protocol offers as encapsulation 
mechanism. As such, you’d depend on the procedures used by the parent protocol.
Let’s consider two examples Geneve and NSH: For Geneve 
(draft-brockners-ippm-ioam-geneve-00) we use the “option class” mechanism to 
carry IOAM data, i.e. Geneve’s mechanism to carry meta data. Getting to the 
payload in a setup with IOAM data within the Geneve header is no different than 
a Geneve setup without IOAM, assuming that the Geneve implementation supports 
Geneve option classes. Check out draft-ietf-nvo3-geneve for the Geneve header. 
For NSH the suggestion in draft-brockners-sfc-ioam-nsh-01 is to use the “NSH 
Next Protocol” mechanism in NSH (see e.g. RFC 8300, section 9.1.6). 
Re-specifying the encap mechanism of the base protocol in a specification which 
only leverages the base protocol will do more harm than good. It should be 
avoided because it could only lead to confusion. All the IOAM encap drafts 
clearly reference the parent protocol encap mechanism – so an implementer will 
naturally refer to the base specification.

All that said: What are you trying to point out? It seems that you’re pickup up 
the discussion about the pros and cons on whether to use protocol meta-data or 
the “next header” approach. The SFC WG discussed this at length in the last 
meeting in London and you actively participated in it. The “next header” 
approach allows for a more efficient implementation in hardware (fewer nested 
structures/lookups) at the expense of requiring the each node to have a basic 
understanding of IOAM (at least the type and length fields – so that you could 
skip past it), whereas the “leverage meta-data type-2” approach leads to more 
complicated lookup operations (the location of MD Type 2 isn’t fixed) as well 
as constrain the amount of data to be carried to 256 octets. See also section 
4.1 in draft-brockners-sfc-ioam-nsh-01.
You remember that from the “hum” in the room that the chairs initiated (which 
still needs confirmation on the list – which we do right now), there seems to 
be a preference to either go with the “next header approach” (as per 
draft-brockners-sfc-ioam-nsh-01) or to document the next header approach and 
the MD-Type2 approach. We do care about efficient implementation – this is what 
we learned from several IOAM implementations by now, and which is why we have 
quite a few authors from companies which drive silicon implementations on the 
IOAM drafts – see also John Lemon’s email yesterday.

We’d greatly appreciate thoughts from other SFC WG members on their preference 
of using either the “NSH next protocol” approach or the “MD Type2” meta-data 
based approach.

Thanks,
Frank

From: Greg Mirsky 
Sent: Donnerstag, 19. April 2018 19:27
To: Frank Brockners (fbrockne) 
Cc: IETF IPPM WG ; NVO3 ; Service Function 
Chaining IETF list ; int-a...@ietf.org
Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up 
from WG discussion in London

Hi Frank,
thank you for your expedient response. Yes, clarification and consistent 
terminology, of course as different encapsulations allow that, will help. What 
I'm looking through the iOAM encapsulation drafts is the answer to this 
question How a system that is not using iOAM can get to the data payload that 
follows the iOAM message? Is there the field in the iOAM shim that allows the 
system to skip over the iOAM message (by iOAM message I mean iOAM shim and iOAM 
data)? Would such system be required to parse other than iOAM shim constructs? 
I couldn't find this scenario being discussed in any of iOAM encapsulation 
drafts. Have I missed it?

Regards,
Greg

On Thu, Apr 19, 2018 at 9:54 AM, Frank Brockners (fbrockne) 
> wrote:
Hi Greg,

good catch – there is a bit of loose language in some of the drafts. We’ll make 
things crisper in the next rev. Note that there is no generic “IOAM header” but 
that definition is always within the context of a particular encapsulation 
protocol. draft-weis-ippm-ioam-gre-00 already has a definition of the IOAM 
header (for GRE) – see section 3. For the other drafts, we use language like 
“The IOAM related fields in VXLAN-GPE are defined as follows” or “The fields 
related to the encapsulation of IOAM data fields in Geneve are defined as 
follows”, i.e. the information that is required to perform the encapsulation 
into the parent protocol, along with the actual IOAM data fields. Moving 
forward, we can be crisper and split things into an “encapsulation dependent 
part” and a “data part”.

Frank

From: Greg Mirsky >
Sent: Donnerstag, 19. April 2018 18:15
To: Frank Brockners (fbrockne) >
Cc: 

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[John Lemon]

Hi Greg,

I never stated "that mere fact of existing implementation should cancel
discussion of technical characteristics of the proposed approaches to
hybrid OAM". I just noted implementation status as AN important thing to
consider. I also noted that "I've seen several good arguments for why the
existing IOAM implementation [...] meets the needs for IOAM." I'm not
trying to end discussion of the technical characteristics. I'm stating that
I believe that it has been well argued that IOAM is mature enough that it
is clear that it is sufficiently different from OOAM as to not share the
same header.

I hope that clarifies my intent.

Regards, John


On Thu, Apr 19, 2018 at 9:30 AM, Greg Mirsky  wrote:

> Hi John,
> I don't argue with the importance of interoperable implementations (though
> early implementations accept the risk of non-compliance with the final
> specification, for example, SFC NSH). At the same time, I don't think that
> mere fact of existing implementation should cancel discussion of technical
> characteristics of the proposed approaches to hybrid OAM.
>
> Regards,
> Greg
>
> On Thu, Apr 19, 2018 at 9:09 AM, John Lemon 
> wrote:
>
>> I never saw a response to the request for a pointer to an OOAM
>> implementation, so I assume none exist.
>>
>> I've seen several good arguments for why the existing IOAM
>> implementation, for which several implementations exist, meets the needs
>> for IOAM.
>>
>> I think it is time to put to bed the request to examine merging OOAM and
>> IOAM. Let's move forward with IOAM and not hold it up.
>>
>> Respectfully, John
>>
>>
>> On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) <
>> fbroc...@cisco.com> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>>
>>> thanks – and it seems that we’re on the same page with regards to
>>> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of
>>> OOAM.
>>>
>>>
>>>
>>> On the IOAM implementation: There are several implementations of IOAM.
>>> Some of which have recently been worked on and shown at an IETF hackathon,
>>> see https://datatracker.ietf.org/meeting/100/materials/slides-10
>>> 0-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
>>> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino. You
>>> probably also remember the Netronome/Broadcom demo -
>>> https://www.youtube.com/watch?v=j9FbD4a3F4E .
>>>
>>> Below you seem to be specifically referring to the IOAM open source
>>> implementation in FD.io/VPP: There are protocol encapsulations for
>>> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses
>>> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for
>>> NSH. As you’re well aware, there the discussion in SFC whether to use
>>> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled,
>>> hence we’ll refrain from updating the code until SFC WG has come to a
>>> conclusion.
>>>
>>>
>>>
>>> Could you provide a pointer to an OOAM implementation?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Frank
>>>
>>>
>>>
>>> *From:* Greg Mirsky 
>>> *Sent:* Donnerstag, 12. April 2018 18:54
>>> *To:* Frank Brockners (fbrockne) 
>>> *Cc:* IETF IPPM WG ; NVO3 ; Service
>>> Function Chaining IETF list ; int-a...@ietf.org
>>> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
>>> follow up from WG discussion in London
>>>
>>>
>>>
>>> Hi Frank,
>>>
>>> thank you for sharing your points. Please find my notes in-line and
>>> tagged GIM>>. I believe that this is very much relevant to work of other
>>> working groups that directly work on the overlay encapsulations in the
>>> center of the discussion and hence I've added them to the list. Hope we'll
>>> have more opinions to reach the conclusion that is acceptable to all.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <
>>> fbroc...@cisco.com> wrote:
>>>
>>> Back at the IPPM meeting in London, we discussed several drafts dealing
>>> with the encapsulation of IOAM data in various protocols
>>> (draft-brockners-ippm-ioam-vxlan-gpe-00, 
>>> draft-brockners-ippm-ioam-geneve-00,
>>> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
>>> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
>>> could be leveraged.  After carefully considering
>>> draft-ooamdt-rtgwg-ooam-header, I came to the conclusion that the “OOAM
>>> header” does not meet the needs of IOAM:
>>>
>>> * Efficiency: IOAM adds data to live user traffic. As such, an
>>> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
>>> bytes long. The approach for IOAM data encapsulation in the above mentioned
>>> drafts only requires 4 bytes. Using the OOAM header approach would add an
>>> unnecessary overhead of 4 bytes – which is significant.
>>>
>>> GIM>> The difference in four 

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi Frank,
thank you for your expedient response. Yes, clarification and consistent
terminology, of course as different encapsulations allow that, will help.
What I'm looking through the iOAM encapsulation drafts is the answer to
this question How a system that is not using iOAM can get to the data
payload that follows the iOAM message? Is there the field in the iOAM shim
that allows the system to skip over the iOAM message (by iOAM message I
mean iOAM shim and iOAM data)? Would such system be required to parse other
than iOAM shim constructs? I couldn't find this scenario being discussed in
any of iOAM encapsulation drafts. Have I missed it?

Regards,
Greg

On Thu, Apr 19, 2018 at 9:54 AM, Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Hi Greg,
>
>
>
> good catch – there is a bit of loose language in some of the drafts. We’ll
> make things crisper in the next rev. Note that there is no generic “IOAM
> header” but that definition is always within the context of a particular
> encapsulation protocol. draft-weis-ippm-ioam-gre-00 already has a
> definition of the IOAM header (for GRE) – see section 3. For the other
> drafts, we use language like “The IOAM related fields in VXLAN-GPE are
> defined as follows” or “The fields related to the encapsulation of IOAM
> data fields in Geneve are defined as follows”, i.e. the information that is
> required to perform the encapsulation into the parent protocol, along with
> the actual IOAM data fields. Moving forward, we can be crisper and split
> things into an “encapsulation dependent part” and a “data part”.
>
>
>
> Frank
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Donnerstag, 19. April 2018 18:15
> *To:* Frank Brockners (fbrockne) 
> *Cc:* IETF IPPM WG ; NVO3 ; Service
> Function Chaining IETF list ; int-a...@ietf.org
> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
>
>
>
> Hi Frank, et. al,
>
> we have a very good discussion, thank you. I have a question and
> appreciate your consideration:
>
>- encapsulation documents refer to IOAM HDR, its length is reflected
>in the field labeled either Length or IOAM HDR len. But I cannot find the
>definition of IOAM HDR. What is the IOAM HDR?
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) <
> fbroc...@cisco.com> wrote:
>
> Back at the IPPM meeting in London, we discussed several drafts dealing
> with the encapsulation of IOAM data in various protocols
> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
> could be leveraged.  After carefully considering 
> draft-ooamdt-rtgwg-ooam-header,
> I came to the conclusion that the “OOAM header” does not meet the needs of
> IOAM:
>
> * Efficiency: IOAM adds data to live user traffic. As such, an
> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
> bytes long. The approach for IOAM data encapsulation in the above mentioned
> drafts only requires 4 bytes. Using the OOAM header approach would add an
> unnecessary overhead of 4 bytes – which is significant.
>
> * Maturity: IOAM has several implementations, which were also shown at
> recent IETF hackathons – and we’re expecting additional implementations to
> be publicized soon. Interoperable implementations need timely
> specifications. Despite the question being asked, the recent thread on OOAM
> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
> addition, the thread revealed that several fundamental questions about the
> OOAM header are still open, such as whether or how active OAM mechanisms
> within protocols such as Geneve would apply to the OOAM header. This
> ultimately means that we won’t get to a timely specification.
>
> * Scope: It isn’t entirely clear to which protocols the OOAM header would
> ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit
> field for “Next Prot”, the next protocol. Some protocols that IOAM data
> needs to be encapsulated into use 16-bits for their next protocol code
> points. See e.g. the GRE encapsulation – as specified in
> draft-weis-ippm-ioam-gre-00.
>
> With the above in mind, I’d suggest that the WG moves forward with
> specific definitions for encapsulating IOAM data into protocols – per the
> above mentioned drafts.
>
>
>
> Regards, Frank
>
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
>
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Frank Brockners (fbrockne)]

Hi Greg,

good catch – there is a bit of loose language in some of the drafts. We’ll make 
things crisper in the next rev. Note that there is no generic “IOAM header” but 
that definition is always within the context of a particular encapsulation 
protocol. draft-weis-ippm-ioam-gre-00 already has a definition of the IOAM 
header (for GRE) – see section 3. For the other drafts, we use language like 
“The IOAM related fields in VXLAN-GPE are defined as follows” or “The fields 
related to the encapsulation of IOAM data fields in Geneve are defined as 
follows”, i.e. the information that is required to perform the encapsulation 
into the parent protocol, along with the actual IOAM data fields. Moving 
forward, we can be crisper and split things into an “encapsulation dependent 
part” and a “data part”.

Frank

From: Greg Mirsky 
Sent: Donnerstag, 19. April 2018 18:15
To: Frank Brockners (fbrockne) 
Cc: IETF IPPM WG ; NVO3 ; Service Function 
Chaining IETF list ; int-a...@ietf.org
Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up 
from WG discussion in London

Hi Frank, et. al,
we have a very good discussion, thank you. I have a question and appreciate 
your consideration:

  *   encapsulation documents refer to IOAM HDR, its length is reflected in the 
field labeled either Length or IOAM HDR len. But I cannot find the definition 
of IOAM HDR. What is the IOAM HDR?

Regards,
Greg


On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) 
> wrote:
Back at the IPPM meeting in London, we discussed several drafts dealing with 
the encapsulation of IOAM data in various protocols 
(draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, 
draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to 
the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be 
leveraged.  After carefully considering draft-ooamdt-rtgwg-ooam-header, I came 
to the conclusion that the “OOAM header” does not meet the needs of IOAM:
* Efficiency: IOAM adds data to live user traffic. As such, an encapsulation 
needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The 
approach for IOAM data encapsulation in the above mentioned drafts only 
requires 4 bytes. Using the OOAM header approach would add an unnecessary 
overhead of 4 bytes – which is significant.
* Maturity: IOAM has several implementations, which were also shown at recent 
IETF hackathons – and we’re expecting additional implementations to be 
publicized soon. Interoperable implementations need timely specifications. 
Despite the question being asked, the recent thread on OOAM in the NVO3 list 
hasn’t revealed any implementation of the OOAM header. In addition, the thread 
revealed that several fundamental questions about the OOAM header are still 
open, such as whether or how active OAM mechanisms within protocols such as 
Geneve would apply to the OOAM header. This ultimately means that we won’t get 
to a timely specification.
* Scope: It isn’t entirely clear to which protocols the OOAM header would 
ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit 
field for “Next Prot”, the next protocol. Some protocols that IOAM data needs 
to be encapsulated into use 16-bits for their next protocol code points. See 
e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00.
With the above in mind, I’d suggest that the WG moves forward with specific 
definitions for encapsulating IOAM data into protocols – per the above 
mentioned drafts.

Regards, Frank

___
ippm mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi John,
I don't argue with the importance of interoperable implementations (though
early implementations accept the risk of non-compliance with the final
specification, for example, SFC NSH). At the same time, I don't think that
mere fact of existing implementation should cancel discussion of technical
characteristics of the proposed approaches to hybrid OAM.

Regards,
Greg

On Thu, Apr 19, 2018 at 9:09 AM, John Lemon  wrote:

> I never saw a response to the request for a pointer to an OOAM
> implementation, so I assume none exist.
>
> I've seen several good arguments for why the existing IOAM implementation,
> for which several implementations exist, meets the needs for IOAM.
>
> I think it is time to put to bed the request to examine merging OOAM and
> IOAM. Let's move forward with IOAM and not hold it up.
>
> Respectfully, John
>
>
> On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) <
> fbroc...@cisco.com> wrote:
>
>> Hi Greg,
>>
>>
>>
>> thanks – and it seems that we’re on the same page with regards to
>> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of
>> OOAM.
>>
>>
>>
>> On the IOAM implementation: There are several implementations of IOAM.
>> Some of which have recently been worked on and shown at an IETF hackathon,
>> see https://datatracker.ietf.org/meeting/100/materials/slides-10
>> 0-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
>> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino.. You
>> probably also remember the Netronome/Broadcom demo -
>> https://www.youtube.com/watch?v=j9FbD4a3F4E .
>>
>> Below you seem to be specifically referring to the IOAM open source
>> implementation in FD.io/VPP: There are protocol encapsulations for
>> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses
>> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for
>> NSH. As you’re well aware, there the discussion in SFC whether to use
>> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled,
>> hence we’ll refrain from updating the code until SFC WG has come to a
>> conclusion.
>>
>>
>>
>> Could you provide a pointer to an OOAM implementation?
>>
>>
>>
>> Thanks,
>>
>> Frank
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* Donnerstag, 12. April 2018 18:54
>> *To:* Frank Brockners (fbrockne) 
>> *Cc:* IETF IPPM WG ; NVO3 ; Service
>> Function Chaining IETF list ; int-a...@ietf.org
>> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
>> follow up from WG discussion in London
>>
>>
>>
>> Hi Frank,
>>
>> thank you for sharing your points. Please find my notes in-line and
>> tagged GIM>>. I believe that this is very much relevant to work of other
>> working groups that directly work on the overlay encapsulations in the
>> center of the discussion and hence I've added them to the list. Hope we'll
>> have more opinions to reach the conclusion that is acceptable to all.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <
>> fbroc...@cisco.com> wrote:
>>
>> Back at the IPPM meeting in London, we discussed several drafts dealing
>> with the encapsulation of IOAM data in various protocols
>> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
>> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
>> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
>> could be leveraged.  After carefully considering
>> draft-ooamdt-rtgwg-ooam-header, I came to the conclusion that the “OOAM
>> header” does not meet the needs of IOAM:
>>
>> * Efficiency: IOAM adds data to live user traffic. As such, an
>> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
>> bytes long. The approach for IOAM data encapsulation in the above mentioned
>> drafts only requires 4 bytes. Using the OOAM header approach would add an
>> unnecessary overhead of 4 bytes – which is significant.
>>
>> GIM>> The difference in four octets is because OOAM Header:
>>
>>- provides more flexibility, e.g. Flags field and Reserved fields;
>>- supports larger OAM packets than iOAM header;
>>- is future proof by supporting versioning (Version field).
>>
>> * Maturity: IOAM has several implementations, which were also shown at
>> recent IETF hackathons – and we’re expecting additional implementations to
>> be publicized soon. Interoperable implementations need timely
>> specifications. Despite the question being asked, the recent thread on OOAM
>> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
>> addition, the thread revealed that several fundamental questions about the
>> OOAM header are still open, such as whether or how active OAM mechanisms
>> within protocols such as Geneve would apply to the OOAM header. This
>> ultimately means that we 

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi Frank, et. al,
we have a very good discussion, thank you. I have a question and appreciate
your consideration:

   - encapsulation documents refer to IOAM HDR, its length is reflected in
   the field labeled either Length or IOAM HDR len. But I cannot find the
   definition of IOAM HDR. What is the IOAM HDR?


Regards,
Greg


On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Back at the IPPM meeting in London, we discussed several drafts dealing
> with the encapsulation of IOAM data in various protocols
> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
> could be leveraged.  After carefully considering 
> draft-ooamdt-rtgwg-ooam-header,
> I came to the conclusion that the “OOAM header” does not meet the needs of
> IOAM:
>
> * Efficiency: IOAM adds data to live user traffic. As such, an
> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
> bytes long. The approach for IOAM data encapsulation in the above mentioned
> drafts only requires 4 bytes. Using the OOAM header approach would add an
> unnecessary overhead of 4 bytes – which is significant.
>
> * Maturity: IOAM has several implementations, which were also shown at
> recent IETF hackathons – and we’re expecting additional implementations to
> be publicized soon. Interoperable implementations need timely
> specifications. Despite the question being asked, the recent thread on OOAM
> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
> addition, the thread revealed that several fundamental questions about the
> OOAM header are still open, such as whether or how active OAM mechanisms
> within protocols such as Geneve would apply to the OOAM header. This
> ultimately means that we won’t get to a timely specification.
>
> * Scope: It isn’t entirely clear to which protocols the OOAM header would
> ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit
> field for “Next Prot”, the next protocol. Some protocols that IOAM data
> needs to be encapsulated into use 16-bits for their next protocol code
> points. See e.g. the GRE encapsulation – as specified in
> draft-weis-ippm-ioam-gre-00.
>
> With the above in mind, I’d suggest that the WG moves forward with
> specific definitions for encapsulating IOAM data into protocols – per the
> above mentioned drafts.
>
>
>
> Regards, Frank
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[John Lemon]

I never saw a response to the request for a pointer to an OOAM
implementation, so I assume none exist.

I've seen several good arguments for why the existing IOAM implementation,
for which several implementations exist, meets the needs for IOAM.

I think it is time to put to bed the request to examine merging OOAM and
IOAM. Let's move forward with IOAM and not hold it up.

Respectfully, John


On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Hi Greg,
>
>
>
> thanks – and it seems that we’re on the same page with regards to
> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of
> OOAM.
>
>
>
> On the IOAM implementation: There are several implementations of IOAM.
> Some of which have recently been worked on and shown at an IETF hackathon,
> see https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino. You
> probably also remember the Netronome/Broadcom demo -
> https://www.youtube.com/watch?v=j9FbD4a3F4E .
>
> Below you seem to be specifically referring to the IOAM open source
> implementation in FD.io/VPP: There are protocol encapsulations for
> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses
> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for
> NSH. As you’re well aware, there the discussion in SFC whether to use
> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled,
> hence we’ll refrain from updating the code until SFC WG has come to a
> conclusion.
>
>
>
> Could you provide a pointer to an OOAM implementation?
>
>
>
> Thanks,
>
> Frank
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Donnerstag, 12. April 2018 18:54
> *To:* Frank Brockners (fbrockne) 
> *Cc:* IETF IPPM WG ; NVO3 ; Service
> Function Chaining IETF list ; int-a...@ietf.org
> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
>
>
>
> Hi Frank,
>
> thank you for sharing your points. Please find my notes in-line and tagged
> GIM>>. I believe that this is very much relevant to work of other working
> groups that directly work on the overlay encapsulations in the center of
> the discussion and hence I've added them to the list. Hope we'll have more
> opinions to reach the conclusion that is acceptable to all.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <
> fbroc...@cisco.com> wrote:
>
> Back at the IPPM meeting in London, we discussed several drafts dealing
> with the encapsulation of IOAM data in various protocols
> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
> could be leveraged.  After carefully considering 
> draft-ooamdt-rtgwg-ooam-header,
> I came to the conclusion that the “OOAM header” does not meet the needs of
> IOAM:
>
> * Efficiency: IOAM adds data to live user traffic. As such, an
> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
> bytes long. The approach for IOAM data encapsulation in the above mentioned
> drafts only requires 4 bytes. Using the OOAM header approach would add an
> unnecessary overhead of 4 bytes – which is significant.
>
> GIM>> The difference in four octets is because OOAM Header:
>
>- provides more flexibility, e.g. Flags field and Reserved fields;
>- supports larger OAM packets than iOAM header;
>- is future proof by supporting versioning (Version field).
>
> * Maturity: IOAM has several implementations, which were also shown at
> recent IETF hackathons – and we’re expecting additional implementations to
> be publicized soon. Interoperable implementations need timely
> specifications. Despite the question being asked, the recent thread on OOAM
> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
> addition, the thread revealed that several fundamental questions about the
> OOAM header are still open, such as whether or how active OAM mechanisms
> within protocols such as Geneve would apply to the OOAM header. This
> ultimately means that we won’t get to a timely specification.
>
> GIM>> May I ask which encapsulations supported by the implementations you
> refer to. Until very recently all iOAM proposals were to use meta-data TLV
> in, e.g. Geneve and NSH. And if these or some of these implementations
> already updated to the newly proposed iOAM shim, I don't see problem in
> making them use OOAM Header. Would you agree?
>
>
>
> * Scope: It isn’t entirely clear to which protocols the OOAM header would
> ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit
> field for “Next Prot”, the next 

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi Frank,
I think you've misunderstood my response to your statements:

   - the scope of OOAM, contrary to what you've stated, is clearly stated
   in the draft;
   - what you present as "efficiency" I consider to be serious limitations
   (lack of versioning, limited size for data, and no future extension) that
   should be explained and thoroughly discussed by the WGs that develop
   corresponding overlay networks before IPPM WG makes any decision.

Regards,
Greg

On Thu, Apr 12, 2018 at 8:06 PM, Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Hi Greg,
>
>
>
> thanks – and it seems that we’re on the same page with regards to
> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of
> OOAM.
>
>
>
> On the IOAM implementation: There are several implementations of IOAM.
> Some of which have recently been worked on and shown at an IETF hackathon,
> see https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino. You
> probably also remember the Netronome/Broadcom demo -
> https://www.youtube.com/watch?v=j9FbD4a3F4E .
>
> Below you seem to be specifically referring to the IOAM open source
> implementation in FD.io/VPP: There are protocol encapsulations for
> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses
> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for
> NSH. As you’re well aware, there the discussion in SFC whether to use
> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled,
> hence we’ll refrain from updating the code until SFC WG has come to a
> conclusion.
>
>
>
> Could you provide a pointer to an OOAM implementation?
>
>
>
> Thanks,
>
> Frank
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Donnerstag, 12. April 2018 18:54
> *To:* Frank Brockners (fbrockne) 
> *Cc:* IETF IPPM WG ; NVO3 ; Service
> Function Chaining IETF list ; int-a...@ietf.org
> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
>
>
>
> Hi Frank,
>
> thank you for sharing your points. Please find my notes in-line and tagged
> GIM>>. I believe that this is very much relevant to work of other working
> groups that directly work on the overlay encapsulations in the center of
> the discussion and hence I've added them to the list. Hope we'll have more
> opinions to reach the conclusion that is acceptable to all.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <
> fbroc...@cisco.com> wrote:
>
> Back at the IPPM meeting in London, we discussed several drafts dealing
> with the encapsulation of IOAM data in various protocols
> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
> could be leveraged.  After carefully considering 
> draft-ooamdt-rtgwg-ooam-header,
> I came to the conclusion that the “OOAM header” does not meet the needs of
> IOAM:
>
> * Efficiency: IOAM adds data to live user traffic. As such, an
> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
> bytes long. The approach for IOAM data encapsulation in the above mentioned
> drafts only requires 4 bytes. Using the OOAM header approach would add an
> unnecessary overhead of 4 bytes – which is significant.
>
> GIM>> The difference in four octets is because OOAM Header:
>
>- provides more flexibility, e.g. Flags field and Reserved fields;
>- supports larger OAM packets than iOAM header;
>- is future proof by supporting versioning (Version field).
>
> * Maturity: IOAM has several implementations, which were also shown at
> recent IETF hackathons – and we’re expecting additional implementations to
> be publicized soon. Interoperable implementations need timely
> specifications. Despite the question being asked, the recent thread on OOAM
> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
> addition, the thread revealed that several fundamental questions about the
> OOAM header are still open, such as whether or how active OAM mechanisms
> within protocols such as Geneve would apply to the OOAM header. This
> ultimately means that we won’t get to a timely specification.
>
> GIM>> May I ask which encapsulations supported by the implementations you
> refer to. Until very recently all iOAM proposals were to use meta-data TLV
> in, e.g. Geneve and NSH. And if these or some of these implementations
> already updated to the newly proposed iOAM shim, I don't see problem in
> making them use OOAM Header. Would you agree?
>
>
>
> * Scope: It isn’t entirely clear to which protocols the OOAM header would
> ultimately apply to. The way the 

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Frank Brockners (fbrockne)]

Hi Greg,

thanks – and it seems that we’re on the same page with regards to efficiency (4 
bytes of non-required overhead) and maturity (or lack of) of OOAM.

On the IOAM implementation: There are several implementations of IOAM. Some of 
which have recently been worked on and shown at an IETF hackathon, see 
https://datatracker.ietf.org/meeting/100/materials/slides-100-hackathon-sessa-in-situ-oam-ioam
 - where we’ve shown IPv6 and VXLAN-GPE with IOAM – on FD.io/VPP as well as on 
Barefoot Tofino. You probably also remember the Netronome/Broadcom demo - 
https://www.youtube.com/watch?v=j9FbD4a3F4E .
Below you seem to be specifically referring to the IOAM open source 
implementation in FD.io/VPP: There are protocol encapsulations for VXLAN-GPE, 
NSH, and IPv6 implemented in FD.io/VPP. The current code uses the “next header 
approach” for VXLAN-GPE and it leverages MD-Type 2 for NSH. As you’re well 
aware, there the discussion in SFC whether to use MD-Type 2 or next header 
encapsulating IOAM data in NSH isn’t yet settled, hence we’ll refrain from 
updating the code until SFC WG has come to a conclusion.

Could you provide a pointer to an OOAM implementation?

Thanks,
Frank

From: Greg Mirsky 
Sent: Donnerstag, 12. April 2018 18:54
To: Frank Brockners (fbrockne) 
Cc: IETF IPPM WG ; NVO3 ; Service Function 
Chaining IETF list ; int-a...@ietf.org
Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up 
from WG discussion in London

Hi Frank,
thank you for sharing your points. Please find my notes in-line and tagged 
GIM>>. I believe that this is very much relevant to work of other working 
groups that directly work on the overlay encapsulations in the center of the 
discussion and hence I've added them to the list. Hope we'll have more opinions 
to reach the conclusion that is acceptable to all.

Regards,
Greg

On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) 
> wrote:
Back at the IPPM meeting in London, we discussed several drafts dealing with 
the encapsulation of IOAM data in various protocols 
(draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, 
draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to 
the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be 
leveraged.  After carefully considering draft-ooamdt-rtgwg-ooam-header, I came 
to the conclusion that the “OOAM header” does not meet the needs of IOAM:
* Efficiency: IOAM adds data to live user traffic. As such, an encapsulation 
needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The 
approach for IOAM data encapsulation in the above mentioned drafts only 
requires 4 bytes. Using the OOAM header approach would add an unnecessary 
overhead of 4 bytes – which is significant.
GIM>> The difference in four octets is because OOAM Header:

  *   provides more flexibility, e.g. Flags field and Reserved fields;
  *   supports larger OAM packets than iOAM header;
  *   is future proof by supporting versioning (Version field).
* Maturity: IOAM has several implementations, which were also shown at recent 
IETF hackathons – and we’re expecting additional implementations to be 
publicized soon. Interoperable implementations need timely specifications. 
Despite the question being asked, the recent thread on OOAM in the NVO3 list 
hasn’t revealed any implementation of the OOAM header. In addition, the thread 
revealed that several fundamental questions about the OOAM header are still 
open, such as whether or how active OAM mechanisms within protocols such as 
Geneve would apply to the OOAM header. This ultimately means that we won’t get 
to a timely specification.
GIM>> May I ask which encapsulations supported by the implementations you refer 
to. Until very recently all iOAM proposals were to use meta-data TLV in, e.g. 
Geneve and NSH. And if these or some of these implementations already updated 
to the newly proposed iOAM shim, I don't see problem in making them use OOAM 
Header. Would you agree?

* Scope: It isn’t entirely clear to which protocols the OOAM header would 
ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit 
field for “Next Prot”, the next protocol. Some protocols that IOAM data needs 
to be encapsulated into use 16-bits for their next protocol code points. See 
e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00.
GIM>> The first paragraph of the Introduction section states:
   New protocols that support overlay networks like VxLAN-GPE
   [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve
   [I-D.ietf-nvo3-geneve], BIER [I-D.ietf-bier-mpls-encapsulation], and
   NSH [I-D.ietf-sfc-nsh] support multi-protocol payload, e.g.
   Ethernet, IPv4/IPv6, and recognize Operations, Administration, and
   Maintenance (OAM) as one of distinct types.  

Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi Frank,
thank you for sharing your points. Please find my notes in-line and tagged
GIM>>. I believe that this is very much relevant to work of other working
groups that directly work on the overlay encapsulations in the center of
the discussion and hence I've added them to the list. Hope we'll have more
opinions to reach the conclusion that is acceptable to all.

Regards,
Greg

On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Back at the IPPM meeting in London, we discussed several drafts dealing
> with the encapsulation of IOAM data in various protocols
> (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00,
> draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take
> to the list was the question on whether draft-ooamdt-rtgwg-ooam-header
> could be leveraged.  After carefully considering 
> draft-ooamdt-rtgwg-ooam-header,
> I came to the conclusion that the “OOAM header” does not meet the needs of
> IOAM:
>
> * Efficiency: IOAM adds data to live user traffic. As such, an
> encapsulation needs to be as efficient as possible. The “OOAM header” is 8
> bytes long. The approach for IOAM data encapsulation in the above mentioned
> drafts only requires 4 bytes. Using the OOAM header approach would add an
> unnecessary overhead of 4 bytes – which is significant.
>
GIM>> The difference in four octets is because OOAM Header:

   - provides more flexibility, e.g. Flags field and Reserved fields;
   - supports larger OAM packets than iOAM header;
   - is future proof by supporting versioning (Version field).

* Maturity: IOAM has several implementations, which were also shown at
> recent IETF hackathons – and we’re expecting additional implementations to
> be publicized soon. Interoperable implementations need timely
> specifications. Despite the question being asked, the recent thread on OOAM
> in the NVO3 list hasn’t revealed any implementation of the OOAM header. In
> addition, the thread revealed that several fundamental questions about the
> OOAM header are still open, such as whether or how active OAM mechanisms
> within protocols such as Geneve would apply to the OOAM header. This
> ultimately means that we won’t get to a timely specification.
>
GIM>> May I ask which encapsulations supported by the implementations you
refer to. Until very recently all iOAM proposals were to use meta-data TLV
in, e.g. Geneve and NSH. And if these or some of these implementations
already updated to the newly proposed iOAM shim, I don't see problem in
making them use OOAM Header. Would you agree?


> * Scope: It isn’t entirely clear to which protocols the OOAM header would
> ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit
> field for “Next Prot”, the next protocol. Some protocols that IOAM data
> needs to be encapsulated into use 16-bits for their next protocol code
> points. See e.g. the GRE encapsulation – as specified in
> draft-weis-ippm-ioam-gre-00.
>
GIM>> The first paragraph of the Introduction section states:
   New protocols that support overlay networks like VxLAN-GPE
   [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve
   [I-D.ietf-nvo3-geneve], BIER [I-D.ietf-bier-mpls-encapsulation], and
   NSH [I-D.ietf-sfc-nsh] support multi-protocol payload, e.g.
   Ethernet, IPv4/IPv6, and recognize Operations, Administration, and
   Maintenance (OAM) as one of distinct types.  That ensures that
   Overlay OAM (OOAM)packets are sharing fate with Overlay data packet
   traversing the underlay.
I'm updating the OOAM Header draft and along with cleaning nits will update
reference to GUE. I think that the list and the statemnt are quite clear in
identifying the scope of networks that may benefit from using not only
common OOAM Header but common OOAM mechanisms, e.g. Echo Request/Reply
.

With the above in mind, I’d suggest that the WG moves forward with specific
> definitions for encapsulating IOAM data into protocols – per the above
> mentioned drafts.
>
>
>
> Regards, Frank
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3