Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Robert Raszuk <robert@raszuk.net> Thu, 30 March 2017 15:31 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687E129512; Thu, 30 Mar 2017 08:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 z-wSdaCu5cGS; Thu, 30 Mar 2017 08:31:06 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD5C129533; Thu, 30 Mar 2017 08:31:04 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id y18so78460637itc.1; Thu, 30 Mar 2017 08:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=b5zLQECnWrxvR4MOa5o3fJnL2vxvJEobnElGydwPSqs=; b=ZwLiwNin+0sYnmDZm0o1bE0x3tRdCCZQgfTRVn0lOVvon+k8Te1gNEMvQP6NY01HLu nuvjZS3Os0Wyc1WkQthgnWWF02uS12DoTFGmh1kedIHTbWqajvn82vuj94t9ToOTnqom tbf/mQO47R34XZiGud+6dShTN9TkJY09KJNhxiYvj7IlIhNAihP7VEMe+OgnQsjZEhgx htKUq3Q68RFxKpVnwhoca0CQvaSd8vuEeR/iIDH3Z661irF94H50/xhM7rI20ieE8Lpl Uw2diNLwziP+Bg+FZ3duV22+UlijtHtGcy3umpHoiwpHJlGLkMO7t3YBm8fxr9gXZWOh FQxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=b5zLQECnWrxvR4MOa5o3fJnL2vxvJEobnElGydwPSqs=; b=BDa1jU9ZXmrHmhufcHAcSpO/VkxlvN5QxvZNhyJP33Ug0KZsPIibG6xHXAP4QgDt7D IRqy3GUpzwRWaDUl6hGKn+zvDy6xs1Bnk0RiR2RHxjZBmAwH5vz8Qiine2BDCplT97AF 1W2y4pexSE+Xy+7TV5mdPhGp9TDxQ1gHMaj8vgsemrPj7u0/H2WzivfnjUHhGQrRQcsk 4Ue2t6651cuY7vKVXb08vbO1rONqLHC5xO9LC2ergmRej52mgDgoKZiYuz7AU9aPTYk2 JZ4rDtTYeZ7klL0xjaZhIxcxgfJN7ML/s1lio9WfPcigIA9evNepXZmirjXAVckqxoDv EtYQ==
X-Gm-Message-State: AFeK/H2p/wFG4/g5jd8Dc37K5XGFdup5+zksyRRLGSCwAU6kiDoBmJBjMThtzvd0rdOx83svTpeNnwd3pd8+fA==
X-Received: by 10.36.65.203 with SMTP id b72mr5036732itd.24.1490887863519; Thu, 30 Mar 2017 08:31:03 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 08:31:02 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 08:31:02 -0700 (PDT)
In-Reply-To: <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 30 Mar 2017 10:31:02 -0500
X-Google-Sender-Auth: W1jS1pmtbL_4D912WoIZdG-CEFw
Message-ID: <CA+b+ERk8kHWyBY3GPp21-pgrL_SsShaLkrn4UdecFeQPYamSEg@mail.gmail.com>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, IETF Discussion <ietf@ietf.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>, 6man <ipv6@ietf.org>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a1143f4348163aa054bf461e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lUTPlUgQlyPvipnvmt2MhyPsjsg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 15:31:09 -0000

Hi Brian,

Could you elaborate a bit on the definition of "accidentally escaping
packets" ?

The fundamental issue with original Suresh suggestion I see is that his
proposed text kills ability to have 2460bis as normative reference in any
other draft describing or defining extension headers. And effectively stops
any work which needs to be based on 2460bis till 2460bis is updated.

Kind regards
R.






On Mar 30, 2017 10:11, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:

On 31/03/2017 02:11, Jeff Tantsura wrote:
> Brian,
>
> if I understand you correctly:
>
> If properly worded (improved) draft-voyer explicitly states – the
intention is to change the 2460(bis) behavior and to allow header insertion
within a controlled domain, and given there’s a valid justification of why
encap wouldn’t’ meet the need, you wouldn’t oppose?

No, I wouldn't. I might even help; hence my suggested tweak to 2460bis.
Note that the tricky bit (in reality and in the text) is a crisp definition
of what the domain boundary is and what happens when packets with inserted
headers accidentally escape. We did hit that difficulty when trying (and
failing) to define local-use rules for stateful use of the flow label. But
we were trying to do that in a generic document (in effect, an extension of
RFC2460) and failed for essentially the same reasons that led Suresh to his
decision on 2460bis.

https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some
remnants of that attempt.

    Brian


>
> Thanks!
>
> Cheers,
> Jeff
>
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <
ietf-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:
>
>     On 30/03/2017 15:59, Leddy, John wrote:
>
>     ...
>     > If this insert/delete of an SRH is prematurely prohibited;  What is
a recommended solution to the Real World problem above.  Not use case, we
are implementing.
>     >
>     > Again; I’m worried we are eliminating a tool that may prove very
helpful, preclude its use in future IETF work and shutdown a path for
Innovation in Networking,
>
>     I've tried to say this before but I'm not sure people are getting it:
>
>     RFC2460bis, if approved as is, draws a line in the sand *for
interoperability across the whole Internet*. There are reasons for this -
PMTUD in any form, any future replacement for the unsuccessful IPsec/AH,
and all the problems of deploying extension headers that are understood by
some nodes and not by others.
>
>     There is no reason why a subsequent standards-track document cannot
allow header insertion (and removal) within finite domains where the above
issues do not apply. In fact, an improved version of
draft-voyer-6man-extension-header-insertion-00 could become exactly that.
>
>     There doesn't need to be a tussle here.
>
>        Brian Carpenter
>
>
>
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------