Re: [Int-area] [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-area@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: [Int-area] [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-area@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
>
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [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-area@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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [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-area@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: [Int-area] [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
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [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-area@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: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Tom Herbert]

On Mon, Apr 16, 2018 at 6:31 AM, Tianran Zhou  wrote:
> Hi Shwetha,
>
> You are talking about the outer encapsution. It is straight forward for the
> underlay to record by the header. But what about the overlay, i.e., inner
> encapsulation(e.g. geneve)? Without special configuration, intermediate node
> will not read the inner header, hence not be able to process IOAM.e

Hi Tianran,

I believe that is also not protocol conformant. Intermediate nodes
should not be processing transport layer data as this can lead to
misinterpretation and possibly silent data corruption.

For instance, Geneve is a UDP encapsulation protocol with assigned
port 6081. In order for an intermediate device to process the Geneve
encapsulation header it would need to look for packets with
destination port of 6081 since that is the only possible
discriminator. However, transport port numbers do not have global
meaning and hosts may use port numbers for other purposes (RFC7605
describes this). So a packet to port 6081 might be something other
than Geneve and may be misinterpreted. If a misinterpreted packet is
changed (like ippm data is written) then that would be systematic
silent data corruption.

As far as I know, hop-by-hop options is the only protocol confirming
mechanism that allows an intermediate note to change data of packet in
flight. Encpasulation is the only conforming mechanism that allows an
intermediate node to add data (like extension headers) to a packet in
flight.

Tom

> Maybe we are not synced by this overlay/underlay use case. :-)
>
> Tianran
>
>
>
> 
> Sent from WeLink
>
> 发件人： Shwetha Bhandari (shwethab)
> 收件人： Tianran Zhou;Frank Brockners
> (fbrockne);Mickey
> Spiegel;Tom Herbert
> 抄送： NVO3;int-area;Service Function
> Chaining IETF list;IETF IPPM WG
> 主题： Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
> 时间： 2018-04-16 18:17:01
>
> Hi Tianran,
>
>> If I recall right, it is not written in the ioam data draft.
>
> Data draft is defining the data to be carried in IOAM in an encapsulation
> agnostic way, it does not specify how the encapsulation protocol is
> configured.
>
>
>
>> Yes, node by node configuration is an easy way.
>
> While it is, it does not have to be a node by node configuration. It can be
> part of the encapsulation definition.
>
> For e.g. If the encapsulation is IPv6 and if we define the data to be
> carried as HbH options, then based on the Option Type with highest order 2
> bits set to 00 then the v6 nodes that implement IOAM will process the option
> and others will skip over.
>
>
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> From: ippm  on behalf of Tianran Zhou
> 
> Date: Monday, April 16, 2018 at 2:36 PM
> To: "Frank Brockners (fbrockne)" , Mickey Spiegel
> , Tom Herbert 
> Cc: NVO3 , "int-area@ietf.org" , Service
> Function Chaining IETF list , IETF IPPM WG 
> Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various
> protocols - follow up from WG discussion in London
>
>
>
> Hi Frank,
>
>
>
> If I recall right, it is not written in the ioam data draft.
>
> Yes, node by node configuration is an easy way. In the
> draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate the
> layering.
>
>+--rw ioam
>
>   +--rw ioam-profiles
>
>  +--rw enabled?boolean
>
>  +--rw ioam-profile* [profile-name]
>
> +--rw profile-namestring
>
> +--rw filter
>
> |  +--rw filter-type?   ioam-filter-type
>
> |  +--rw acl-name?  -> /acl:acls/acl/name
>
> +--rw protocol-type?  ioam-protocol-type
>
> +--rw incremental-tracing-profile {incremental-trace}?
>
> |  ...
>
> +--rw preallocated-tracing-profile {preallocated-trace}?
>
> |  ...
>
> +--rw pot-profile {proof-of-transit}?
>
> |  ...
>
> +--rw e2e-profile {edge-to-edge}?
>
>...
>
>
>
>
>
> Tianran
>
> From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
> Sent: Monday, April 16, 2018 4:51 PM
> To: Tianran Zhou ; Mickey Spiegel
> ; Tom Herbert 
> Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF
> list ; IETF IPPM WG 
> Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various
> protocols - follow up from WG discussion in London
>
>
>
> Hi Tianran,
>
>
>
> IOAM is a domain specific feature (see also 

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

[Tianran Zhou]

Hi Shwetha,

You are talking about the outer encapsution. It is straight forward for the 
underlay to record by the header. But what about the overlay, i.e., inner 
encapsulation(e.g. geneve)? Without special configuration, intermediate node 
will not read the inner header, hence not be able to process IOAM.
Maybe we are not synced by this overlay/underlay use case. :-)

Tianran




Sent from WeLink

发件人： Shwetha Bhandari (shwethab)
收件人： Tianran Zhou>;Frank 
Brockners (fbrockne)>;Mickey 
Spiegel>;Tom
 Herbert>
抄送： 
NVO3>;int-area>;Service
 Function Chaining IETF list>;IETF IPPM 
WG>
主题： Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols - 
follow up from WG discussion in London
时间： 2018-04-16 18:17:01

Hi Tianran,
> If I recall right, it is not written in the ioam data draft.
Data draft is defining the data to be carried in IOAM in an encapsulation 
agnostic way, it does not specify how the encapsulation protocol is configured.

> Yes, node by node configuration is an easy way.
While it is, it does not have to be a node by node configuration. It can be 
part of the encapsulation definition.
For e.g. If the encapsulation is IPv6 and if we define the data to be carried 
as HbH options, then based on the Option Type with highest order 2 bits set to 
00 then the v6 nodes that implement IOAM will process the option and others 
will skip over.


Thanks,
Shwetha

From: ippm  on behalf of Tianran Zhou 

Date: Monday, April 16, 2018 at 2:36 PM
To: "Frank Brockners (fbrockne)" , Mickey Spiegel 
, Tom Herbert 
Cc: NVO3 , "int-area@ietf.org" , Service 
Function Chaining IETF list , IETF IPPM WG 
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Hi Frank,

If I recall right, it is not written in the ioam data draft.
Yes, node by node configuration is an easy way. In the 
draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate the layering.
   +--rw ioam
  +--rw ioam-profiles
 +--rw enabled?boolean
 +--rw ioam-profile* [profile-name]
+--rw profile-namestring
+--rw filter
|  +--rw filter-type?   ioam-filter-type
|  +--rw acl-name?  -> /acl:acls/acl/name
+--rw protocol-type?  ioam-protocol-type
+--rw incremental-tracing-profile {incremental-trace}?
|  ...
+--rw preallocated-tracing-profile {preallocated-trace}?
|  ...
+--rw pot-profile {proof-of-transit}?
|  ...
+--rw e2e-profile {edge-to-edge}?
   ...


Tianran
From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Sent: Monday, April 16, 2018 4:51 PM
To: Tianran Zhou ; Mickey Spiegel 
; Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Hi Tianran,

IOAM is a domain specific feature (see also draft-ietf-ippm-ioam-data-02 
sections 3 and 4), which allows an operator to control by means of 
configuration where and for which traffic IOAM data fields are 
added/updated/removed from the customer traffic. Using your example of Geneve 
over IPv6 �C with IOAM data in both the Geneve and the IPv6 protocol, one would 
expect that the operator configures the endpoints of the Geneve tunnel to 
operate on the IOAM data in Geneve, and the IPv6 routers that the Geneve tunnel 
traverses to operate on the IOAM data in IPv6.

Frank

From: Tianran Zhou >
Sent: Montag, 16. April 2018 10:37
To: Frank Brockners (fbrockne) >; 
Mickey Spiegel 
>; Tom 
Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in 

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

[Frank Brockners (fbrockne)]

Hi Tianran,

IOAM is a domain specific feature (see also draft-ietf-ippm-ioam-data-02 
sections 3 and 4), which allows an operator to control by means of 
configuration where and for which traffic IOAM data fields are 
added/updated/removed from the customer traffic. Using your example of Geneve 
over IPv6 – with IOAM data in both the Geneve and the IPv6 protocol, one would 
expect that the operator configures the endpoints of the Geneve tunnel to 
operate on the IOAM data in Geneve, and the IPv6 routers that the Geneve tunnel 
traverses to operate on the IOAM data in IPv6.

Frank

From: Tianran Zhou 
Sent: Montag, 16. April 2018 10:37
To: Frank Brockners (fbrockne) ; Mickey Spiegel 
; Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Hi Frank,

How does a forwarder know when and where to insert the data?
In the case of Geneve over IPv6, do you mean the device need to scan all the 
protocol stack? Or just the outer encapsulation?

Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Frank Brockners 
(fbrockne)
Sent: Monday, April 16, 2018 3:08 PM
To: Mickey Spiegel 
>; Tom 
Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London


Tom,

a quick addition to what Mickey mentioned below: What you seem to have in mind 
is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), 
i.e. if you’re running for example Geneve over IPv6, then IOAM data could be 
encapsulated in both protocols, Geneve and IPv6 – giving you visibility into 
the “underlay” (IPv6) and the “overlay” (Geneve).

Frank

From: ippm > On Behalf Of 
Mickey Spiegel
Sent: Freitag, 13. April 2018 20:22
To: Tom Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Tom,

On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert 
> wrote:
Mickey,

Looking at these ippm drafts more closely, I have a much more
fundamental concern.

In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
in the introduction:

"In-situ OAM (IOAM) records OAM information within the packet while
the packet traverses a particular network domain.  The term "in-situ"
refers to the fact that the IOAM data fields are added to the data
packets rather than is being sent within packets specifically
dedicated to OAM.  This document defines how IOAM data fields are
transported as part of the Geneve [I-D.ietf-nvo3-geneve]
encapsulation."

I assume this means that as packets with Geneve encapsulation traverse
the network they are interpreted by intermediate nodes as being
Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
port number would be used to identify packets as being Geneve. So an
intermediate device might be looking for UDP packets destined to port
6081 (the assigned UDP port for Geneve). If my understanding is
correct, then this is a problem.

UDP port numbers do not have global meaning. An intermediate device
may very well see UDP packets destined to port 6081 that are not
actually Geneve. This scenario is discussed in RFC7605:

"...intermediate device interprets traffic based on the port number.
It is important to recognize that any interpretation of port numbers
-- except at the endpoints -- may be incorrect, because port numbers
are meaningful only at the endpoints."

If the UDP data is modified, as the draft would imply, then
misinterpretation may also mean silent data corruption of packets. A
protocol that would allow this seems pretty incorrect! Note that this
would be true also for any UDP encapsulation that the network tries to
interpret.

The intention is to allow for multiple nodes that a packet traverses
to be able to insert IOAM node information in the same trace option,
but leave some flexibility regarding which nodes actually do the
IOAM processing and the node information. This may vary
depending on the transport.

In case of a tunneled encapsulation 

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

[Shwetha Bhandari (shwethab)]

Hi Tianran,

> If I recall right, it is not written in the ioam data draft.

Data draft is defining the data to be carried in IOAM in an encapsulation 
agnostic way, it does not specify how the encapsulation protocol is configured.

 

> Yes, node by node configuration is an easy way.

While it is, it does not have to be a node by node configuration. It can be 
part of the encapsulation definition. 

For e.g. If the encapsulation is IPv6 and if we define the data to be carried 
as HbH options, then based on the Option Type with highest order 2 bits set to 
00 then the v6 nodes that implement IOAM will process the option and others 
will skip over.

 

 

Thanks,

Shwetha

 

From: ippm  on behalf of Tianran Zhou 

Date: Monday, April 16, 2018 at 2:36 PM
To: "Frank Brockners (fbrockne)" , Mickey Spiegel 
, Tom Herbert 
Cc: NVO3 , "int-area@ietf.org" , Service 
Function Chaining IETF list , IETF IPPM WG 
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

 

Hi Frank,

 

If I recall right, it is not written in the ioam data draft.

Yes, node by node configuration is an easy way. In the 
draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate the layering.

   +--rw ioam

  +--rw ioam-profiles

 +--rw enabled?boolean

 +--rw ioam-profile* [profile-name]

+--rw profile-namestring

+--rw filter

|  +--rw filter-type?   ioam-filter-type

|  +--rw acl-name?  -> /acl:acls/acl/name

+--rw protocol-type?  ioam-protocol-type

+--rw incremental-tracing-profile {incremental-trace}?

|  ...

+--rw preallocated-tracing-profile {preallocated-trace}?

|  ...

+--rw pot-profile {proof-of-transit}?

|  ...

+--rw e2e-profile {edge-to-edge}?

   ...

 

 

Tianran

From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com] 
Sent: Monday, April 16, 2018 4:51 PM
To: Tianran Zhou ; Mickey Spiegel 
; Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

 

Hi Tianran,

 

IOAM is a domain specific feature (see also draft-ietf-ippm-ioam-data-02 
sections 3 and 4), which allows an operator to control by means of 
configuration where and for which traffic IOAM data fields are 
added/updated/removed from the customer traffic. Using your example of Geneve 
over IPv6 – with IOAM data in both the Geneve and the IPv6 protocol, one would 
expect that the operator configures the endpoints of the Geneve tunnel to 
operate on the IOAM data in Geneve, and the IPv6 routers that the Geneve tunnel 
traverses to operate on the IOAM data in IPv6. 

 

Frank

 

From: Tianran Zhou  
Sent: Montag, 16. April 2018 10:37
To: Frank Brockners (fbrockne) ; Mickey Spiegel 
; Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

 

Hi Frank,

 

How does a forwarder know when and where to insert the data? 

In the case of Geneve over IPv6, do you mean the device need to scan all the 
protocol stack? Or just the outer encapsulation?

 

Tianran

 

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Frank Brockners 
(fbrockne)
Sent: Monday, April 16, 2018 3:08 PM
To: Mickey Spiegel ; Tom Herbert 

Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

 

 

Tom,

 

a quick addition to what Mickey mentioned below: What you seem to have in mind 
is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), 
i.e. if you’re running for example Geneve over IPv6, then IOAM data could be 
encapsulated in both protocols, Geneve and IPv6 – giving you visibility into 
the “underlay” (IPv6) and the “overlay” (Geneve). 

 

Frank

 

From: ippm  On Behalf Of Mickey Spiegel
Sent: Freitag, 13. April 2018 20:22
To: Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining 

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

[Tianran Zhou]

Hi Frank,

How does a forwarder know when and where to insert the data?
In the case of Geneve over IPv6, do you mean the device need to scan all the 
protocol stack? Or just the outer encapsulation?

Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Frank Brockners 
(fbrockne)
Sent: Monday, April 16, 2018 3:08 PM
To: Mickey Spiegel ; Tom Herbert 

Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London


Tom,

a quick addition to what Mickey mentioned below: What you seem to have in mind 
is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), 
i.e. if you’re running for example Geneve over IPv6, then IOAM data could be 
encapsulated in both protocols, Geneve and IPv6 – giving you visibility into 
the “underlay” (IPv6) and the “overlay” (Geneve).

