[ippm] Roman Danyliw's No Objection on draft-ietf-ippm-ioam-flags-09: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 29 June 2022 17:12 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-ioam-flags@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com, tpauly@apple.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <165652275375.26179.3652733993984279480@ietfa.amsl.com>
Date: Wed, 29 Jun 2022 10:12:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/VwOLxba9rcVlX6c5w_utir7-U1o>
Subject: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-ioam-flags-09: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-ioam-flags-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Donald Eastlake for the SECDIR review.

Section 4.*.  The same thing appears to be said twice, but with different
normative language:

-- Section 4
   Loopback can be used only if a return path from transit nodes and
   destination nodes towards the source (encapsulating node) exists.”

-- Section 4.1.
   The loopback flag MUST NOT be set if it is not guaranteed that there
   is a return path from each of the IOAM transit and IOAM decapsulating
   nodes, or if the encapsulating node's identity is not available in
   the encapsulation header.

** Section 4.4.

   In either case, when the packet reaches the IOAM
   boundary its IOAM encapsulation is removed, preventing IOAM
   information from leaking out from the IOAM domain.

Isn’t it more than removing the IOAM encapsulation?  Wouldn’t the packet just
be dropped at that point since it is a loop back packet with no place to go?

** Section 5.  How does a deencapsulating node distinguish between the two use
cases of “IOAM active measurement using probe packets within the IOAM domain”
and “IOAM active measurement using replicated data packets”? Specifically, how
does the deencapsulating know it is a getting a probe packet vs. a replicated
packet?

[ippm] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker