Re: [ippm] Vote at IPPM session

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 15 April 2017 09:16 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4E712426E; Sat, 15 Apr 2017 02:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 PqV24UubfW3a; Sat, 15 Apr 2017 02:16:12 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8711205F0; Sat, 15 Apr 2017 02:16:11 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3F9FenS025278; Sat, 15 Apr 2017 10:15:40 +0100
Received: from 950129200 (251.129.113.87.dyn.plus.net [87.113.129.251]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3F9FZGP025220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Apr 2017 10:15:39 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Frank Brockners (fbrockne)'" <fbrockne@cisco.com>
Cc: 'ALFRED MORTON' <acmorton@att.com>, "'Brian Trammell (IETF)'" <ietf@trammell.ch>, 'IPPM Chairs' <ippm-chairs@ietf.org>, ippm@ietf.org, 'Sarah B' <sbanks@encrypted.net>
References: <CA+RyBmXAyOVZy2DncvC9Bdkmt2P+OXhV49sFgCqXf=1Of3EWkw@mail.gmail.com> <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <CA+RyBmUtVv6fJVLrUxwLiHg9ktvDCkuV0s+KWyv4ygEb50rMOw@mail.gmail.com> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <CAKKJt-ca7VgePkstLE=RLTh506o44m3hiZ_ay88hOS1egz20KA@mail.gmail.com> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <e60a1ae521054eb3b9e1352d5918c6b2@XCH-RCD-008.cisco.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <aa0dea09d3e44260a2ed306836c68ccb@XCH-RCD-008.cisco.com> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net>
In-Reply-To: <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net>
Date: Sat, 15 Apr 2017 10:15:39 +0100
Message-ID: <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABFXUytwGaPkqGAuvO8TYDDF8SAQGwfxGGoCi7hgA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23006.006
X-TM-AS-Result: No--9.607-10.0-31-10
X-imss-scan-details: No--9.607-10.0-31-10
X-TMASE-MatchedRID: VPleTT1nwdSnykMun0J1wgRH1Nr7oERdofZV/2Xa0cJ9aRK7E1xmXtum fLXrQVDADZcIl/YT+Cfw4tCmqBF8q3AELY3VgLbxDB+ErBr0bAOAfODDLypXmv2dkkg+0fIUqdW hIZx2SSJlaA126RCPPCbjUl0Qr/WOrsq/7BhdGyAwmhCbeOj6aVAI6wCVrE3vHiIhsW/ea0TbtI JlNra3Svdy7GMadCXAkZOl7WKIImq0P2qkGU0XygtuKBGekqUpI/NGWt0UYPCi94flAwriz1/Jb 6MCIex9SxNZBp51BkJf5VBpy9gGOJh0MHTFa8de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/UmaXuIupD6ZmwHO7cF9ialaKSEs>
Subject: Re: [ippm] Vote at IPPM session
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Sat, 15 Apr 2017 09:16:14 -0000

Hi Frank, all,

Thanks for proposing some text.

> How about: "The operator of such a domain MUST put provisions in place to
> ensure that in-situ OAM data stays within the specific domain only (i.e., does
not
> leak beyond the edge) using for example packet filtering methods. The operator
> SHOULD consider 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 a native
IPv6
> transport, IOAM support for ICMPv6 Echo Request/Reply could 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)."

Like Sarah, I think this is a start.

I remain disappointed that it is the operators' responsibility to ensure various
things, and not a feature of the protocol or implementation.

But perhaps this text serves as a warning to the operators about using
implementations of iOAM and so will suffice.

I think the use of 2119 capitalisation is meaningless in this paragraph, and
that the "SHOULD" in the second sentence should in any case be a "must".

Thanks,
Adrian