Re: [v6ops] possible path forward with RFC7084 and transition/other stuff

Nick Hilliard <nick@foobar.org> Fri, 21 July 2017 11:00 UTC

Return-Path: <nick@foobar.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0112ECF0 for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 04:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 aY910VW3xvTI for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 04:00:38 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA7212EC51 for <v6ops@ietf.org>; Fri, 21 Jul 2017 04:00:37 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6LB0SG8032025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2017 12:00:29 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5971DECC.3030005@foobar.org>
Date: Fri, 21 Jul 2017 12:00:28 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.16 (Macintosh/20170718)
MIME-Version: 1.0
To: jordi.palet@consulintel.es
CC: v6ops@ietf.org
References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es>
In-Reply-To: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/StmZNuu-iFYYsj6-zt6_HXpSduk>
Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jul 2017 11:00:40 -0000

JORDI PALET MARTINEZ wrote:
> (I’m sending this email after checking with the WG chairs if they agree on it)
> 
> Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), have a chat about a possible path forward with the RFC7084-bis and related docs.
> 
> If I understood correctly, we somehow agreed that a possible path is (let’s call this CHOICE 1):
> 1) Not change/update the existing RFC7084.
> 2) Use my “Transition Requirements for IPv6 Customer Edge Routers” document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting point, which “extend” the requirements of RFC7084 towards supporting actual world transition requirements.
> 3) In this updated document, the transition requirements can then be a MUST, so vendors take it seriously.
> 4) I will include the reference to RFC8026 (some more text, as this reference is already in all my docs regarding this topic), so there is a “flow” of how the pair “ISP-CE” can get working IPv6 and then IPv4 if it is available from the ISP “as a service”. I think this can have also what Fred was suggesting as “IPv6 must be on by default”, right?
> 
> CHOICE 2 (to make it clear, my own toughs after waking up this morning, not discussed with the other folks yesterday):
> Same as choice 1 above, but include also support for HNCP and may be something else if we believe it is required during the development of this document (for example it seems clear that if we offer IPv4 as a service, because actual multicast-based IPTV services run on IPv4, we need to keep supporting that on top of an IPv6-only access).
> So then the document will be renamed to something such as “Transition and extended requirements for IPv6 CE routers”.
> 
> Tim, Barbara, James, can you confirm if I got right choice 1, or misunderstood/missed anything?
> 
> WG participants, could you provide your view on those two options?

I haven't seen much deployment of HNCP, so at this stage it would
probably be premature to state it as a requirement in a CPE router
scenario.  Otherwise, option 1 looks great, so go for it!

Nick