IOAM transport: draft-weis-ippm-ioam-eth-01: examples for add/remove IOAM when tunnel start/end different from IOAM start/end

[inband-oam]

From: John Lemon [email protected]
Date: Friday, April 19, 2019 at 3:53 AM
To: Brian Weis [email protected]
Cc: "Frank Brockners (fbrockne)" [email protected], Shwetha bhandari [email protected], Tal Mizrahi [email protected], Mickey Spiegel [email protected], Barak Gafni [email protected], Aviv Kfir [email protected], "Ramesh Sivakolundu (sramesh)" [email protected]
Subject: Re: IOAM GRE Encapsulation Question

Hi Brian,

I see that draft-weis-ippm-ioam-eth-01 does not address this issue. I think we need to think about what is legal, and also how we handle each case upon reception.

Speaking of reception, how would you suggest dealing with the following?
• I have some packets coming into the IOAM-adding node with {IP, GRE, IP}. So say I add the IOAM as an additional thing pointed to by GRE as follows: {IP, GRE, IOAM, IP}. When this this gets to the end of the IOAM domain, I want to change this back to {IP, GRE, IP}.
• I also have some other packets coming with {IP, IP}. And say I add IOAM as follows: {IP, GRE, IOAM, IP}. When this gets to the end of the IOAM domain, I want to change this back to {IP, IP}.

At the end of the IOAM domain, how do I know whether to remove the GRE header or not?

Thanks, John

On Sun, Dec 16, 2018 at 8:46 PM Frank Brockners (fbrockne) [email protected] wrote:
Hey Brian,

adding a section with encap examples/use cases to the draft sounds like a great idea to me.

Cheers Frank

Am 17.12.2018 um 05:19 schrieb Brian Weis (bew) [email protected]:
Hi John,

One nit. I apologize, but when sending the earlier email I mistakenly referred to GRE as following an Ethernet header. But to my knowledge there is no standardized EtherType for GRE itself. GRE is IP protocol 47, so should following an IP header. So my packet examples were missing an IP header, and so I assume so were yours.

On Dec 12, 2018, at 3:37 PM, John Lemon [email protected] wrote:

Hi Brian,

Actually, what I was asking about was:

     BEFORE APPLYING IOAM
     ------------------------------------------

IPv4 | ETH | GRE | NOT IOAM | IP | TCP | Data |
------------------------------------------

I had been thinking about adding IOAM to an un-tunneled packet in my original example. I assume here that the “NOT IOAM” is another tunnel header of some kind, since there’s an IP header following it, so you're starting with a tunneled IP packet and you want to add an IOAM header and data.

BEFORE APPLYING IOAM
-----------------------------------------------
IPv4 | ETH | IP | GRE | NOT IOAM | IP | TCP | Data |

The above is what I would actually expect. I didn’t bother to fix the examples below.

     AFTER APPLYING IOAM, POSSIBILITY 1
     -------------------------------------------------

IPv4 | ETH | GRE | NOT IOAM | IOAM | IP | TCP | Data |
-------------------------------------------------

This makes sense to me when the “NOT IOAM” header has a next protocol as an EtherType.

     AFTER APPLYING IOAM, POSSIBILITY 2
     -------------------------------------------------

IPv4 | ETH | GRE | IOAM | NOT IOAM | IP | TCP | Data |
-------------------------------------------------

Yep, again this makes sense to me because the IOAM header can link to the “NOT IOAM” header.

     AFTER APPLYING IOAM, POSSIBILITY 3
     -------------------------------------------------------------

IPv4 | ETH | GRE | IOAM | ETH | GRE | NOT IOAM | IP | TCP | Data |
-------------------------------------------------------------

That’s gnarly, but looks perfectly legal to me. It’s begging for some form of header compression method as an option. :-)

Do people think this is worth describing these use cases in a new Appendix to the IOAM Ethernet I-D, or is it too complicated of a topic?

Thanks,
Brian

P.S. - I’m changing my email from [email protected] to [email protected], and I’ve copied the new one on this email.

Thanks, John

On Tue, Dec 11, 2018 at 9:20 PM Brian Weis (bew) [email protected] wrote:
Hi John,

First of all, I no longer have the need for that confusing language regarding the IOAM Ethertype “Next Protocol” optionally being an IP protocol, so I think it should be removed in the next draft. Lets assume “Next Protocol” is simply an EtherType. I think that’s probably a lot of the confusion.

I had envisioned that an IP over GRE packet would look like this:

     BEFORE APPLYING IOAM
     ------------------------- 

IPv4 | ETH | IP | TCP | Data |
-------------------------

     AFTER APPLYING IOAM
     -------------------------------------------------

IPv4 | ETH | GRE | IOAM HDR + DATA | IP | TCP | Data |
-------------------------------------------------

Does that make sense?

Thanks,
Brian

On Dec 11, 2018, at 3:56 PM, John Lemon [email protected] wrote:

Hi Brian,

When I have an existing IP over GRE packet that I want to add IOAM to, are you envisaging that this is done via extending the existing GRE encapsulation, by encapsulating the IP packet in a new IP over GRE over previous IP tunnel, or something else?

Thanks, John

[mickeyspiegel]

Catching up on IETF threads 2 1/2 weeks later. Please see comments inline. On Thu, Apr 18, 2019 at 11:29 PM inband-oam <[email protected]> wrote:

From: John Lemon ***@***.*** Date: Friday, April 19, 2019 at 3:53 AM To: Brian Weis ***@***.*** Cc: "Frank Brockners (fbrockne)" ***@***.***, Shwetha bhandari ***@***.***, Tal Mizrahi ***@***.***, Mickey Spiegel ***@***.***, Barak Gafni ***@***.***, Aviv Kfir ***@***.***, "Ramesh Sivakolundu (sramesh)" ***@***.*** Subject: Re: IOAM GRE Encapsulation Question Hi Brian, I see that draft-weis-ippm-ioam-eth-01 does not address this issue. I think we need to think about what is legal, and also how we handle each case upon reception. Speaking of reception, how would you suggest dealing with the following? • I have some packets coming into the IOAM-adding node with {IP, GRE, IP}. So say I add the IOAM as an additional thing pointed to by GRE as follows: {IP, GRE, IOAM, IP}. When this this gets to the end of the IOAM domain, I want to change this back to {IP, GRE, IP}. • I also have some other packets coming with {IP, IP}. And say I add IOAM as follows: {IP, GRE, IOAM, IP}. When this gets to the end of the IOAM domain, I want to change this back to {IP, IP}. At the end of the IOAM domain, how do I know whether to remove the GRE header or not?

For VXLAN-GPE, I was going to propose adding a bit to the shim header that could be used to distinguish this kind of thing. In that case, the confusion is between a VXLAN header and a VXLAN-GPE header, with the issue arising if there are any native VXLAN-GPE endpoints in the network (so VXLAN-GPE is not just used for IOAM). * G: Indicates whether the original packet (before insertion of IOAM headers and metadata) used a VXLAN or VXLAN GPE encapsulation. - 0: Original packet used VXLAN encapsulation. - 1: Original packet used VXLAN GPE encapsulation. - This may be used as a hint that helps the IOAM decapsulating node (when it is not the VTEP) determine whether to progress the packet using a VXLAN GPE encapsulation, or whether to convert the VXLAN GPE encapsulation back to a VXLAN (without GPE) encapsulation. The same approach could be taken for GRE. However, I have two concerns: 1. While the IOAM shim header for VXLAN-GPE has a reserved byte, the IOAM shim header for ethernet encapsulations does not. 2. I thought the feedback from the operator session at the last IETF was quite negative with regard to the use of GRE as an IOAM encapsulation option for native IPv4 packets. I am confused by a lot of the discussion below. Shouldn't the original packet be either a native IPv4 packet: ETH | IP | TCP | Data | or a GRE tunneled packet: ETH | IP | GRE | IP | TCP | Data | Then the packet with IOAM would be: ETH | IP | GRE | IOAM HDR + DATA | IP | TCP | Data | The additional bit is all you need for the decapsulating node to determine whether to remove just "IOAM HDR + DATA", or all of outer "ETH | IP | GRE | IOAM HDR + DATA", then slapping on a new outer ETH header. A lot of this comes down to how acceptable it is for a node that does not own the outer IP destination address to peek under the hood and start removing headers. Some purists will scream. Mickey Thanks, John

