Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Sun, 11 April 2021 16:46 UTC

Return-Path: <fbrockne@cisco.com>
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 7DCBA3A146A; Sun, 11 Apr 2021 09:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.918
X-Spam-Level:
X-Spam-Status: No, score=-11.918 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZMjL3FVU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e7GaUEqk
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 mYDlUoo-ooye; Sun, 11 Apr 2021 09:46:10 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2AC3A1464; Sun, 11 Apr 2021 09:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22966; q=dns/txt; s=iport; t=1618159570; x=1619369170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=972DcsZJpEFQfGH4nrrHcnyBR80/XoYp4Nnbe2yrdSQ=; b=ZMjL3FVUV2Q6ktdA3wgjZsJRAeAHRnLc+UcNhVW1CYwgUh+JNZQuIAeu hh1Ze3Tn1oHbYRuL8fSAReQqWB1uIS+cT4QgSBMsXyWEw8eTC2J1K44XD ad+ozMmXgDVN9rvtEjoVkqOw9jURDfQOuZVL9LAmC3wAMYK8UfPiZ6Czr c=;
X-IPAS-Result: =?us-ascii?q?A0BhAQC5JnNg/4YNJK1QChwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFBBAEBCwGBUikoB3daNjEKhDiDSAOFOYhTA48nihSBQoERA1QLAQEBDQEBK?= =?us-ascii?q?AoCBAEBgVuCdQIXgWACJTcGDgIDAQEBAwIDAQEBAQEFAQEBAgEGBHEThVANh?= =?us-ascii?q?kQBAQEBAgEjEQwBATcBCwQCAQgRBAEBAwImAgICMBUICAIEAQ0FCBeCB0yCV?= =?us-ascii?q?QMOIQEOoGoCih93gTKBAYIEAQEGgUdBgwAYghMDBoEPKgGCdYQJglqCZIEQJ?= =?us-ascii?q?xyBSUKBE0OCXz6CYAIBAoEoAQcLAQccgxU1giuBWDsELQY+JgQNFQ0MCA4CA?= =?us-ascii?q?gJ3BAYTPAIDBQsBEgEEAQECDVMSkCwiA4M1i3iILZIdCoMLiWOGSYcchVeDT?= =?us-ascii?q?Yp4iTeMdR2UeIIQiVqSWgSEYQICAgIEBQIOAQEGgWokaVgRB3AVO4JpUBcCD?= =?us-ascii?q?o4fCQMWFYM5hRSFRXMCNgIGAQkBAQMJfIsGAYEOAQE?=
IronPort-PHdr: A9a23:IpMUAx8/dDnq4P9uWNfoyV9lXQAupqn0MwgJ65Eul7NJdOG58o//O FDEjd1gg1DER5md7OhL2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2E d4EWApj+He2YkVaF8vkexvVuHLhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oK xDjpgTKvc5Qioxnec4M
IronPort-HdrOrdr: A9a23:lHSGCqDJVV6yv83lHejdtceALOonbusQ8zAX/mhLY1h8btGYm8 eynP4SyB/zj3IrVGs9nM2bUZPgfVr1zrQwxYUKJ7+tUE3duGWuJJx/9oeK+VPdMgXE3Kpm2a 9kGpIQNPTZB1J3lNu/xQG+HcopztXvytHWuc715R5WPGZXQotn6Bp0DRveN0VwShVPC5ZRLu vj2uNsoT28dXMLKvmhDn4eUOTZ4/HNnpTqYRkJbiRXqTWmpzWu9bL8Dlykzg4TOgk/j4sK3E rkt0jC5qulu+ym0RO07Q/uxrlfhdeJ8Ko5OOWikc4QQw+c7zqARIMkYLGauSBwnefH0idXrP DpgzMNe/t+8GnQeGbdm2qs5yDF3Cw143HvjX+06EGT2/DRfz4xB8pfiY8xSHKwgCBM0KAeoc B29lmUuJZNARTLkD6V3am0azhRikG2rXA++NRj6UB3bIoEZLdd6awZ8U9Fea1wZB7S1YE9HO FiSPzb/fZdGGnqFkzxg28H+q3JYl0DWjO9BmQSsM2c1DZb2FpjyVED+cAZlnAcsLogVpht/Y 3/Q+dVvYALavVTQbN2Be8HT8fyIHfKWwjwPGWbJkmiPL0bOkjKt4X87NwOlaOXUa1N6KF3tI XKUVteu2J3UVnpE9ey0JpC9Q2IZ2mhQzL3yIV764JisrPxAJrnWBfzDWwGoo+FmbEyE8fbU/ G8NNZ9GPn4N1bjHo5PwknwQJ9XJX4CUNAEu9oyVl6Uy/i7bbHCh6j+SrL+NbDtGTErVifUGX 0YRgX+I81G8wSqVxbD8V7sckKoXna60YN7EaDc8eRW4pMKLJdwvg8cjkn84smKLDZFo7EnZU cWGsK/roqL4U2NuUrY5WRgPRRQSmxP5q/7bn9MrQgWd0XucbgCvN2bcXtI3GSOIwJ+S8++Kn 8am31HvYaMa7CAzyErDNyqdkiAiWEImX6MR5AA3rGY6dz9YZM+BJY+UKl3HQHGfiYFwTpCmS NmUkspV0XfHjThheGZl5QSHvjYbMQ5qhysO9RopXXWsli8qckjSmAAZSOnVdeajG8VNmFpr2 w015VaobKb3R6zNGM0gY0DQSxxQVXSJIgDMSOoS8F/nKvxdAR5UGGQ7Abq+y0bSy7N7EUdhm voMCuOX+rEa2At4Exw4+LN7E5+cHmbcgZWbH132LcNSVjuizJUzfKBYLa13i+qTmY6hssZMD 3DfFIpU15T7tiqyR+YnyuDH306xpMoevfQFqgnbqu74ALfFKSY0a4BBPNa55BjKZTntfIKS/ uWf0uPICr/EP5B4X3Zml81fC11omIji/XmxVns63W5xmc2BZPpUR9bbqBeJ9GX9G7/QfmUlJ 1/kNIupOO1dmH8cMSPx62SbzlNLHro0CSLZvBtrZBfpqQpsrRvW5HdTDvTzXlCmAwkM92crj JpfI1rpLTafoN/dc0bfCxUulIvidSUNUMu9gj7GPU3c10hh2LSVun5r4bguP4qGAmMtQHwMV 6Q/2lG8/DJUzCK2LQaB6gzSF4mIHQU+TBn5qePZofQAAKle6Vf51K8KGa6a6IYR66fG7kcxy wKrO2gjquSbW7/1w/Rtzcgff4L/GajXM+oAAWDXeRP6Me3PFyQgq2spM6/5Q2HPQeTegAdn8 lCc0dVc8FIzj8lh4cz2jKpSqP2rlk++mEuqA1PhxrowMy+/GzfHUtaKgXXjZVdQClLPhGz/L H42Pnd0G64/SNM1pbCHlpBZ91CG9AfSY7sMidlQPJgy4KA7u4omSRMYBAnEm46hnT8xopdrM WE5Mk=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,214,1613433600"; d="scan'208";a="679183818"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Apr 2021 16:46:09 +0000
Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 13BGk93h028573 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sun, 11 Apr 2021 16:46:09 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Sun, 11 Apr 2021 11:46:08 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Sun, 11 Apr 2021 11:46:08 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 11 Apr 2021 12:46:08 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ba4avQqNHF/tFcmiuMoon4j+KBubbA9uLHdstzt6NX+lm6aoucXyjJafw3SjHOHEYNBKZ8ooKvYc2Pci8AXW3d1rmmoyShPpf/MEi66SkZYiynpxHiF1FRDa3mL1v5kzueum0IF05ND5qUvLQENcfg3vlfWkJtXdhJAftWkVOo5UIoH2Ryo3stZgjS3s0bJ8r/dBQAypybbD2L1wrpJNSm7G9gIEkhsLdrh+3jCc0ec6Q2Y+rms9At5JibpvVR70sSSvckg0UH5+JI5TLnQOAPEw2Iwr1OdIsJGs6xGp8iBOQnHLuuMZ3NdYoYT5Hmtk+iuM3ynEv6IjgnwU6kWmMg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=972DcsZJpEFQfGH4nrrHcnyBR80/XoYp4Nnbe2yrdSQ=; b=Tf2OndlzO+Rrme+lYW5Pr4eaxps+NEIvXpB/LoI4TeEtudSGkrqNJtvl+ArL01hcW9rziLL9AvraNH6raMWQKWCUgt1LeRHK/Yz/UT6Ka0uEpc19uBkPwztzk853AfsWSeV7baYMhsRd7XNzsRhDh0ob0vU1q2+INfzvhuxK6p+SgkQssImmyD9CfppfILNfRVZ3vTI54ch3YViGK14ZQzwJdjMnerDjPUuOPpDj9r4xbUyDq9lzZ/Un2TbDnxLR/JQiimSS6nFfrZJVwbpDBmO3mmSv6Ar+0ZhN72jvOlho256ZGb7if6vLkAbry+D+DFVlaJ/Gex3Kbb/knz4aZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=972DcsZJpEFQfGH4nrrHcnyBR80/XoYp4Nnbe2yrdSQ=; b=e7GaUEqkinG9glnlZ7Smsjh8LPWaEbC7GC8Ti2lmnfLrj3sWmx+wIt0L0BV56dG6yUGM8eePZCon4y1iLCOihb41QevrIg6IrbAKWaBkzlGPp2G9GgmM5LNRDMC9IpHgqVLYh6wcc9Wkkt7RFWjYbbxe90sgPE6F3+SVomorjDs=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (2603:10b6:a02:c8::31) by BYAPR11MB3383.namprd11.prod.outlook.com (2603:10b6:a03:1b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27; Sun, 11 Apr 2021 16:46:06 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f43e:a30f:8e8f:1e93]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f43e:a30f:8e8f:1e93%6]) with mapi id 15.20.3999.033; Sun, 11 Apr 2021 16:46:06 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, Al Morton <acm@research.att.com>
Thread-Topic: Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
Thread-Index: AQHXIXKPxK7/c1+mik++OpFqpHZ06qqvlvyQ
Date: Sun, 11 Apr 2021 16:46:06 +0000
Message-ID: <BYAPR11MB258481FC2FB8EC909D59969EDA719@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <161667538893.15241.7322339760692550091@ietfa.amsl.com>
In-Reply-To: <161667538893.15241.7322339760692550091@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: eggert.org; dkim=none (message not signed) header.d=none;eggert.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5c30165c-3ee5-467c-2ada-08d8fd094d12
x-ms-traffictypediagnostic: BYAPR11MB3383:
x-microsoft-antispam-prvs: <BYAPR11MB33839389EEA3353BDD821395DA719@BYAPR11MB3383.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lv3aPopP+00HGQ13GFEz0Xwb6cPEEp+i3uUzNxgLwXPbY7682wlSqNm1d/LZ/jqrBkApcTNqIl1GBasRN8RgYYJ6wMzX8vEdDrwRC/qlmV0ipXo35dPs45FGWYwyH77Jz4sBBcf+g7LQUjBQULiyM7qUd4e1D9LpkU9BYmMFHoZ3+QYKnTDz5CxZzO5ZNbagkp+D2Fb3hIt9wJFoHsUGQnaFUYx++Utf05GVDLLz/hmi7kjYlFSa9PGCFzuWjcLIhBAwKW3wKP9cEqyc9H1/rIywdNPJPoMBmx4alUBBHHf82poOhAN1V4mpnKcMpTWzZMD+Y8WFKDn+4SUU3+IEq5d3G8NXnJ2wIV7/bItpA2mJXKnBwbioCurbWp5m3TszsJsH1Ge+/FRBt1fffmT8kq7J4rwQ+UlTGuvDX18+trckTv1T2W8QcB57aq6BWVllNtbPVsTQJp4U07AaiuR1Dzn7c0UqurdWPn4tMpOyg6xJYXed4wQLOE9M9LkkNn9+cK28SNtJp/qUHK7a24L8QRIoXhdXmjf97zF5jwt9UEEdC+DzcIt4ogQyrelD8NHt63ycLzvQwy8Nd1womqKoDxJyvj1yNEGesyM/rCy3MzF2KQev16tS80fdnKjyX/hxEmdfG8LCbAg1rh0ZKSK1ELxqmfnfuUCE4I1lZBlg+FONc6smzrV+8aM5lHXnAb2T
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2584.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(136003)(396003)(39860400002)(66446008)(66476007)(66556008)(64756008)(316002)(966005)(55016002)(2906002)(66946007)(26005)(30864003)(8676002)(66574015)(186003)(38100700002)(478600001)(8936002)(6506007)(4326008)(7696005)(33656002)(52536014)(71200400001)(76116006)(86362001)(9686003)(83380400001)(5660300002)(53546011)(54906003)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?dk1QV1N4ZGdyUkU4VUZuZ2ZkM2s4NUdpcW5PRGtXTGxQcmY2eWFsWVAzM0VR?= =?utf-8?B?ekpMRVYvcHFWcitJQitzTFJMMEorbWU1bzB4blhVZWE2SFVRajU0V0hUdWxI?= =?utf-8?B?cTJldGI0QWhtMy9xa05pUjR3UjRMNXdnMnFiTEZMbjcyOU9Dd29SOFZ3THR1?= =?utf-8?B?L3RDV1pxc01NZ1M5amEvUDZhZjBUbGgxU3ZQQkVOS1RDVCs0OFZMT2F5RWJR?= =?utf-8?B?aXdCQ3crZ2RzKys4ci8vNGV0Q3FwNmgreGVKS0NsT3dBSkpBL2NMbEw3RHlV?= =?utf-8?B?UjJodHBNWTBlcHBKajdNTU0xR0FXYmMvaVJWZ1oyZW5aQzE4TzQ0Yy8xUzZE?= =?utf-8?B?b1MySDhnb3VWeHBmckZvSVhaYjFMckIvNWVZOGxxZHY0M2Z5bm9sS01Lc1Bp?= =?utf-8?B?TGdyZUZ1YmFZVTlvUDNkZnlHZ2lEa1NZb01LRERGcFRDWnkzQkVMYUxXNFJl?= =?utf-8?B?YWFTUTVWR01QL1dmaEV0YkloTC9MZFF4NGZFZzIrUjZhNXRrMlZVeTJ3c1pN?= =?utf-8?B?OWhVRGtWNUdnTWJmcEphUHI5bi9vUkkzSzRlYjlGNzRRRGhSN1Y2bHN4QU12?= =?utf-8?B?VzAwL1Z0SnVYZ04yd2hVN0MrdDhWUXo3VnlLeXRYc2lMemlPREFXSWRJWjI0?= =?utf-8?B?UW96MXhVaEFQWG91R1Vmcm9qRHQ1am5hajhDKzNDRGFwVDM2Qkt0TUJ0aGNX?= =?utf-8?B?cHJraVZCRS9yV1Z5UWNrVGowMElETlB5YWxTNFE1U3drNllRZHovd3hnMVV0?= =?utf-8?B?NUFCZGNIODlHcjdFeUkvMVB6VkFPOHRHT0twSnFXcXU0cGZuN0xsb1lVL3Ey?= =?utf-8?B?Z1d0NGVoL3ZzNEQvOWdYZGFwU3dBNUdSenBoMDlSNE5MckVCVFdBZzNBbzcx?= =?utf-8?B?WGtaay93c3N2UzFKeHRhaStTQ045NEdEcHl3NE9FTUI1VitPVkdVQUtaNHdz?= =?utf-8?B?TTFSVUo4OVYyRzluOXlVTjBMY3hZb2lIdmZuN3EwV3ZUN0hKd3F0YjdzOVZF?= =?utf-8?B?NFhseFNlZm5uWWxWWEZ2RnZSeXNiN29kZGd5eEIwUmZNMFQwVVRldkk2Ukg5?= =?utf-8?B?VEJSeVN3dG5XSStoVUhoNUFMOHJlMzBTb0ZKaWdpWHJ0Q2J4Nitic1V5WGs5?= =?utf-8?B?MU04eWNTZGNJQjhFbi9XL1NESkI3SzJadWp2V3BXZTFoNm1ieDR3blpRa0t4?= =?utf-8?B?ZkFLbEVpVXNnS252Y0E5V0tlM3NFNzdWNHQ3VW5ER1BpWXdKUUQ3dDc0NHRs?= =?utf-8?B?clRwb1ZTV0pLSVBTa211cGNxZU9KT1RxSDd6eWlSS3U2ZHRyZVY0dnNUWVFH?= =?utf-8?B?azdWZlRGSmR3eDRzZldobDIyVmZkeEtSR25ZMUZneUJTbmN0WFd6S0RIUHBJ?= =?utf-8?B?TWU5b2hzQlF5QTRoc0l2M1RTbHdQYlRyMXhDYUM2Y24zMTNZTExUcnpJT1ZP?= =?utf-8?B?TVJ1U3dGMHF1NUN3dGJOUm9aU3QxZStZK3ZoMHBTZ3c2blNLZ0o3Zmx4elE1?= =?utf-8?B?aWtxNmkxem1RTjlCS1ZZbHc1UWdBUzV0bWYvM0hxRGo2anl5RTkwVHFIYTlR?= =?utf-8?B?RVdnMU44RzNMajJ4MDhTVldxdGkrSTFuemtkMXJwa0FLQzJoeEVKeTcybms1?= =?utf-8?B?SDlLWitJS1hEZW5wT281QStIYmVmVng5RzVqclRmSnhQaXAvZTlMd0VDNFBG?= =?utf-8?B?M0swQWovVFRGa0k0ZjZRclBJSHVaTmNOeWdrV0c2OWR3TlZmU2hiY0lsdC9S?= =?utf-8?Q?08GRe44BjRdg685/48uE4nqVQdCf9Qh+J+r5yTR?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2584.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c30165c-3ee5-467c-2ada-08d8fd094d12
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2021 16:46:06.0725 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HFFS9xvdmhBhpCJmNHvePmiqSL2vdxVDE2hx51LrdY9Sx3igJ92tG5E2xEa65fZiTEA9U2iT+Amste+IIYZ8+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3383
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/T4zyQC8wjCT0BfK3xZiTIjjAtD4>
Subject: Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 11 Apr 2021 16:46:16 -0000

