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

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Wed, 16 September 2020 06:38 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: ippm-ioam-ix-dt@ietfa.amsl.com
Delivered-To: ippm-ioam-ix-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F313A0D5E for <ippm-ioam-ix-dt@ietfa.amsl.com>; Tue, 15 Sep 2020 23:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbAs1dFOjT7m for <ippm-ioam-ix-dt@ietfa.amsl.com>; Tue, 15 Sep 2020 23:38:30 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0333A0D58 for <ippm-ioam-ix-dt@ietf.org>; Tue, 15 Sep 2020 23:38:29 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id s13so1597776wmh.4 for <ippm-ioam-ix-dt@ietf.org>; Tue, 15 Sep 2020 23:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=V/CooEU4E7UMxti1Ayseu2a7JhcmqaRWDADWMhN4HNQ=; b=EzZtwV2gb2IwPEQHb2gYEU/gJp0/rt0TVLLXWWV/Wj32dGo0f9VL2exwMp+zjpYdUp b/NhThXz184T4r0xbhLqCU9rWeUcmbMycM8salpYJBPSGPpt0bqO7IB90FfNXNZ3KxGJ CikGyWmN5P4aGD4sZLLvmy2qX1a7iU/pm3elsU9V1iOK73usuHf8DBsNPNc9H022FUJA kD/Yw5lTKqKcaby0BpfZXjhnuqtWgOWVJuAmyRgt0Ab7sm+SVDqic7PNNDWHVIDuyDzL RWwkgvq0/15Bqt/t/UBAE9KpLarG+5p3whfflzkbbq6ExQ9DFmC0QrQvC52+E64nl1kf ulOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=V/CooEU4E7UMxti1Ayseu2a7JhcmqaRWDADWMhN4HNQ=; b=kVQ5NVG44wv/R37HgsV4bhBveD6lbmLrrFOnxagura3pB1gaDtMIlxV+1SR7gyHvw9 sRa62eAV1ohxKtxKr2uKZ3s9lWVG/4JFYE95TO8WZUuIBd3wylsjnv8UjE0b96FyjiFV qAkfQp8fCZP6s9iHbz1mqBl2zafhZiWWiey97fNMEc52EQ1KgVcpTdXwg2iJ+YNNz92+ qm3J1HqMCwgq63G2Pufxo8rEMFZgXPCF9a+OoGdiOLmEb8QUTodjYaqKGctEDq13njCX 2mrm4OvcytzeY8stm+M1frJziss1zTj6mSPR/Zk/I9qFiJx+1e0RBsLWHTSwWvcyrx9u ZEaA==
X-Gm-Message-State: AOAM531tnWhZHZ2w8smYLYwz34rDucdfprreelqn8DLa9KW5zw0oyoV1 rQ9s8Xi6M+t+7y8av1/Imugc//zOmunlh8lCe3ykBs76swd6fA==
X-Google-Smtp-Source: ABdhPJxd8AczXbw4Www1kDWIghcRlFjdv5YRguGqHwYsnEqWv2PMhR2yEKqIpaxIODt2p0gr9uNfO8sQ86yt8PjQ3I4=
X-Received: by 2002:a1c:e4c5:: with SMTP id b188mr2146508wmh.67.1600238308000; Tue, 15 Sep 2020 23:38:28 -0700 (PDT)
MIME-Version: 1.0
References: <CABUE3XmeQ5B=kPsgUT7+GqWb2Skt=b2N-BbstDSL8Oe1b9tzaQ@mail.gmail.com>
In-Reply-To: <CABUE3XmeQ5B=kPsgUT7+GqWb2Skt=b2N-BbstDSL8Oe1b9tzaQ@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 16 Sep 2020 09:38:16 +0300
Message-ID: <CABUE3X=-krbH05zDYF-juCiejTbuVZQe2gOZFQCjJ4JjhnHj6Q@mail.gmail.com>
To: ippm-ioam-ix-dt@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/_e2Lbb13beZENUsCMDZqme_rTmU>
Subject: Re: [Ippm-ioam-ix-dt] IOAM Flag Draft: Loopback on the Reverse Path
X-BeenThere: ippm-ioam-ix-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPPM iOAM Immediate Export \(IX\) design team" <ippm-ioam-ix-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm-ioam-ix-dt>, <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm-ioam-ix-dt/>
List-Post: <mailto:ippm-ioam-ix-dt@ietf.org>
List-Help: <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm-ioam-ix-dt>, <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 06:38:31 -0000

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 <tal.mizrahi.phd@gmail.com> 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.