Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Fri, 28 April 2017 08:46 UTC

Return-Path: <bclaise@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 209D2129C6F; Fri, 28 Apr 2017 01:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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
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 AdB-D2x2U2gf; Fri, 28 Apr 2017 01:46:24 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9F9126BF0; Fri, 28 Apr 2017 01:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3073; q=dns/txt; s=iport; t=1493369002; x=1494578602; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=OHkWsZi1V5Lx7iPgmibINPNOonquT+X+UeEO+/hxmhI=; b=I5oSY6dajze3ndZC8smfZJ9o3RsMUjvYkrMUxifo025CcfGnBXsCXGfl CuShwLG/I0Za4sNjDTW1JUntO8SDTnQixSQIr94a0iMVokduLayjer0Mh cUYgK4GTNUxj+0HopygLMJ4orFci3GlZszhafK/iGvyACoGHHufXWwKwB g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BSAQBRAANZ/xbLJq1aAxkBAQEBAQEBAQEBAQcBAQEBAYQ2gQyDaIoYc5BblWyCDyyFeAKEbBgBAgEBAQEBAQFrKIUVAQEBAQMjFREwEAsUAwECAiYCAk8IBgEMBgIBAYobDqthgiaLBgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VUgV4rgm+FACaCP4JfAQSJPZQThxmCaIkLggKFN4NChmOMAIgnHziBCi4gCBkVhWqBTD41AYdrAQEB
X-IronPort-AV: E=Sophos;i="5.37,387,1488844800"; d="scan'208";a="652500493"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 08:42:55 +0000
Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3S8gtHH002119; Fri, 28 Apr 2017 08:42:55 GMT
To: nalini.elkins@insidethestack.com, The IESG <iesg@ietf.org>
References: <554038332.13283997.1493352099497.ref@mail.yahoo.com> <554038332.13283997.1493352099497@mail.yahoo.com>
Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, Bill Cerveny <ietf@wjcerveny.com>, ippm-chairs@ietf.org, ippm@ietf.org, jiangsheng@huawei.com
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <a30a6331-21fb-56a5-72e2-801dbc539b00@cisco.com>
Date: Fri, 28 Apr 2017 10:42:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <554038332.13283997.1493352099497@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/VutQoEJWRQ60SoiBZJ4DzUEzD44>
Subject: Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
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: Fri, 28 Apr 2017 08:46:28 -0000

On 4/28/2017 6:01 AM, nalini.elkins@insidethestack.com wrote:
> On Wed, 4/12/17, Benoit Claise <bclaise@cisco.com> wrote:
>
>   Subject: Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
>   To: "The IESG" <iesg@ietf.org>
>   Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" <acmorton@att.com>, "Bill Cerveny" <ietf@wjcerveny.com>, ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org, jiangsheng@huawei.com
>   Date: Wednesday, April 12, 2017, 11:30 AM
>   
>> Benoit Claise has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection
>   
>>    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-6man-pdm-option/
>   
>   
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>   
>> No objection to the publication of this document, but it's important to get Warren's COMMENT addressed:
>> This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine /
>> ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out
>> of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6).
>   
>
> This was the text that was agreed on with Warren.   Please let me know if you agree.
Sure.

Thanks, B.
>
> Current Text
>   ----------------
>
> 1.6 IPv6 Transition Technologies
>
> In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed.  The PDM header is not expected to work in such scenarios.  It is likely that an
>   IPv6 packet containing PDM will be dropped if using IPv6 transition technologies.
>
> New Text
> ------------
>
> 1.6 Full Support of IPv6 Functionality
>
> In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed.  The PDM header may not work in such scenarios.  It is likely that an
> IPv6 packet containing PDM will be dropped if using IPv6 transition technologies.
>
> It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option.  For example, adding the PDM header to a packet
> may push the layer 4 information to a point in the packet where it is not visible to filtering logic, and may be dropped.  This kind of situation is expected to become rare over time.
>
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>   
>   
> .
>