Re: [tig-diagnostics] Uploading icmp aup

Ronald Bonica <rbonica@juniper.net> Wed, 11 July 2012 17:55 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: tig-diagnostics@ietfa.amsl.com
Delivered-To: tig-diagnostics@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2E11E8116 for <tig-diagnostics@ietfa.amsl.com>; Wed, 11 Jul 2012 10:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Level:
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1VDAQK2kufP for <tig-diagnostics@ietfa.amsl.com>; Wed, 11 Jul 2012 10:55:25 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71711E80DB for <tig-diagnostics@ietf.org>; Wed, 11 Jul 2012 10:55:25 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT/2+Ic6iV77h/Zgr/cYjMY7jFwFvou2U@postini.com; Wed, 11 Jul 2012 10:55:56 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jul 2012 10:52:04 -0700
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jul 2012 10:52:03 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 11 Jul 2012 13:51:36 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: Melinda Shore <melinda.shore@gmail.com>, Carlos Pignataro <cpignata@cisco.com>
Date: Wed, 11 Jul 2012 13:51:36 -0400
Thread-Topic: [tig-diagnostics] Uploading icmp aup
Thread-Index: Ac1eDnniVeeFFlqMRHSC3u6qqfqRVwBeasDA
Message-ID: <13205C286662DE4387D9AF3AC30EF456D77008617B@EMBX01-WF.jnpr.net>
References: <4FFB39FC.1080605@gmail.com>
In-Reply-To: <4FFB39FC.1080605@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tig-diagnostics@ietf.org" <tig-diagnostics@ietf.org>
Subject: Re: [tig-diagnostics] Uploading icmp aup
X-BeenThere: tig-diagnostics@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <tig-diagnostics.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tig-diagnostics>, <mailto:tig-diagnostics-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tig-diagnostics>
List-Post: <mailto:tig-diagnostics@ietf.org>
List-Help: <mailto:tig-diagnostics-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tig-diagnostics>, <mailto:tig-diagnostics-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 17:55:26 -0000

Hi Melinda,

I think a better approach might be to define an AUP for ICMP in Section 1. In Section 1.1, demonstrate how all existing ICMP messages conform to that AUP. In Section 2, call out areas in which current practice falls short of the goal state in the AUP and in which future ICMP work is required.

Only in Section 3 should you call out inappropriate uses for ICMP. In Section 3, please avoid specific references to specific proposals. The people who we offend are not likely to be supportive of this draft!

IMHO, the only appropriate use for ICMP are:

1) to inform a datagram's originator that a forwarding plane anomaly has been encountered downstream. By examining the ICMP message, the datagram originator must be able to determine whether the forwarding plane anomaly that cause the ICMP message to be sent also caused the original datagram to be discarded. 
2) to discover on-link routers and hosts

In Section 1.1, it should be pretty easy to assign all existing ICMP messages to one of the two categories listed above. The only difficult case is the ICMP Redirect message. However, you could argue that the redirect message reports a forwarding anomaly in which the originator of the ICMP message forwards a packet through the same interface upon which it was received.

In Section two, you could call out cases in which the ICMP message doesn't make it to the originator of the datagram. For example, if a datagram times out inside a tunnel, the ICMP message is sent to a tunnel endpoint. The endpoint device may or may not relay the message to the datagram originator. You can also call out cases in which the ICMP message makes it to the datagram originator, but contains deceptive or incomplete information (e.g., in the presence of NAT).

In Section 3, you can briefly mention that ICMP should not be used as a routing or network management protocol.

What do you think?

                                  Ron





> -----Original Message-----
> From: tig-diagnostics-bounces@ietf.org [mailto:tig-diagnostics-
> bounces@ietf.org] On Behalf Of Melinda Shore
> Sent: Monday, July 09, 2012 4:07 PM
> To: Carlos Pignataro
> Cc: tig-diagnostics@ietf.org
> Subject: [tig-diagnostics] Uploading icmp aup
> 
> I'm in the process of uploading the ICMP AUP draft.  I've spent the
> last few days looking at it and thinking "no, that's not right" and
> then rewriting portions, it's been a bit of a slog.  I've taken the
> liberty of adding your name as co-author, both because you've said that
> you'd be interested in helping whip this thing into shape and because I
> relied quite a bit on your bibliography.
> 
> It is being posted as draft-shore-icmp-aup.  If there's interest we can
> discuss it at the opsawg session in Vancouver.
> 
> Melinda
> _______________________________________________
> tig-diagnostics mailing list
> tig-diagnostics@ietf.org
> https://www.ietf.org/mailman/listinfo/tig-diagnostics