Frank

From: ippm > On Behalf Of 
Mickey Spiegel
Sent: Freitag, 13. April 2018 20:22
To: Tom Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Tom,

On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert 
> wrote:
Mickey,

Looking at these ippm drafts more closely, I have a much more
fundamental concern.

In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
in the introduction:

"In-situ OAM (IOAM) records OAM information within the packet while
the packet traverses a particular network domain.  The term "in-situ"
refers to the fact that the IOAM data fields are added to the data
packets rather than is being sent within packets specifically
dedicated to OAM.  This document defines how IOAM data fields are
transported as part of the Geneve [I-D.ietf-nvo3-geneve]
encapsulation."

I assume this means that as packets with Geneve encapsulation traverse
the network they are interpreted by intermediate nodes as being
Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
port number would be used to identify packets as being Geneve. So an
intermediate device might be looking for UDP packets destined to port
6081 (the assigned UDP port for Geneve). If my understanding is
correct, then this is a problem.

UDP port numbers do not have global meaning. An intermediate device
may very well see UDP packets destined to port 6081 that are not
actually Geneve. This scenario is discussed in RFC7605:

"...intermediate device interprets traffic based on the port number.
It is important to recognize that any interpretation of port numbers
-- except at the endpoints -- may be incorrect, because port numbers
are meaningful only at the endpoints."

