Re: [Int-area] question about xping (draft-bonica-intarea-eping)

Sowmini Varadhan <sowmini.varadhan@oracle.com> Wed, 29 March 2017 15:32 UTC

Return-Path: <sowmini.varadhan@oracle.com>
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 E430E1296D7 for <int-area@ietfa.amsl.com>; Wed, 29 Mar 2017 08:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 6Ra6LOuVxCwR for <int-area@ietfa.amsl.com>; Wed, 29 Mar 2017 08:32:57 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E871296D3 for <int-area@ietf.org>; Wed, 29 Mar 2017 08:32:57 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2TFWsnr026566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Mar 2017 15:32:55 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2TFWsRg022953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Mar 2017 15:32:54 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2TFWsTI014540; Wed, 29 Mar 2017 15:32:54 GMT
Received: from oracle.com (/207.91.160.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Mar 2017 08:32:53 -0700
Date: Wed, 29 Mar 2017 11:32:47 -0400
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Ron Bonica <rbonica@juniper.net>
Cc: Reji Thomas <rejithomas@juniper.net>, "furry@google.com" <furry@google.com>, "chris.lenart@verizon.com" <chris.lenart@verizon.com>, "int-area@ietf.org" <int-area@ietf.org>
Message-ID: <20170329153247.GA6324@oracle.com>
References: <20170328213205.GC6413@oracle.com> <BLUPR0501MB2051EA17D498590F6335FA24AE320@BLUPR0501MB2051.namprd05.prod.outlook.com> <20170328224144.GA12970@oracle.com> <BLUPR0501MB2051DD681C73FB210530E0C9AE350@BLUPR0501MB2051.namprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR0501MB2051DD681C73FB210530E0C9AE350@BLUPR0501MB2051.namprd05.prod.outlook.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/yJG_d3tk3AoCEKuM5k_MTgNsJ8o>
Subject: Re: [Int-area] question about xping (draft-bonica-intarea-eping)
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, 29 Mar 2017 15:32:59 -0000

On (03/29/17 14:50), Ron Bonica wrote:
> 
> Sowmini,
> 
> You have convinced me that there should be no information leaking at
> all. So, I think that the next version of the draft should enforce the
> following rules:
> 
> -  If the destination and probed interfaces are in the same VRF/routing
> instance/namespace, the ICMP Extended Echo Reply message will reflect
> the state of the probe interface
> - Otherwise, the ICMP Extended Echo message will contain an error code
> indicating that the probed interface does not exist.
> 
> Do you agree?

Yes, that's a much more consistent model (esp since the same IP 
address can itself exist in multiple VRFs) and also extends without loss
of generality to other virtualization models.

thanks for addressing this!

--Sowmini