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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 26 April 2018 07:16 UTC

Return-Path: <prvs=1654602c4e=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 BC589127867 for <v6ops@ietfa.amsl.com>; Thu, 26 Apr 2018 00:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 4XSnRZuQloRG for <v6ops@ietfa.amsl.com>; Thu, 26 Apr 2018 00:16:57 -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 BDE8412704A for <v6ops@ietf.org>; Thu, 26 Apr 2018 00:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1524727015; x=1525331815; 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=CByLcHEg dzlTg7DuiVy/k3KOzJnhvxDX1/vrcAEeo+Y=; b=Hh/41HOhr3dCK98mSBqrK/7k 3ReObMi4Vk2WDEGTw5vR3b2yupGtd6E0VDTqr1wU0bseW1DrS22HfgUMOCrnUI5n a1NYK7mmma+FV6fAsl+usCvrC+qYz9Y7QIoaCVzYD7KIr4qvmiwjstLE6H6sUaRn +WzlSH7VywJ9RcaG+eI=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 26 Apr 2018 09:16:55 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 26 Apr 2018 09:16:54 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005758414.msg for <v6ops@ietf.org>; Thu, 26 Apr 2018 09:16:54 +0200
X-MDRemoteIP: 2001:470:1f09:495:5d10:1cc6:6774:1393
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Thu, 26 Apr 2018 09:16:54 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1654602c4e=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: Thu, 26 Apr 2018 09:16:52 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: V6 Ops List <v6ops@ietf.org>
Message-ID: <5DF54225-5D63-44B1-B8ED-1A24D9A1FA5F@consulintel.es>
Thread-Topic: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com> <6334FC96-5DC0-4ADF-BBD7-1746A885C6AB@employees.org>
In-Reply-To: <6334FC96-5DC0-4ADF-BBD7-1746A885C6AB@employees.org>
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/FitEjd6adL6abpcH_iX4H9VlrBs>
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: Thu, 26 Apr 2018 07:17:00 -0000

Hi Ole,

I agree in part with you. We defined too many transition mechanisms, but we are only engineers, not fortune tellers with a crystal ball, so we needed to "learn" from our own mistakes and enhance the earlier transitions techniques.

Also, we need to understand that not all the networks have the same way to do things, not same requirements, etc.

For example, MAP is fantastic if you have a broadband network only, but if you have also a cellular network, or you want to offer LTE backup to your broadband network, it makes more sense 464XLAT.

Looking into that, I think it help to have a document that summarizes those mechanisms that, after few years, look like the winners, so implementors and ISPs have an easier "single document" to follow and converge. If we look at all the options that we have for IPv4aaS, I think this document is reducing them to the half, which I think is a very good step.

I wish we can for example say "the best option is 464XLAT", is the only one supported in both broadband and cellular, and list only that one, but I think this is difficult to happen.

Regards,
Jordi
 
 
-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Ole Troan <otroan@employees.org>
Fecha: jueves, 26 de abril de 2018, 9:01
Para: V6 Ops List <v6ops@ietf.org>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    For the IPv4aaS mechanisms, the IETF could not come to consensus and ended up standardizing all the proposed solutions. This is failure.
    This same thing happened with the IPv6aaS (6to4, 6over4, 6rd, L2TP, Teredo...) mechanisms. Where the IETF tried to "fix" that by e.g. shutting down the ngtrans working group.
    
    For the IPv6aaS, history declared a few winners (6rd, NAT64), but it led to a lot of pain on the way (6to4 / Teredo / NAT-PT).
    I don't think the IPv4aaS mechanisms have equal risk of damage as what 6to4/Teredo had.
    
    Still, is there anything we have learnt from the last 3-5 years?
    Does it help or harm, that the IETF publishes a document perpetuating the failure?
    
    Ole
    
    > On 15 Apr 2018, at 07:00, Fred Baker <fredbaker.ietf@gmail.com> wrote:
    > 
    > 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
    
    _______________________________________________
    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.