If the UDP data is modified, as the draft would imply, then
misinterpretation may also mean silent data corruption of packets. A
protocol that would allow this seems pretty incorrect! Note that this
would be true also for any UDP encapsulation that the network tries to
interpret.

The intention is to allow for multiple nodes that a packet traverses
to be able to insert IOAM node information in the same trace option,
but leave some flexibility regarding which nodes actually do the
IOAM processing and the node information. This may vary
depending on the transport.

In case of a tunneled encapsulation such as Geneve or VXLAN,
there may still be multiple hops. For example a network may use
Geneve or VXLAN, but only do L2 processing at ToRs, with L3
processing done at aggregation or core switches. In this case
many packets would do 2 Geneve or VXLAN hops, so the packet
would contain IOAM node information from two nodes.

Another example is service function chaining using Geneve or
VXLAN rather than NSH.


I am also wondering if hop-by-hop options been considered for this
application? Their interpretation in the network is unabiguous and
they also have the advantage that the work with any IP protocol or
encapsulation.

IPv6 hop-by-hop options has been considered. See
draft-brockners-inband-oam-transport-05. This has not yet been
broken out into a separate draft.

Mickey


Thanks,
Tom


On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
> wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert 
> > wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> >
>> wrote:
>> > Hi Frank,
>> > thank you for sharing your points. 

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

