Subject: Re: [Ippm-ioam-ix-dt] IOAM Flag Draft: Loopback on the Reverse Path

From: Tal Mizrahi <[email-masked]>
Date: Wed, 16 Sep 2020 09:38:16 +0300

Hi,

On September 2nd we had another discussion about this open issue in
the IOAM virtual meeting (a link to the summary can be found below).
https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/rKmecuK3zyEZ4jvRj3as6fTSEGA/

Based on this discussion, the following proposal came up and seems to
be the most reasonable.
In a nutshell:
- An IOAM encapsulating node that pushes an IOAM trace option can set
the loopback bit. This encapsulating node is either (a) an endpoint,
or (b) a router/switch that pushes a tunnel encapsulation.
- IOAM nodes along the path push IOAM data, create a copy of the
packet, and loop the copy back to the IOAM encapsulating node. This
includes assigning the source address (referring to the encapsulating
node) as the new destination address.
  A node that loops back the copy of the packet clears the loopback
flag (to zero).
- On the reverse path (which does not necessarily follow the same path
as the forward direction), IOAM nodes push IOAM data onto the trace
option.
- When the packet reaches the original IOAM encapsulating node (whose
address is now the destination address), the node compares the Node ID
in the first data field of the packet to its own Node ID value, and
thus determines whether this is an IOAM looped-back packet that was
created by the current node. In this case the packet is terminated.

This is a summary of the idea. More details will be added if we decide
to proceed with this idea.
Comments will be welcome.

Thanks,
Tal.

On Sun, Aug 30, 2020 at 9:03 AM Tal Mizrahi <[email-masked]> wrote:
>
> Hi,
>
> This is a short summary of the open issue we have about loopback on
> the reverse path.
> The loopback flag indicates to transit IOAM nodes that they need to
> loop back the packet. When an IOAM packet is looped back we want it to
> be forwarded back to the encapsulating node so that (1) no data fields
> will be pushed along the reverse path, and (2) the encapsulating node
> will know that this is a looped back packet and terminate it.
>
> We have discussed five possible options of how to indicate that a
> looped back packet is in transit on the reverse path:
> - Flag: A dedicated flag (new flag) that indicates that a packet is looped back.
> - IOAM type: A dedicated IOAM type that indicates this.
> - RemainingLen: An IOAM transit node that loops back the packet clears
> the RemainingLen field. This will not work for the pre-allocated trace
> option.
> - Exporting format: A packet on the reverse path is sent with an
> exporting format (e.g., using the IOAM raw exporting format).
> - E2E option: A packet that is intended for loopback includes an E2E
> option that includes the ID of the encapsulating node, and an
> indication about whether the packet is on the reverse path.
>
> Thoughts/preferences?
>
> Cheers,
> Tal.