[ippm] Intdir telechat review of draft-ietf-ippm-ioam-data-12
Carlos Bernardos via Datatracker <noreply@ietf.org> Mon, 22 March 2021 09:09 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6EE3A0C3D; Mon, 22 Mar 2021 02:09:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carlos Bernardos via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-ippm-ioam-data.all@ietf.org, ippm@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161640414001.4412.5606895020701581108@ietfa.amsl.com>
Reply-To: Carlos Bernardos <cjbc@it.uc3m.es>
Date: Mon, 22 Mar 2021 02:09:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/gDUuGAHNb7g6bbqX6Vpjq-vz8po>
Subject: [ippm] Intdir telechat review of draft-ietf-ippm-ioam-data-12
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2021 09:09:00 -0000
Reviewer: Carlos Bernardos Review result: Ready with Nits Thanks for this document. I think it is well written and well on track. I include below some comments, mostly from an Internet view point, but not limited to that. - I wonder if some SHOULD/MUST language needs to be used in the following piece, as it talks about important operational considerations: "The operator has to consider the potential operational impact of IOAM to mechanisms such as ECMP processing (e.g. load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e. ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM) and ICMP message handling (i.e. in case of IPv6, IOAM support for ICMPv6 Echo Request/Reply is desired which would translate into ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an Echo Request message to an Echo Reply message)." - I think a clarification of how an IOAM domain relates to an administrative domain (as mentioned in Section 4) is required. It is not clear if they are the same or an IOAM domain is a subset of an admin domain. - Are there any privacy concerns due to the fact of the information that IOAM discloses and can be analyzed by any node in the domain? There is some text in the Security Considerations, but it does not cover in much detail the new risks that it opens due to the additional information disclosure for that belong to the domain. -Nit: in section 3, some abbreviations follow the approach "XXX: ", while others "YYY ". Please harmonize it. Example of what I mean below: E2E Edge to Edge Geneve: Generic Network Virtualization Encapsulation [I-D.ietf-nvo3-geneve] Thanks, Carlos
- [ippm] Intdir telechat review of draft-ietf-ippm-… Carlos Bernardos via Datatracker