[Tianran Zhou]

Hi Frank,

If I recall right, it is not written in the ioam data draft.
Yes, node by node configuration is an easy way. In the 
draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate the layering.
   +--rw ioam
  +--rw ioam-profiles
 +--rw enabled?boolean
 +--rw ioam-profile* [profile-name]
+--rw profile-namestring
+--rw filter
|  +--rw filter-type?   ioam-filter-type
|  +--rw acl-name?  -> /acl:acls/acl/name
+--rw protocol-type?  ioam-protocol-type
+--rw incremental-tracing-profile {incremental-trace}?
|  ...
+--rw preallocated-tracing-profile {preallocated-trace}?
|  ...
+--rw pot-profile {proof-of-transit}?
|  ...
+--rw e2e-profile {edge-to-edge}?
   ...


Tianran
From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Sent: Monday, April 16, 2018 4:51 PM
To: Tianran Zhou ; Mickey Spiegel 
; Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Hi Tianran,

IOAM is a domain specific feature (see also draft-ietf-ippm-ioam-data-02 
sections 3 and 4), which allows an operator to control by means of 
configuration where and for which traffic IOAM data fields are 
added/updated/removed from the customer traffic. Using your example of Geneve 
over IPv6 – with IOAM data in both the Geneve and the IPv6 protocol, one would 
expect that the operator configures the endpoints of the Geneve tunnel to 
operate on the IOAM data in Geneve, and the IPv6 routers that the Geneve tunnel 
traverses to operate on the IOAM data in IPv6.

Frank

From: Tianran Zhou >
Sent: Montag, 16. April 2018 10:37
To: Frank Brockners (fbrockne) >; 
Mickey Spiegel 
>; Tom 
Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Hi Frank,

How does a forwarder know when and where to insert the data?
In the case of Geneve over IPv6, do you mean the device need to scan all the 
protocol stack? Or just the outer encapsulation?

Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Frank Brockners 
(fbrockne)
Sent: Monday, April 16, 2018 3:08 PM
To: Mickey Spiegel 
>; Tom 
Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London


Tom,

a quick addition to what Mickey mentioned below: What you seem to have in mind 
is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), 
i.e. if you’re running for example Geneve over IPv6, then IOAM data could be 
encapsulated in both protocols, Geneve and IPv6 – giving you visibility into 
the “underlay” (IPv6) and the “overlay” (Geneve).

Frank

From: ippm > On Behalf Of 
Mickey Spiegel
Sent: Freitag, 13. April 2018 20:22
To: Tom Herbert >
Cc: NVO3 >; 
int-area@ietf.org; Service Function Chaining IETF 
list >; IETF IPPM WG 
>
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Tom,

On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert 
> wrote:
Mickey,

Looking at these ippm drafts more closely, I have a much more
fundamental concern.

In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
in the introduction:

"In-situ OAM (IOAM) records OAM information within the packet while
the packet traverses a particular network domain.  The term "in-situ"
refers to the fact that the IOAM data fields are added to the data
packets rather than is being sent within packets specifically
dedicated to OAM.  

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

[Frank Brockners (fbrockne)]

Tom,

a quick addition to what Mickey mentioned below: What you seem to have in mind 
is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), 
i.e. if you’re running for example Geneve over IPv6, then IOAM data could be 
encapsulated in both protocols, Geneve and IPv6 – giving you visibility into 
the “underlay” (IPv6) and the “overlay” (Geneve).

Frank

From: ippm  On Behalf Of Mickey Spiegel
Sent: Freitag, 13. April 2018 20:22
To: Tom Herbert 
Cc: NVO3 ; int-area@ietf.org; Service Function Chaining IETF 
list ; IETF IPPM WG 
Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various protocols 
- follow up from WG discussion in London

Tom,

On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert 
> wrote:
Mickey,

Looking at these ippm drafts more closely, I have a much more
fundamental concern.

In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
in the introduction:

"In-situ OAM (IOAM) records OAM information within the packet while
the packet traverses a particular network domain.  The term "in-situ"
refers to the fact that the IOAM data fields are added to the data
packets rather than is being sent within packets specifically
dedicated to OAM.  This document defines how IOAM data fields are
transported as part of the Geneve [I-D.ietf-nvo3-geneve]
encapsulation."

I assume this means that as packets with Geneve encapsulation traverse
the network they are interpreted by intermediate nodes as being
Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
port number would be used to identify packets as being Geneve. So an
intermediate device might be looking for UDP packets destined to port
6081 (the assigned UDP port for Geneve). If my understanding is
correct, then this is a problem.

UDP port numbers do not have global meaning. An intermediate device
may very well see UDP packets destined to port 6081 that are not
actually Geneve. This scenario is discussed in RFC7605:

"...intermediate device interprets traffic based on the port number.
It is important to recognize that any interpretation of port numbers
-- except at the endpoints -- may be incorrect, because port numbers
are meaningful only at the endpoints."

If the UDP data is modified, as the draft would imply, then
misinterpretation may also mean silent data corruption of packets. A
protocol that would allow this seems pretty incorrect! Note that this
would be true also for any UDP encapsulation that the network tries to
interpret.

The intention is to allow for multiple nodes that a packet traverses
to be able to insert IOAM node information in the same trace option,
but leave some flexibility regarding which nodes actually do the
IOAM processing and the node information. This may vary
depending on the transport.

In case of a tunneled encapsulation such as Geneve or VXLAN,
there may still be multiple hops. For example a network may use
Geneve or VXLAN, but only do L2 processing at ToRs, with L3
processing done at aggregation or core switches. In this case
many packets would do 2 Geneve or VXLAN hops, so the packet
would contain IOAM node information from two nodes.

Another example is service function chaining using Geneve or
VXLAN rather than NSH.


I am also wondering if hop-by-hop options been considered for this
application? Their interpretation in the network is unabiguous and
they also have the advantage that the work with any IP protocol or
encapsulation.

IPv6 hop-by-hop options has been considered. See
draft-brockners-inband-oam-transport-05. This has not yet been
broken out into a separate draft.

Mickey


Thanks,
Tom


On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
> wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert 
> > wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> >
>> wrote:
>> > 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 

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

[Tom Herbert]

On Fri, Apr 13, 2018 at 11:22 AM, Mickey Spiegel
 wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert  wrote:
>>
>> Mickey,
>>
>> Looking at these ippm drafts more closely, I have a much more
>> fundamental concern.
>>
>> In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
>> in the introduction:
>>
>> "In-situ OAM (IOAM) records OAM information within the packet while
>> the packet traverses a particular network domain.  The term "in-situ"
>> refers to the fact that the IOAM data fields are added to the data
>> packets rather than is being sent within packets specifically
>> dedicated to OAM.  This document defines how IOAM data fields are
>> transported as part of the Geneve [I-D.ietf-nvo3-geneve]
>> encapsulation."
>>
>> I assume this means that as packets with Geneve encapsulation traverse
>> the network they are interpreted by intermediate nodes as being
>> Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
>> port number would be used to identify packets as being Geneve. So an
>> intermediate device might be looking for UDP packets destined to port
>> 6081 (the assigned UDP port for Geneve). If my understanding is
>> correct, then this is a problem.
>>
>> UDP port numbers do not have global meaning. An intermediate device
>> may very well see UDP packets destined to port 6081 that are not
>> actually Geneve. This scenario is discussed in RFC7605:
>>
>> "...intermediate device interprets traffic based on the port number.
>> It is important to recognize that any interpretation of port numbers
>> -- except at the endpoints -- may be incorrect, because port numbers
>> are meaningful only at the endpoints."
>>
>> If the UDP data is modified, as the draft would imply, then
>> misinterpretation may also mean silent data corruption of packets. A
>> protocol that would allow this seems pretty incorrect! Note that this
>> would be true also for any UDP encapsulation that the network tries to
>> interpret.
>
>
> The intention is to allow for multiple nodes that a packet traverses
> to be able to insert IOAM node information in the same trace option,
> but leave some flexibility regarding which nodes actually do the
> IOAM processing and the node information. This may vary
> depending on the transport.
>
> In case of a tunneled encapsulation such as Geneve or VXLAN,
> there may still be multiple hops. For example a network may use
> Geneve or VXLAN, but only do L2 processing at ToRs, with L3
> processing done at aggregation or core switches. In this case
> many packets would do 2 Geneve or VXLAN hops, so the packet
> would contain IOAM node information from two nodes.
>
Mickey,

Thanks, for the explanation. The requirements around this are not
clear in the drafts so I would suggest that be clarified. Intermediate
nodes should never look at, much less change, transport layer data for
packets for which they are not the addressee (we've already seen
several instances of implemenations skirting these rules out of
convenience!)

One other nit: I don't think a six page I-D really needs twelve
authors! Please consider reducing the number to only the major
contributors.

Tom

> Another example is service function chaining using Geneve or
> VXLAN rather than NSH.
>
>>
>> I am also wondering if hop-by-hop options been considered for this
>> application? Their interpretation in the network is unabiguous and
>> they also have the advantage that the work with any IP protocol or
>> encapsulation.
>
>
> IPv6 hop-by-hop options has been considered. See
> draft-brockners-inband-oam-transport-05. This has not yet been
> broken out into a separate draft.
>
> Mickey
>
>>
>> Thanks,
>> Tom
>>
>>
>> On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
>>  wrote:
>> > Tom,
>> >
>> > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert 
>> > wrote:
>> >>
>> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> >> wrote:
>> >> > 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 

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

[Mickey Spiegel]

Tom,

On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert  wrote:

