Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 15 April 2018 09:16 UTC

Return-Path: <prvs=1643abb877=jordi.palet@consulintel.es>
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 2DB7C126DFF for <v6ops@ietfa.amsl.com>; Sun, 15 Apr 2018 02:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 7xRvek0HuHXA for <v6ops@ietfa.amsl.com>; Sun, 15 Apr 2018 02:16:46 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E9D1267BB for <v6ops@ietf.org>; Sun, 15 Apr 2018 02:16:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1523783803; x=1524388603; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=+800Cspy 7dYD1diXaDHDwllEUBoautkVZ0qLehEZCZ8=; b=E0baMvEFY+wo1AMsgK4/FdIA ML9JKV1aNfhQE/zbFbodCKqDO+3GoO4J5umIP1HO8KJB+1I6Cxf2El1iIREWmOep bMVs1c8gn7c9vfGutoa7r+M9NPt5+SwXlqEzhyHn9eNG72C/klrEKytXPXPIY5jh bzo7/2FDe+1bBdUAGV4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 15 Apr 2018 11:16:43 +0200
X-Spam-Processed: mail.consulintel.es, Sun, 15 Apr 2018 11:16:42 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005751622.msg for <v6ops@ietf.org>; Sun, 15 Apr 2018 11:16:42 +0200
X-MDRemoteIP: 2001:470:1f09:495:f0d0:adcb:2e90:97bf
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Sun, 15 Apr 2018 11:16:42 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1643abb877=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Sun, 15 Apr 2018 11:16:39 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: V6 Ops List <v6ops@ietf.org>
Message-ID: <7E49B768-9650-4804-9B59-49EAB8A8F91A@consulintel.es>
Thread-Topic: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com>
In-Reply-To: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GvkDYapWLw0KXfX0zkAUE3O68t4>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
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: Sun, 15 Apr 2018 09:16:48 -0000

Hi Fred, all,

My comments regarding this.

RFC7084 had only 2 transition mechanisms, DS-Lite and 6RD.

draft-palet-v6ops-transition-ipv4aas has 4:
1) lw4o6: Basically, in terms of code, this is a "subset of DS-LITE", so if DS-Lite and IPv4 NAT support is already implemented, lw4o6 is also "there".
2) 464XLAT MAP-T and MAP-E. They also share most of the code already implemented for the previous ones.

This is explained in section 7 of the document, as it was requested during previous discussions in the draft-ietf-v6ops-rfc7084-bis and "follow-up" docs.

Last, but not least, because this document follow the same structure regarding the transitions mechanisms as RFC7084, the document doesn't mandate any of them. It is just saying, "if you want to implement this transition, remember that in addition to RFCxxx, you need to do this and that".

>From that perspective, I don't think the comment "too many" is a valid one. In fact we could add more, and be in the same situation: the document is not mandating any of them. I recall I responded to that question in the last meeting and was not "contra-argued" on that.

Regarding the question of if there are deployments on each of those, yes, probably fewer on MAP-E/T that the other two, but they are big.

During the discussion on draft-ietf-v6ops-rfc7084-bis, it was confirmed in the list by several voices, hopefully they can confirm again and I'm sure there are many others, for example for the case of lw4o6, I recall this email from DT group:

https://www.ietf.org/mail-archive/web/v6ops/current/msg25227.html, which mentions 1.5 million users.

I'm aware of similar other cases with each of those mechanisms, even with several millions users.

What we, unfortunately, aren't going to get here, is the voices of small ISPs (500-10.000 customers), which I know a few of them as well, which are asking their CE vendors for this support, and the response is "not in RFC7084") and they aren't "big" enough (each of them), to ask for that in a tender, specially because in most of the cases, they just go to the retail market and buy 10 units each week (last week I got a couple of cases on that in Spain, during the ESNOG, considering lw4o6 or 464XLAT).

Another example is:
https://mailarchive.ietf.org/arch/msg/v6ops/GvBFbzn32pP5x02UbB_7E3B12SQ

In my survey about IPv6 deployment (only residential, no corporate, no cellular), with over 1.520 responses up to now, I got 3% with 464XLAT, 1% for lw4o6, 1% for MAP-E, 1% for MAP-T. For comparision, 6rd was 3%, softwires 1%, tunnel broker 3%, dual-stack with CGN 8%, DS-LITE 3%, dual-stack with public IPv4 71%.

Just comparing a single "pair", 6rd with 464XLAT, I think it is easy to conclude that they are at the same level. There was a time for 6rd and DS-Lite, time is now for successors which allow "IPv6-only" access.

I'm sure my co-author, a CE vendor, can also provide more details on all this from a vendors perspective and what they heard from customers/market.

So clearly, I think that being this document a "follow-up", as instructed by the v6ops WG, after having adopted as WG item RFC7084-bis, we should do the same with this document.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.ietf@gmail.com>
Fecha: domingo, 15 de abril de 2018, 7:00
Para: V6 Ops List <v6ops@ietf.org>
Asunto: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    At IETF 101, Jordi Palet Martinez presented draft-palet-v6ops-transition-ipv4aas. The draft is at https://tools.ietf.org/html/draft-palet-v6ops-transition-ipv4aas, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-00.
    
    I would like to invite discussion.
    
    In particular, this draft derives from draft-ietf-v6ops-rfc7084-bis, and the chairs wonder if it should be reposted as the next version of draft-ietf-v6ops-rfc7084-bis. That should happen if an only if the working group thinks it should be published as an RFC (now or at some point) adding considerations for implementors of RFC 7084 and also implementing transition services.
    
    A key comment at IETF 101 was that there remain far too many transition mechanisms listed. It would be helpful, if you hold that opinion, if you could give that advice, identify the mechanism or mechanisms you think should be listed, and indicate the reasoning behind your viewpoint. For example, if you think MAP-T should be listed, it would be helpful to know what operators are implementing MAP-T and are looking for CE Routers that support it. The same comment applies to any such mechanism or service.
    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.