Re: [v6ops] Thoughts about wider operational input

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 21 March 2022 20:56 UTC

Return-Path: <prvs=1079dad7ec=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 840BA3A1B19 for <v6ops@ietfa.amsl.com>; Mon, 21 Mar 2022 13:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 aHhtoxbStIi9 for <v6ops@ietfa.amsl.com>; Mon, 21 Mar 2022 13:56:28 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5843A1B23 for <v6ops@ietf.org>; Mon, 21 Mar 2022 13:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1647896182; x=1648500982; 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=IYoDp95K f5AkZK/kNSpMNKrYRw/XdJTSQgFZZ65i8x4=; b=cYfD4PH//9DcMo4l1i157a5H QDHR9crHkoXXhyS0RibUi6RSYgyrsgkJD8xQNqH36doCb0c1ffPO7OFjvFXXLsmu 9ffWxMrG6OjJ6SgaXNDtRt8tiBL/RpTV3o4GJsAPLWu/UnggNK1Qs0w45QNPb1ZZ vQ3ApG9AIthGr99xrtY=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 21 Mar 2022 21:56:22 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 21 Mar 2022 21:56:21 +0100
Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000827848.msg for <v6ops@ietf.org>; Mon, 21 Mar 2022 21:56:20 +0100
X-MDRemoteIP: 2001:470:1f09:495:752e:994e:145a:d5d8
X-MDHelo: [10.10.10.144]
X-MDArrival-Date: Mon, 21 Mar 2022 21:56:20 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1079dad7ec=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.60.22022702
Date: Mon, 21 Mar 2022 21:56:19 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Ops WG <v6ops@ietf.org>
Message-ID: <AD68DD0F-0F4E-4831-B9B0-B1770B669E48@consulintel.es>
Thread-Topic: [v6ops] Thoughts about wider operational input
References: <BE3310F7-692C-46E9-A75B-07C4C3C6476F@gmail.com>
In-Reply-To: <BE3310F7-692C-46E9-A75B-07C4C3C6476F@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/IeX-enz_K-DrjjiCmJdPsTJcDw0>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 21 Mar 2022 20:56:34 -0000

Hi Fred, all,

I've thought about this many times, and I've myself confronted views:
1) Enterprises will come on-board when they really need it and start feeling the pressure, same as ISPs did/are doing.
2) We've failed with enterprises, as we are missing a better solution for multihoming.

No need to explain 1.

Of course, 2 only apply to certain "size" of enterprises. For example, SMEs that don't require multihoming or don't need to expose their internal services to "outside", could just survive with whatever prefix is assigned by the ISP, even if is not persistent, or even they can get assigned a PI from the relevant RIR and agree with their ISP to route it, so no need for BGP.

However, many organizations that today already use multihoming but still don't do BGP, definitively will require a PI prefix and they will need to have their own BGP router (very expensive, complex, lack of trained staff, etc.), or play ugly tricks.

I don't believe the right way is conditional RAs (RFC8475), neither using the experimental NPT (RFC6296).

A definitive solution may not be just an operational issue, so perhaps outside v6ops chapter, unless we can think in a new "magic", which then can definitively improve getting the enterprises moving on faster.

Regards,
Jordi
@jordipalet
 
 

El 21/3/22, 21:33, "v6ops en nombre de Fred Baker" <v6ops-bounces@ietf.org en nombre de fredbaker.ietf@gmail.com> escribió:

    I have thought some about the discussion we had in the V6ops meeting about increasing operational input. Several suggestions were made: add a separate meeting, segregate parts of the meeting, attend the IEPG, use an interim, and so on. One thought that I had was to schedule a meeting at RIPE in May.

    None of these address what seems to me to be a core problem: ISPs are deploying, but enterprise isn’t. How do we get enterprise on board?

    Sent using a machine that autocorrects in interesting ways...
    _______________________________________________
    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.theipv6company.com
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.