> Mickey,
>
> Looking at these ippm drafts more closely, I have a much more
> fundamental concern.
>
> In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
> in the introduction:
>
> "In-situ OAM (IOAM) records OAM information within the packet while
> the packet traverses a particular network domain.  The term "in-situ"
> refers to the fact that the IOAM data fields are added to the data
> packets rather than is being sent within packets specifically
> dedicated to OAM.  This document defines how IOAM data fields are
> transported as part of the Geneve [I-D.ietf-nvo3-geneve]
> encapsulation."
>
> I assume this means that as packets with Geneve encapsulation traverse
> the network they are interpreted by intermediate nodes as being
> Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
> port number would be used to identify packets as being Geneve. So an
> intermediate device might be looking for UDP packets destined to port
> 6081 (the assigned UDP port for Geneve). If my understanding is
> correct, then this is a problem.
>
> UDP port numbers do not have global meaning. An intermediate device
> may very well see UDP packets destined to port 6081 that are not
> actually Geneve. This scenario is discussed in RFC7605:
>
> "...intermediate device interprets traffic based on the port number.
> It is important to recognize that any interpretation of port numbers
> -- except at the endpoints -- may be incorrect, because port numbers
> are meaningful only at the endpoints."
>
> If the UDP data is modified, as the draft would imply, then
> misinterpretation may also mean silent data corruption of packets. A
> protocol that would allow this seems pretty incorrect! Note that this
> would be true also for any UDP encapsulation that the network tries to
> interpret.
>

The intention is to allow for multiple nodes that a packet traverses
to be able to insert IOAM node information in the same trace option,
but leave some flexibility regarding which nodes actually do the
IOAM processing and the node information. This may vary
depending on the transport.

In case of a tunneled encapsulation such as Geneve or VXLAN,
there may still be multiple hops. For example a network may use
Geneve or VXLAN, but only do L2 processing at ToRs, with L3
processing done at aggregation or core switches. In this case
many packets would do 2 Geneve or VXLAN hops, so the packet
would contain IOAM node information from two nodes.

Another example is service function chaining using Geneve or
VXLAN rather than NSH.


> I am also wondering if hop-by-hop options been considered for this
> application? Their interpretation in the network is unabiguous and
> they also have the advantage that the work with any IP protocol or
> encapsulation.
>

IPv6 hop-by-hop options has been considered. See
draft-brockners-inband-oam-transport-05. This has not yet been
broken out into a separate draft.

Mickey


> Thanks,
> Tom
>
>
> On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
>  wrote:
> > Tom,
> >
> > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert 
> wrote:
> >>
> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
> >> wrote:
> >> > 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.
> >> Greg,
> >>
> >> I'm missing something here. I looked at the 

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

[徐小虎(义先)]

Hi,
It said in draft-brockners-ippm-ioam-vxlan-gpe-00:
"   [I-D.ietf-nvo3-vxlan-gpe] defines an "O bit" for OAM packets.  Per
   [I-D.ietf-nvo3-vxlan-gpe] the O bit indicates that the packet
   contains an OAM message instead of data payload.  Packets that carry
   IOAM data fields in addition to regular data payload / customer
   traffic must not set the O bit.  Packets that carry only IOAM data
   fields without any payload must set the O bit."
My first question is: if the Next Protocol field within the VXLAN-GPE header 
should be resorted to indicate the IOAM, why do we still need the "O" bit? 
It said in draft-brockners-ippm-ioam-vxlan-gpe-00:
"Next Protocol:  8-bit unsigned integer that determines the type of
  header following IOAM protocol.  The value is from the IANA 
registry setup for VXLAN GPE Next Protocol defined in
  [I-D.ietf-nvo3-vxlan-gpe]."
My second question is: why the "Next Protocol" is designed to be 
context-specific (i.e., specific to the tunnel over which the IOAM data fields 
are contained). In other words, wouldn't it be better to make the Next Protocol 
tunnel-independant since the IOAM is intended to be added into various tunnel 
encapsulations?

My third question is: does it means intermediate nodes must be aware of various 
tunnel encapsulations since the IOAM data field is behind the tunnel header? 
wouldn't it be better to carry the IOAM data just behind the outer IP header?
Best regards,Xiaohu
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.  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 

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

[Frank Brockners (fbrockne)]

Tom,

the term "overhead" here refers to the number of extra bytes used in the parent 
protocol to carry IOAM data. IOAM data itself is of course not counted for the 
comparison, because it would need to be carried in both cases.

Using your Geneve reference as an example, in order to carry IOAM data, we need 
to add another Geneve Option class along with type fields etc. per the Geneve 
draft spec - which sums up to 4 bytes:

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |  Option Class  =  TBD_IOAM| Type  |R|R|R| Length  | 

The OOAM header requires 8 bytes to serve the very same purpose:

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |   Msg Type|   Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags |Reserved   |   Next Prot   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HTH.

Frank



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

On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky  wrote:
> Hi Tom,
> could you please mention which drafts, iOAM or OOAM, you refer to. 
> Please note, that OOAM supports both active and hybrid OAM methods, 
> while iOAM only the latter.

Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance.

>
> Regards,
> Greg
>
> On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert  wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> wrote:
>> > 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.
>> Greg,
>>
>> I'm missing something here. I looked at the drafts you referenced and 
>> each of them looks like the overhead for OAM is greater that four 
>> bytes. In each there is some overhead equivalent to type/length, for 
>> instance in Geneve four bytes are needed for option class, type, and 
>> length. Unless the the OAM data is zero length, I don't see how this 
>> adds up to only four bytes of overhead.
>>
>> Tom
>>
>> >
>> > 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 

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

[Tom Herbert]

Mickey,

Looking at these ippm drafts more closely, I have a much more
fundamental concern.

In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text
in the introduction:

