Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

Ca By <cb.list6@gmail.com> Wed, 12 April 2017 13:50 UTC

Return-Path: <cb.list6@gmail.com>
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 60EFD1294C0 for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 06:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 CMoWC_l4zlt9 for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 06:50:30 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 C2C5B1294B5 for <v6ops@ietf.org>; Wed, 12 Apr 2017 06:50:29 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id j9so11922036ywj.3 for <v6ops@ietf.org>; Wed, 12 Apr 2017 06:50:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fv3QtNJ8Fug5Boa5ZogWeYVd9nSrP49vXCBqGahxKPQ=; b=AHPqe0KYO0Nc9s6LjR9p0J65mqugRk/FP5FjlQDty/tYgzb1cCP0qqCjSoLpwTchse WGqW/LrSEk6bpwEnfp9h1IG3fcu4uF5iyL/CYkTBLnd0Tyo27rVtgbdlSpdk2+/ZnwsS FYaAd+RrVaCLJfV5NThIp1mLdiKIAVKvgULGrLgHPa/e0XfQYSrgECc76XSCQ2YJPpY6 xBOgC0euxFxSxVs+hz9Tsi+tIDG2j6232MlqwK8twQJu9noo4e/5d9r2HX1UwTx//aN2 OBMRMan9r09f5x2quaMuyfH/X1GOk2bZ36kE4WTb0JOQNpIUOSpQHedqmd0C50XsibC+ f+Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fv3QtNJ8Fug5Boa5ZogWeYVd9nSrP49vXCBqGahxKPQ=; b=HYqf+R/L13Ee1wvk5/i5nGHWhy/B9zm32uJPSmh8SzKFVelU575Em9scyNA5FkGqQR 765++QQeuejbD7o6aN8hFMdpHXF/v8KbhUUuRUDDi9aO0EOj0VcVSWGIDmfXa99IUcPq /OoNXKVbXTTyn5xWaiar7r9LAT8buxA6vu2YpF1NcWO0SZyQgE5316eKZzzoSoq3j7c6 Wf4UxM54jkXNJ1VVPt9DlkmSwbhLWsSn5D+gPTgbulnY+6Ag/O22PuuyxdPhGqgxiIaJ tQJ0DAZv9pA+nf1FS7D82hfS1gmg9BkckcUgcR2n8KgKWqOlMsOOdEZc3Xy2ch+lzwDQ IttQ==
X-Gm-Message-State: AN3rC/6NjbuQOFjGVsQgsPXZer//eRbe/l70FoppwBtWUW4sBrx1BpdCGBHT9HAnR2lwMdS6GX5COtUMTIZxtg==
X-Received: by 10.129.53.199 with SMTP id c190mr8694896ywa.80.1492005029002; Wed, 12 Apr 2017 06:50:29 -0700 (PDT)
MIME-Version: 1.0
References: <D8F5C737-B01A-4EC8-9175-C4921C0CD69F@consulintel.es> <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org>
In-Reply-To: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org>
From: Ca By <cb.list6@gmail.com>
Date: Wed, 12 Apr 2017 13:50:17 +0000
Message-ID: <CAD6AjGQyatWEOxCpnOn8H+SxG=BWM=cBPaXoON6vA7dj7TNqOQ@mail.gmail.com>
To: jordi.palet@consulintel.es, otroan@employees.org
Cc: v6ops@ietf.org
Content-Type: multipart/alternative; boundary="001a11421778c1c3db054cf87d23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Y2Yye280bFQ385T7UVFv2iUNqU8>
Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
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: Wed, 12 Apr 2017 13:50:32 -0000

Ole

On Wed, Apr 12, 2017 at 3:56 AM <otroan@employees.org> wrote:

> Jordi,
>
> > I’m NOT in favor of including an unlimited number of mechanisms, and I
> think we must focus in those that have a real traction. I’m NOT in favor of
> including LISP.
> >
> > However, the document is a WG document, so is not just my decision, but
> the WG, so I must ask the WG opinions before “rejecting” LISP. That was my
> question.
> >
> > I think we need to have a balance:
> > 1) Main goal, support of IPv6-only access but allow IPv4 to keep working
> in the customer’s LANs.
> > 2) Allow the support of “older” IPv6-in-IPv4 (basically 6rd) as it was
> in the previous version of the document, but moved to MAY. Deployments that
> today have IPv4-only access, can start deploying IPv6 (in IPv4 if they need
> it), but use the same CE for when they can move to IPv6-only access.
>
> Which is a bit ironic with regards to 6RD which is one of the few
> mechanisms with real deployment, as in millions and millions of users.
>
> >3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed),
> based on market relevance and understanding that most of them don’t take
> additional code in the CPE, because most of this code is basically the same.
>
> That statement is not quite true. The various mechanisms while largely
> being built out of the same parts, require quite a bit of glue, testing and
> additional support for configuration. If you think the conflict around
> hosts/network DNS recursive resolver configuration is hard, then this is a
> n-square problem.
>
> For implementation complexity just compare MAP-T and MAP-E/LW46 in:
> https://git.fd.io/vpp/tree/src/vnet/map


Has there yet been a substantial (millions of subs) deployment of any of
those listed ?  I would not say your metric of subjective complexity is
relevant to the current hundreds of millions of subs on v6 or v6-only.

I think map-t may have had some recent deployment at Jio, but it is not
clear to me how much they have used map-t vs DS ... or their v6 numbers in
mobile vs landline.

<https://git.fd.io/vpp/tree/src/vnet/map>
>
> > So, to make it short, unless there is a “magic” mechanism that I’m not
> aware of, and the WG decides to include it, my intend is no longer include
> anything new in the document. And if that “magic” mechanism exists, then we
> could delete all the others.
>
> The magic is in us having the balls to make a choice. And pick one
> mandatory to implement mechanism. And only one.
>

Disagree. This idea of a standard is neither true for ipv4 networks or ipv6
networks. You make standards for interop and design validation, not
picking a universal solution.  Neither have seen one magic choice in
routing protocols, L2 encap, security strategy, v4-v6 transition....

Softwire WG already has seen this approach fail both the working group and
industry several times.  Softwire's approach failed me and my deployment.

Coin flips don't convince anyone of anything aside from your standards
being arbitrary and not driven by practical deployments.

CB

Ps. LISP remains in search of a problem it solves, and has, afaik, not been
used to push ipv6 forward in the real world.


> Cheers,
> Ole
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>