[ippm] Flag draft: updated version

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Mon, 27 January 2020 08:05 UTC

MIME-Version: 1.0
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Mon, 27 Jan 2020 10:05:33 +0200
Message-ID: <CABUE3Xn85Mia_eu7HU5Oqk+KKVreKVnM6i9YjdrNMQr8V04aPg@mail.gmail.com>
To: IETF IPPM WG <ippm@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f7e548059d1a9223"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/HM5sfQL-SBKeBjNKbgnBCOg_Fcs>
Subject: [ippm] Flag draft: updated version
Precedence: list

Hi,

A new version has been posted:
https://tools.ietf.org/html/draft-ietf-ippm-ioam-flags-01

Several issues about the flag draft have been discussed in IETF 106 and in
the IOAM virtual meetings since IETF 106. While not all issues have been
concluded yet, we are releasing this version to allow for some discussion
before IETF 107.

Please let us know if there are any comments.

Main changes since the previous version:
- The Security Considerations section has been updated with further
discussion regarding mitigating amplification attacks, in two main aspects:
rate limiting, and data minimization (a single data field).
- Various clarifications about the loopback flag have been added.
- Text has been added to clarify the purpose of the active flag.

Main open issue:
- Loopback: it was noted that incorporating IOAM data is not necessary on
the reverse path when a packet is looped back. The problem is how to
indicate to transit nodes that they should not push IOAM data into a looped
back packet on the reverse path. There are a few possible solutions: (1) By
defining a new flag that indicates this is a loopback on the reverse path.
(2) By defining a new IOAM type that indicates this is a loopback on the
reverse path. (3) By clearing the RemainingLen field, thus preventing nodes
from pushing more data fields.

Cheers,
Tal.

[ippm] Flag draft: updated version Tal Mizrahi