Hi Lars,

Thanks a lot for your detailed review - and sorry for the delay (PTO & Easter holidays..). Please see inline.

> -----Original Message-----
> From: Lars Eggert via Datatracker <noreply@ietf.org>
> Sent: Donnerstag, 25. März 2021 13:30
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-ippm-ioam-data@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> Al Morton <acm@research.att.com>om>; acm@research.att.com
> Subject: Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS
> and COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-ippm-ioam-data-12: Discuss
> 
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 5.4, paragraph 6, discuss:
> >    A particular implementation of IOAM MAY choose to support only one of
> >    the two trace option types.  In the event that both options are
> 
> Not requiring at least one mandatory-to-implement trace option type is highly
> problematic, since it creates two incompatible flavors of this standard.
> Preventing bifurcation seems to trump the desire for allowing (minor?)
> optimizations.

...FB: There seems to be some confusion and potential misunderstanding here: The two different Trace Option-Types would not lead to two incompatible flavors of the standard:
Each Trace Option-Type fills in the exact same IOAM data-fields - i.e. " node data list [i]" looks the exact same whether pre-allocated or incremental trace option types are used.
Each Trace Option-Type just handles a different “bucket” in the packet. 
And each Trace Option-Type caters for a different type of transit node: Software-based forwarders and Hardware-based forwarders. The differences between the two are not negligible. Memcopy is expensive for a software forwarder, as is a pointer-lookup in the packet for a hardware forwarder. The fact that there are two Option-Types that cater for different types of transit nodes is the result of long discussions. The two different ways to carry the data-fields is to ensure that IOAM can be deployed on a wide variety of devices. I'm afraid, that if we'd drop one variant, or make one variant mandatory, all we'd get is a slowed down adoption of the standard, because we would restrict IOAM tracing to either software forwarders or hardware forwarders.

