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

From: Tal Mizrahi <[email-masked]>
Date: Tue, 13 Oct 2020 09:43:24 +0300

Hi

I have created a pull request that updates the draft according to the
proposal that was discussed in the virtual meeting, and is described below.

https://github.com/inband-oam/ietf/pull/199

A diff between version 02 of the draft and the current proposal can be
found here:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/talmi/ietf/flag-draft-update/drafts/versions/02/draft-ietf-ippm-ioam-flags-02.txt&url2=https://raw.githubusercontent.com/talmi/ietf/flag-draft-update/drafts/versions/03/draft-ietf-ippm-ioam-flags-03.txt

Please let us know if there are any comments.

Thanks,
Tal.

On Wed, Sep 16, 2020 at 9:38 AM Tal Mizrahi <[email-masked]>
wrote:

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

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 21 Oct 2020 11:01:46 +0300

Hi,

If there are no further comments by tomorrow I will post an updated draft.

Cheers,
Tal.

On Tue, Oct 13, 2020 at 9:43 AM Tal Mizrahi <[email-masked]> wrote:
>
> Hi
>
> I have created a pull request that updates the draft according to the proposal that was discussed in the virtual meeting, and is described below.
>
> A diff between version 02 of the draft and the current proposal can be found here:
>
> On Wed, Sep 16, 2020 at 9:38 AM Tal Mizrahi <[email-masked]> wrote:
>>
>> Hi,
>>
>> On Sun, Aug 30, 2020 at 9:03 AM Tal Mizrahi <[email-masked]> wrote:
>> >
>> > Hi,
>> >
>> > - Flag: A dedicated flag (new flag) that indicates that a packet is looped back.