…

On Sun, Dec 16, 2018 at 8:46 PM Frank Brockners (fbrockne) ***@***.*** wrote: Hey Brian, adding a section with encap examples/use cases to the draft sounds like a great idea to me. Cheers Frank Am 17.12.2018 um 05:19 schrieb Brian Weis (bew) ***@***.***: Hi John, One nit. I apologize, but when sending the earlier email I mistakenly referred to GRE as following an Ethernet header. But to my knowledge there is no standardized EtherType for GRE itself. GRE is IP protocol 47, so should following an IP header. So my packet examples were missing an IP header, and so I assume so were yours. On Dec 12, 2018, at 3:37 PM, John Lemon ***@***.*** wrote: Hi Brian, Actually, what I was asking about was: BEFORE APPLYING IOAM ------------------------------------------ IPv4 | ETH | GRE | NOT IOAM | IP | TCP | Data | ------------------------------------------ I had been thinking about adding IOAM to an un-tunneled packet in my original example. I assume here that the “NOT IOAM” is another tunnel header of some kind, since there’s an IP header following it, so you're starting with a tunneled IP packet and you want to add an IOAM header and data. BEFORE APPLYING IOAM ----------------------------------------------- IPv4 | ETH | IP | GRE | NOT IOAM | IP | TCP | Data | The above is what I would actually expect. I didn’t bother to fix the examples below. AFTER APPLYING IOAM, POSSIBILITY 1 ------------------------------------------------- IPv4 | ETH | GRE | NOT IOAM | IOAM | IP | TCP | Data | ------------------------------------------------- This makes sense to me when the “NOT IOAM” header has a next protocol as an EtherType. AFTER APPLYING IOAM, POSSIBILITY 2 ------------------------------------------------- IPv4 | ETH | GRE | IOAM | NOT IOAM | IP | TCP | Data | ------------------------------------------------- Yep, again this makes sense to me because the IOAM header can link to the “NOT IOAM” header. AFTER APPLYING IOAM, POSSIBILITY 3 ------------------------------------------------------------- IPv4 | ETH | GRE | IOAM | ETH | GRE | NOT IOAM | IP | TCP | Data | ------------------------------------------------------------- That’s gnarly, but looks perfectly legal to me. It’s begging for some form of header compression method as an option. :-) Do people think this is worth describing these use cases in a new Appendix to the IOAM Ethernet I-D, or is it too complicated of a topic? Thanks, Brian P.S. - I’m changing my email from ***@***.*** to ***@***.***, and I’ve copied the new one on this email. Thanks, John On Tue, Dec 11, 2018 at 9:20 PM Brian Weis (bew) ***@***.*** wrote: Hi John, First of all, I no longer have the need for that confusing language regarding the IOAM Ethertype “Next Protocol” optionally being an IP protocol, so I think it should be removed in the next draft. Lets assume “Next Protocol” is simply an EtherType. I think that’s probably a lot of the confusion. I had envisioned that an IP over GRE packet would look like this: BEFORE APPLYING IOAM ------------------------- IPv4 | ETH | IP | TCP | Data | ------------------------- AFTER APPLYING IOAM ------------------------------------------------- IPv4 | ETH | GRE | IOAM HDR + DATA | IP | TCP | Data | ------------------------------------------------- Does that make sense? Thanks, Brian On Dec 11, 2018, at 3:56 PM, John Lemon ***@***.*** wrote: Hi Brian, When I have an existing IP over GRE packet that I want to add IOAM to, are you envisaging that this is done via extending the existing GRE encapsulation, by encapsulating the IP packet in a new IP over GRE over previous IP tunnel, or something else? Thanks, John — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHAHKUUEXDOKSOJM3D6CK2TPRFRDFANCNFSM4HHCHXJQ> .