That said, one thing that we should underline in the document is the fact that encap and decap nodes SHOULD be capable of inserting and removing both Trace-Option types. That way, there won’t be any compatibility challenge at all. Transit nodes of different type (HW or SW) would write the information into "their" type of bucket. Extracting the information at the decap node would be common in any case.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1, paragraph 4, comment:
> >    IOAM use cases and mechanisms have expanded as this document matured,
> >    resulting in additional flags and options that could trigger creation
> >    of additional packets dedicated to OAM.  The term IOAM continues to
> >    be used for such mechanisms, in addition to the "in-situ" mechanisms
> >    that motivated this terminology.
> 
> Suggest to rephrase this expanded view on IAM in a way that does not tie the
> description to the time period during which this soon-to-be-archival document
> was edited.

...FB: Thanks. Good suggestion - which we'll reflect in the next revision.

> 
> Section 5.2, paragraph 6, comment:
> >    A transit node MUST ignore IOAM-Option-Types that it does not
> >    understand.  A transit node MUST NOT add new IOAM-Option-Types to a
> >    packet, MUST NOT remove IOAM-Option-Types from a packet, and MUST
> NOT
> >    change the IOAM-Data-Fields of an IOAM Edge-to-Edge Option-Type.
> 
> I'm surprised that IOAM data isn't authenticated or even integrity-protected at
> all. Relying on RFC2119 language alone seems a pretty weak protection.