"In-situ OAM (IOAM) records OAM information within the packet while
the packet traverses a particular network domain.  The term "in-situ"
refers to the fact that the IOAM data fields are added to the data
packets rather than is being sent within packets specifically
dedicated to OAM.  This document defines how IOAM data fields are
transported as part of the Geneve [I-D.ietf-nvo3-geneve]
encapsulation."

I assume this means that as packets with Geneve encapsulation traverse
the network they are interpreted by intermediate nodes as being
Geneve. Since Geneve is a UDP encapsulation, then the destination UDP
port number would be used to identify packets as being Geneve. So an
intermediate device might be looking for UDP packets destined to port
6081 (the assigned UDP port for Geneve). If my understanding is
correct, then this is a problem.

UDP port numbers do not have global meaning. An intermediate device
may very well see UDP packets destined to port 6081 that are not
actually Geneve. This scenario is discussed in RFC7605:

"...intermediate device interprets traffic based on the port number.
It is important to recognize that any interpretation of port numbers
-- except at the endpoints -- may be incorrect, because port numbers
are meaningful only at the endpoints."

If the UDP data is modified, as the draft would imply, then
misinterpretation may also mean silent data corruption of packets. A
protocol that would allow this seems pretty incorrect! Note that this
would be true also for any UDP encapsulation that the network tries to
interpret.

I am also wondering if hop-by-hop options been considered for this
application? Their interpretation in the network is unabiguous and
they also have the advantage that the work with any IP protocol or
encapsulation.

Thanks,
Tom


On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
 wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert  wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> wrote:
>> > 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.
>> Greg,
>>
>> I'm missing something here. I looked at the drafts you referenced and
>> each of them looks like the overhead for OAM is greater that four
>> bytes. In each there is some overhead equivalent to type/length, for
>> instance in Geneve four bytes are needed for option class, type, and
>> length. Unless the the OAM data is zero length, I don't see how this
>> adds up to only four bytes of overhead.
>
>
> The four versus eight bytes just refers to the fields in the four bytes of
> IOAM
> info, that is common to all IOAM options. Beyond that, there are IOAM option
> specific fields. For example if doing one of the IOAM trace options, there
> are
> four bytes of trace option header, including the IOAM-trace-type, NodeLen,
> Flags, and RemainingLen fields. These are followed by the node data list
> containing the per hop IOAM information.
>
> In looking at the OOAM header content, it has nothing to do with any of the
> IOAM information after the first four bytes. It contains another variant of
> the
> information in the first four bytes of IOAM info, spread out over eight
> bytes.
>
>>
>> Tom
>>
>> >
>> > GIM>> The difference in four octets is because OOAM Header:
>> >
>> > provides more 

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

[Tom Herbert]

On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
 wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert  wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> wrote:
>> > 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.
>> Greg,
>>
>> I'm missing something here. I looked at the drafts you referenced and
>> each of them looks like the overhead for OAM is greater that four
>> bytes. In each there is some overhead equivalent to type/length, for
>> instance in Geneve four bytes are needed for option class, type, and
>> length. Unless the the OAM data is zero length, I don't see how this
>> adds up to only four bytes of overhead.
>
>
> The four versus eight bytes just refers to the fields in the four bytes of
> IOAM
> info, that is common to all IOAM options. Beyond that, there are IOAM option
> specific fields. For example if doing one of the IOAM trace options, there
> are
> four bytes of trace option header, including the IOAM-trace-type, NodeLen,
> Flags, and RemainingLen fields. These are followed by the node data list
> containing the per hop IOAM information.
>
All of that and people are worried about having four extra bytes of
overhead? :-)

How big are these encapsulation headers in data packets going to be?

Tom

> In looking at the OOAM header content, it has nothing to do with any of the
> IOAM information after the first four bytes. It contains another variant of
> the
> information in the first four bytes of IOAM info, spread out over eight
> bytes.
>
>>
>> Tom
>>
>> >
>> > GIM>> The difference in four octets is because OOAM Header:
>> >
>> > provides more flexibility, e.g. Flags field and Reserved fields;
>
>
> The flags field only has one defined flag at the moment, for a timestamp
> block. For IOAM trace we need per hop timestamps, which the timestamp
> block cannot address, i.e. the timestamp block is redundant for IOAM.
>
>>
>> > supports larger OAM packets than iOAM header;
>
>
> For IOAM purposes, 1020 octets is more than enough.
>
>>
>> > is future proof by supporting versioning (Version field).
>
>
> IMO, taking the first two bits of the IOAM-Type to define a Version field
> would be a good thing. This does not require adding four more bytes of
> overhead. 64 IOAM-Types is more than enough.
>
>>
>> >>
>> >> * 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 

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

[Carlos Pignataro (cpignata)]

Hi, Greg,

Thanks for the quick response — Frank provided answers to your points, but I do 
have one question about your response (and I will squeeze in a couple of 
additional comments).

Please see inline.

On Apr 12, 2018, at 12:54 PM, Greg Mirsky 
> wrote:

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).

Comment: engineering is usually about making trade-offs. Having Reserved 
fields, unnecessary (and over-generalized) Flags, and a Version field for this 
extra OOAM header does not seem to justify the ROI in adding an extra header 
and extra parsing. This goes back to ‘what problem?'. Having a lot of extra 
fields to parse adds overhead, not only in size, but also in complexity tax. 
Please see Fundamental Truths (6a), (10), and (12) [RFC 1925].
* 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.

Question: The “like” in the first sentence, basically implies “not all 
encapsulations”. Therefore, https://xkcd.com/927/.

Further, what are “protocols that support overlay networks”, and how are you 
choosing your examples?

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.


Question: I do not think this is quite clear as you state, given the fact that 
the word 

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

[Mickey Spiegel]

Tom,

On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert  wrote:

> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
> wrote:
> > 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.
> Greg,
>
> I'm missing something here. I looked at the drafts you referenced and
> each of them looks like the overhead for OAM is greater that four
> bytes. In each there is some overhead equivalent to type/length, for
> instance in Geneve four bytes are needed for option class, type, and
> length. Unless the the OAM data is zero length, I don't see how this
> adds up to only four bytes of overhead.
>

The four versus eight bytes just refers to the fields in the four bytes of
IOAM
info, that is common to all IOAM options. Beyond that, there are IOAM option
specific fields. For example if doing one of the IOAM trace options, there
are
four bytes of trace option header, including the IOAM-trace-type, NodeLen,
Flags, and RemainingLen fields. These are followed by the node data list
containing the per hop IOAM information.

In looking at the OOAM header content, it has nothing to do with any of the
IOAM information after the first four bytes. It contains another variant of
the
information in the first four bytes of IOAM info, spread out over eight
bytes.


> Tom
>
> >
> > GIM>> The difference in four octets is because OOAM Header:
> >
> > provides more flexibility, e.g. Flags field and Reserved fields;
>

The flags field only has one defined flag at the moment, for a timestamp
block. For IOAM trace we need per hop timestamps, which the timestamp
block cannot address, i.e. the timestamp block is redundant for IOAM.


> > supports larger OAM packets than iOAM header;
>

For IOAM purposes, 1020 octets is more than enough.


> > is future proof by supporting versioning (Version field).
>

IMO, taking the first two bits of the IOAM-Type to define a Version field
would be a good thing. This does not require adding four more bytes of
overhead. 64 IOAM-Types is more than enough.


> >>
> >> * 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 

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

[Greg Mirsky]

Hi Tom,
I'll let Frank answer your question as it is on iOAM, not OOAM.

Regards,
Greg

On Thu, Apr 12, 2018 at 11:53 PM, Tom Herbert  wrote:

> On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky 
> wrote:
> > Hi Tom,
> > could you please mention which drafts, iOAM or OOAM, you refer to. Please
> > note, that OOAM supports both active and hybrid OAM methods, while iOAM
> only
> > the latter.
>
> Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance.
>
> >
> > Regards,
> > Greg
> >
> > On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert 
> wrote:
> >>
> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
> >> wrote:
> >> > 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.
> >> Greg,
> >>
> >> I'm missing something here. I looked at the drafts you referenced and
> >> each of them looks like the overhead for OAM is greater that four
> >> bytes. In each there is some overhead equivalent to type/length, for
> >> instance in Geneve four bytes are needed for option class, type, and
> >> length. Unless the the OAM data is zero length, I don't see how this
> >> adds up to only four bytes of overhead.
> >>
> >> Tom
> >>
> >> >
> >> > 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 

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

[Tom Herbert]

On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky  wrote:
> Hi Tom,
> could you please mention which drafts, iOAM or OOAM, you refer to. Please
> note, that OOAM supports both active and hybrid OAM methods, while iOAM only
> the latter.

Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance.

>
> Regards,
> Greg
>
> On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert  wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
>> wrote:
>> > 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.
>> Greg,
>>
>> I'm missing something here. I looked at the drafts you referenced and
>> each of them looks like the overhead for OAM is greater that four
>> bytes. In each there is some overhead equivalent to type/length, for
>> instance in Geneve four bytes are needed for option class, type, and
>> length. Unless the the OAM data is zero length, I don't see how this
>> adds up to only four bytes of overhead.
>>
>> Tom
>>
>> >
>> > 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 

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

[Greg Mirsky]

Hi Tom,
could you please mention which drafts, iOAM or OOAM, you refer to. Please
note, that OOAM supports both active and hybrid OAM methods, while iOAM
only the latter.

Regards,
Greg

On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert  wrote:

> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
> wrote:
> > 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.
> Greg,
>
> I'm missing something here. I looked at the drafts you referenced and
> each of them looks like the overhead for OAM is greater that four
> bytes. In each there is some overhead equivalent to type/length, for
> instance in Geneve four bytes are needed for option class, type, and
> length. Unless the the OAM data is zero length, I don't see how this
> adds up to only four bytes of overhead.
>
> Tom
>
> >
> > 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 

Re: [Int-area] [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-area@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: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

[Greg Mirsky]

Hi Tom,
I think you refer to the proposal on how to apply RFC 8321
 in IPv6 networks. Using two bits-long
field for Alternate Marking is just one option as you can find in the draft
on compact Alt.marking
.
But to answer your question, there's no connection or dependency between
the Alternate Marking method and OOAM. Will note that we have documents on
the applicability of the Alternate Marking method in BIER, SFC NSH, and
Geneve.

Regards,
Greg

On Thu, Apr 12, 2018 at 8:37 PM, Tom Herbert  wrote:

> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky 
> wrote:
> > 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.
> >
>
> What is the relationship between this proposal and
> draft-fioccola-v6ops-ipv6-alt-mark which is currently searching for a
> way to squeeze out two bits in the IP header for performance
> measurement?
>
> Tom
>
> > 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 

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

[Tom Herbert]

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky  wrote:
> 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.
>

What is the relationship between this proposal and
draft-fioccola-v6ops-ipv6-alt-mark which is currently searching for a
way to squeeze out two bits in the IP header for performance
measurement?

Tom

> 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
>>
>
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [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-area@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: [Int-area] [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
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area