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 --------------------------------------------------------------------
- IETF Last Call conclusion for draft-ietf-6man-rfc… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Stefano Previdi (sprevidi)
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… 神明達哉
- Re: IETF Last Call conclusion for draft-ietf-6man… Voyer, Daniel
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Fernando Gont
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Smith
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Xing Li
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Stewart Bryant
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Townsley
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Townsley
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Jeff Tantsura
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- RE: IETF Last Call conclusion for draft-ietf-6man… Ackermann, Michael
- RE: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… 神明達哉
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- RE: IETF Last Call conclusion for draft-ietf-6man… Ackermann, Michael
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Smith
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Jen Linkova
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Martin Rex
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Fernando Gont
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan