Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Ron Bonica <rbonica@juniper.net> Wed, 12 July 2017 15:45 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F712F257 for <int-area@ietfa.amsl.com>; Wed, 12 Jul 2017 08:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 QoQwfUOppmME for <int-area@ietfa.amsl.com>; Wed, 12 Jul 2017 08:45:53 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0124.outbound.protection.outlook.com [104.47.42.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FA712F3D5 for <int-area@ietf.org>; Wed, 12 Jul 2017 08:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AoWbSNK3e78SZ4uRY9Wfaf4QA5cSD87N+mqBFex8JxI=; b=BOkQiNp+vlc8B1XpHdldnjmRLRGFcFkYGiHfCEyieKKuFNA+NSxLu6KrlGqvqKMcfEaQ1jokeLuuSDLrLcdaljwhn57qEsU8dCXbeZCfhNJ6gGDc20EQbZVVPjCD9UEE108Pi1K6jlON3b1Qd1Ws6st7/ajOeHC5u94UKFIFpoM=
Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB2030.namprd05.prod.outlook.com (10.163.227.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 12 Jul 2017 15:45:52 +0000
Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) with mapi id 15.01.1261.012; Wed, 12 Jul 2017 15:45:52 +0000
From: Ron Bonica <rbonica@juniper.net>
To: "int-area@ietf.org" <int-area@ietf.org>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt
Thread-Index: AdL7Je43Z0B6UbQRQ8OzttnbbdH15Q==
Date: Wed, 12 Jul 2017 15:45:52 +0000
Message-ID: <SN1PR0501MB20626C6892CF218223CFF849AEAF0@SN1PR0501MB2062.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2030; 7:FhaueoBMqo95zVx7wEo1anVMJJ6m9bw2EzjRTaDz71rbDvmO4PBYKrW5gEfhhy5Vrg83K3m6WM3qoSNZvXkS1YjS8j1ycsdAPi7QaeD+OtsVZvWWReIOsUZlL0giTwnYFbLR0lC48cuFmATfYm8WjilBhR9zAiq849BvSoWVWymMX7Hpfx3tkV0sXJDuwwFoxWZuZlRmHXQXpjsI+fwgFfrFYZE6VQMyfit02+daCrOqvmuI0LB5tM+M5tJIP6ivOQOXGa6M62vazphEs7uXHOi8KZJXXnXio2qliZA6bL7gPU/L+1gxxIJ3kRD9SjkuKnyV0YlzBt8FQamyOeUar4A9GxDN5aLiSsmTu1gz4B3jUtKt1/jIuf09igTvvEX3wpiJXu0yx4i3kIyHzjNCSdg9wYoQ8fQFUgscY5noy03De3Y9x8m5+LiteG2axIUd4gLLCu4uDw+cIOKr2CosmzonpqkqD/9W08KO39P3NjOtWPG9N+zpMml3jktI2Amx8+s4Q4jrjVolpFP5ajbeBhEc7u6wBvcSMMGcyC3uazMBG+J6pzL9di0XaAxW3WJaIf2FWqdr7M/GPL/j51QeieXpAiPffEOFo4k/jG4rvmegmreeLdr5pmSCskNUlahTzhLK1r8FwFWfSrXg6RIvqIqKV+GDZoP5UzRrfs3ar/gu/2j69Lkzhi7mBk8obJXmFke7IkchVmbKMZPuy9jhTPf2VclWwTaGxUJ9Fs5B/VMuY/iw8IH955dsxMUeFdwl2YXb7tUZt0AmkVBSGE7fPA1muDc3Q19Dy5fgjgIEd8U=
x-ms-office365-filtering-correlation-id: 98ebb0bf-d30f-47df-d765-08d4c93d1387
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0501MB2030;
x-ms-traffictypediagnostic: SN1PR0501MB2030:
x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(148574349560750);
x-microsoft-antispam-prvs: <SN1PR0501MB2030AAA96F7996809B1EBB3CAEAF0@SN1PR0501MB2030.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2030; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2030;
x-forefront-prvs: 036614DD9C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(39400400002)(3846002)(230783001)(6506006)(77096006)(229853002)(102836003)(2900100001)(7696004)(3280700002)(6116002)(2906002)(54356999)(3660700001)(25786009)(86362001)(50986999)(5660300001)(66066001)(2501003)(7736002)(189998001)(38730400002)(8676002)(6246003)(8936002)(53936002)(6306002)(305945005)(99286003)(9686003)(74316002)(55016002)(14454004)(478600001)(6436002)(966005)(81166006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2030; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 15:45:52.2690 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2030
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/nQRs9YfH9vRDPk7F14V0e9jR0h4>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2017 15:45:55 -0000

Hi Carlos,

Thanks for the review. Inline, below.

                                        Ron

> 
> Hi, Ron, Authors,
> 
> As I was reading over draft-ietf-intarea-probe-00, and wanted to share a
> couple of observations for your consideration.
> 
> 
>   *   Have you considered the tradeoff of defining new ICMP Types versus
> extending existing ICMP Types? If using existing ICMPv6 Echo Request/Reply
> and extending them instead of defining brand new types, the backwards
> interoperability achieved is higher
[
[RB ] 
I thought about extending the existing ICMP messages, but decided against it for backward compatibility reasons. Both existing messages end with a variable length data field. This field begins at a fixed position, but doesn't have a length attribute of its own. Therefore, we can't add any more fields after it.

There may be ways to dance around the problem, but they all involve redefining the existing field in the existing message.


>   *   Have you considered using other protocols as well in addition to ICMP for
> the PROBE message, which can elicit ICMP errors or responses with
> appropriate extensions? In particular UDP is a protocol much used and
> desired for probes.
> 
[RB ] 
ICMP and UDP would both work. I chose ICMP because ICMP already supports legacy echo/echo reply. But I'm not feeling religious about this.
In the final analysis, I am willing to use whatever protocol the WG prefers.

> These two points actually reminded me of https://tools.ietf.org/html/draft-
> shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen-
> udp-traceroute-ext-01) that defines a probe extension applied to ICMP Echo
> Request and UDP, and RFC 4884 extensions to responses. That approach
> seems somewhat more generic.
> 
> Additionally, I was also reminded of the ICMP AUP at RFC 7279, it would be
> useful to map against that doc to show how this is (as it is the case) a really
> good use of ICMP.
[RB ] 
Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls out PING as being an acceptable use. But again, I don't feel religious about this. The protocol works over UDP just as well as it works over ICMP.

                                                                                                                      Ron

> 
> Thanks!
> 
> ? Carlos.
> 
> 
*******************************