...FB: Integrity protection of IOAM data fields is handled in a sister document: draft-brockners-ippm-ioam-data-integrity.

> 
> Section 5.3, paragraph 9, comment:
> >    Namespace identifiers allow devices which are IOAM capable to
> >    determine:
> >
> >    o  whether IOAM-Option-Type(s) need to be processed by a device: If
> >       the Namespace-ID contained in a packet does not match any
> >       Namespace-ID the node is configured to operate on, then the node
> >       MUST NOT change the contents of the IOAM-Data-Fields.
> >
> >    o  which IOAM-Option-Type needs to be processed/updated in case there
> >       are multiple IOAM-Option-Types present in the packet.  Multiple
> >       IOAM-Option-Types can be present in a packet in case of
> >       overlapping IOAM-Domains or in case of a layered IOAM deployment.
> >
> >    o  whether IOAM-Option-Type(s) has to be removed from the packet,
> >       e.g. at a domain edge or domain boundary.
> 
> I'll note that cryptographically authenticating IOM data would probably result in
> a system that wouldn't need the concept of namespaces, because keys would
> automatically serve that purpose. (A device can't update an IOAM data item if it
> doesn't have the key to authenticate the update with.)

...FB: Looking at the way you interpreted the meaning of namespaces, we'll probably need to add some additional explanation of  the role of namespaces. The role of namespaces is to provide additional context to IOAM data fields - something that would be quite difficult to tie to a key which is likely going to be per node and potentially even per packet, depending on what scheme we'd use. The draft is pretty explicit about namespaces: “IOAM-Namespaces add further context to IOAM-Option-Types and associated IOAM-Data-Fields.", i.e. they are not intended as e.g. a tenant-identifier or similar. Looks like we need to think of some even more explicit wording here – maybe using some examples that explain the use of namespaces. I’m thinking of something simple such as “For Namespace 1, a “buffer” might be defined in units of “bytes” whereas for Namespace 2, a “buffer” might be defined in units of “packets”. This would likely also help with other questions, such as “why doesn’t the spec define an explicit unit for e.g. “buffers”.

> 
> Section 5.4, paragraph 11, comment:
> >    o  Time of day when the packet was processed by the node as well as
> >       the transit delay.  Different definitions of processing time are
> >       feasible and expected, though it is important that all devices of
> >       an in-situ OAM domain follow the same definition.
> 
> I think "important" is an understatement, this seems required? Also, capturing
> time-of-day seems to require synchronized clocks.

...FB: As usual, the answer is "in depends". If one is just interested in capturing jitter, then one might also do with non-synchronized clocks. 

> 
> Section 5.4.2.12, paragraph 2, comment:
> > 5.4.2.12.  buffer occupancy
> >
> >    The "buffer occupancy" field is a 4-octet unsigned integer field.
> >    This field indicates the current status of the occupancy of the
> >    common buffer pool used by a set of queues.  The units of this field
> >    are implementation specific.  Hence, the units are interpreted within
> >    the context of an IOAM-Namespace and/or node-id if used.  The authors
> >    acknowledge that in some operational cases there is a need for the
> >    units to be consistent across a packet path through the network,
> >    hence it is RECOMMENDED for implementations to use standard units
> >    such as Bytes.
> 
> There are other "standard units" here, such as packets. You'd need to
> recommend a specific standard unit and not just give an example.

...FB: The topic of "units" for IOAM data fields has been discussed quite a bit and not prescribing units is the result of this discussion. The approach that the draft takes is to "avoid specifying a unit unless you have to", because it is quite easy to translate units in backend analytics systems. As long as one properly understands which unit is used for a particular field, backend systems can easily interpret the data and there is no need to prescribe a particular unit. So the draft acknowledges the fact that different devices provide for different units to measure buffer occupancy.

> 
> Section 5.5, paragraph 3, comment:
> >    o  Random: Unique identifier for the packet (e.g., 64-bits allow for
> >       the unique identification of 2^64 packets).
> 
> If this identifier is supposed to be unique, it can't be random. And if it's random,
> it will only be able to statistically uniquely identify a much smaller number of
> packets (birthday paradox).

...FB: Good point. The next rev will avoid the use of "random" and be more specific. 

> 
> Section 6.3, paragraph 11, comment:
> >       Microseconds: specifies the fractional portion of the number of
> >       seconds since the epoch.
> >
> >       + Size: 32 bits.
> >
> >       + Units: the unit is microseconds.  The value of this field is in
> >       the range 0 to (10^6)-1.
> 
> Given that the max. value for microseconds is 999999, using a 32-bit field leaves
> the top eight bits unused.

...FB: True. Are you suggesting that we'd rather make the top 8-bits "reserved" because they will never be used anyway?

> 
> -------------------------------------------------------------------------------
> All comments below are very minor change suggestions that you may choose to
> incorporate in some way (or ignore), as you see fit. There is no need to let me
> know what you did with these suggestions.
> 
> Matt Joras' Gen-ART review
> (https://mailarchive.ietf.org/arch/msg/gen-art/vzngkYWy-W-
> f0PHqAPNRlyNSwnw/)
> contains several other nits that I wanted to make sure you were aware of.
> 
> "Abstract", paragraph 2, nit:
> -    protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
> -                                                        ^^^^^^^^^^^^^^^
> -    header), or IPv4.  In-situ OAM can be used to complement OAM
> -   ---------
> -    mechanisms based on e.g.  ICMP or other types of probe packets.
> -                            ^
> +    protocols such as NSH, Segment Routing, Geneve, IPv6,
> +                                                        ^
> +    or IPv4.  In-situ OAM can be used to complement OAM
> +    mechanisms based on, e.g., ICMP or other types of probe packets.
> +                       +     ^
> 
> Section 1, paragraph 2, nit:
> -    in [RFC7799] IOAM could be portrayed as Hybrid Type 1.  IOAM
> -    mechanisms can be leveraged where mechanisms using e.g.  ICMP do not
> -                                                           ^
> +    in [RFC7799], IOAM could be portrayed as Hybrid Type 1.  IOAM
> +                +
> +    mechanisms can be leveraged where mechanisms using, e.g., ICMP, do not
> +                                                      +     ^     +
> 
> Section 4, paragraph 3, nit:
> -    expected that each such encapsulation will be defined in the relevant
> -                                           ^ ^
> +    expected that each such encapsulation would be defined in the relevant
> +                                           ^^ ^
> 
> Section 4, paragraph 4, nit:
> -    IOAM data does not leak beyond the edge of an IOAM domain using,for
> +    IOAM data does not leak beyond the edge of an IOAM domain using, for
> +                                                                    +
> 
> Section 4, paragraph 4, nit:
> -    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.
> +    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.,
> +
> + +
> 
> Section 4, paragraph 4, nit:
> -    message handling (i.e. in case of IPv6, IOAM support for ICMPv6 Echo
> +    message handling (i.e., in case of IPv6, IOAM support for ICMPv6 Echo
> +                          +
> 
> Section 4, paragraph 7, nit:
> -    are encapsulated into "parent" protocols, like e.g., NSH or IPv6 is
> +    are encapsulated into "parent" protocols, like, e.g., NSH or IPv6 is
> +                                                  +
> 
> Section 4, paragraph 8, nit:
> -    the-night model, i.e. IOAM-Data-Fields in one layer are independent
> +    the-night model, i.e., IOAM-Data-Fields in one layer are independent
> +                         +
> 
> Section 5.1, paragraph 3, nit:
> -    different categories.  In IOAM these categories are referred to as
> +    different categories.  In IOAM, these categories are referred to as
> +                                  +
> 
> Section 5.2, paragraph 2, nit:
> -    transit nodes".  The role of a node (i.e. encapsulating, transit,
> +    transit nodes".  The role of a node (i.e., encapsulating, transit,
> +                                             +
> 
> Section 5.2, paragraph 3, nit:
> -    called the "IOAM encapsulating node", whereas a device which removes
> -           ^^^
> -    an IOAM-Option-Type is referred to as the "IOAM decapsulating node".
> -                                          ^^^
> +    called an "IOAM encapsulating node", whereas a device which removes
> +           ^^
> +    an IOAM-Option-Type is referred to as an "IOAM decapsulating node".
> +                                          ^^
> 
> Section 5.2, paragraph 7, nit:
> -    means that an IOAM node which is e.g. an IOAM-decapsulating node for
> +    means that an IOAM node which is, e.g., an IOAM-decapsulating node for
> +                                    +     +
> 
> Section 5.3, paragraph 6, nit:
> -    assigned range is intended to be domain specific, and managed by the
> -                                           ^
> +    assigned range is intended to be domain-specific, and managed by the
> +                                           ^
> 
> Section 5.3, paragraph 9, nit:
> -       e.g. at a domain edge or domain boundary.
> +       e.g., at a domain edge or domain boundary.
> +           +
> 
> Section 5.4, paragraph 2, nit:
> -    deployment all nodes in an IOAM-Domain would participate in IOAM and
> +    deployment, all nodes in an IOAM-Domain would participate in IOAM and
> +              +
> 
> Section 5.4, paragraph 2, nit:
> -    ways to deal with situations where the PMTU was underestimated, i.e.
> +    ways to deal with situations where the PMTU was underestimated, i.e.,
> +
> + +
> 
> Section 5.4, paragraph 10, nit:
> -       i.e. ingress interface.
> +       i.e., ingress interface.
> +           +
> 
> Section 5.4, paragraph 11, nit:
> -       i.e. egress interface.
> +       i.e., egress interface.
> +           +
> 
> Section 5.4.1, paragraph 2, nit:
> -    i.e. an IOAM transit node MUST NOT modify the Namespace-ID, NodeLen,
> +    i.e., an IOAM transit node MUST NOT modify the Namespace-ID, NodeLen,
> +        +
> 
> Section 5.4.2.2, paragraph 6, nit:
> -    with ingressing or egressing packets, i.e. ingress_if_id could
> +    with ingressing or egressing packets, i.e., ingress_if_id could
> +                                              +
> 
> Section 5.6, paragraph 9, nit:
> -                encapsulating node e.g. by n-tuple based classification
> +                encapsulating node, e.g., by n-tuple based classification
> +                                  +     +
> 
> Section 5.6, paragraph 10, nit:
> -                encapsulating node e.g. by n-tuple based classification
> +                encapsulating node, e.g., by n-tuple based classification
> +                                  +     +

...FB: Thanks much. We'll fix all of those in the next rev (-12).

Thanks again for all your comments, Frank
> 
>