Re: [v6ops] Thoughts about wider operational input

Nick Buraglio <buraglio@es.net> Mon, 28 March 2022 16:34 UTC

Return-Path: <buraglio@es.net>
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 EBBA13A1727 for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2022 09:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 (2048-bit key) header.d=es.net
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 WKJ8WxvShXMg for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2022 09:34:13 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 6DA263A171F for <v6ops@ietf.org>; Mon, 28 Mar 2022 09:34:13 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id t25so25722574lfg.7 for <v6ops@ietf.org>; Mon, 28 Mar 2022 09:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=+EcduafCU1DgxPOX8gl6/0fHkCDwY+9yed4GJhtnAE0=; b=dU2GRme399lTaZBBQzbukDTs3roQE6UThyxpPYjGFDGvO1oHWYMmED34Bxxix22abu t5KUPvUbJmEaQrO5a6rPq5H3Hrnf3tDugYOcTfzsvjGVwZkvtbvL6e1r/WE1tShtxdT3 w69MeXtKi+cQjw620flU7klbdMNNCLIN59GHmCiHkqcMKQ7Di1REQTYsYqiT7i5cml7a 9XcE1QP9pqpyfJZjkJQV5dE03StJhuBRKsilO9OeWuiWAjftyvSG/+mvbhA6UcnF0zIY gW2LmBEBmuArPybycxUMC0cvomjv5bPdtBhyeffkAhMX8A2TGR8gdL9dAt+mKTS5gASB MJzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=+EcduafCU1DgxPOX8gl6/0fHkCDwY+9yed4GJhtnAE0=; b=LvSNHd02UV9X61gefJOrjefIzzYMRVp8WCInI/8axM2P9RoFGUq/KUhVByh1vns03p Ewtnoy2gF44GLZ61k/AF81UTZgkrHFNOQAropcWm7mQVQva0Qpqo3Js4vrDGFxSc7ptU IGXeOUJeiswqq1nEGPVIQ6gIlu1jBDZxwRl5mjSGGKvcckbt8jMo7IyoS8g87dIzWi6b f5Ctn+JRbboYVYjAdQ5gx4koy47mHgKPSb8yx0srgAGRlxn+fkEXnB6Yk+RhJW9Yp96c rgeYYMzvEhCKcgkcanME0eeJYxHoGy+FYYo4b2h8doefRt4/UIdS/1eClSOgKm8TYchl QaLQ==
X-Gm-Message-State: AOAM531eZaX63GBobf3A+TAWwEo6fuCL+a7E9JM/pa84USrGBFZr7rl5 EChXPypQ/7iRw53eAOCjy3Qtm+Pas5fhE8YkvmR5v8VhZb2wz+VLuHzUkfvATCp2KJv/E7fPPHR /5AuWuj9EjMnQWNJSIuVIHOqVI1pVLhWMFAvgUM2wXmYWwxphxRN9LXwwBGpr3JFzDmqvXc5jDA TG8xEoWqc=
X-Google-Smtp-Source: ABdhPJzGrSo7tk57uszPhMGt4t4D0lZPvmpBZiZ1HcXm/RAeSbDrPeZGk7XG8sMBqD336Jea560ygWo0JVBEJZVrmXU=
X-Received: by 2002:a05:6512:1148:b0:448:39c8:89d with SMTP id m8-20020a056512114800b0044839c8089dmr20256680lfg.644.1648485250765; Mon, 28 Mar 2022 09:34:10 -0700 (PDT)
MIME-Version: 1.0
References: <BE3310F7-692C-46E9-A75B-07C4C3C6476F@gmail.com> <DM6PR14MB3178DB5E4F9560FFE0B13521D7179@DM6PR14MB3178.namprd14.prod.outlook.com> <29f35cbabc114386a1d00bf5c4054f6c@huawei.com> <DM6PR14MB3178A04B566F1D24571924F8D7199@DM6PR14MB3178.namprd14.prod.outlook.com> <1DA8D34D-3B77-4B6B-B49F-C4C200492624@in-panik.de> <36b1c1aa244f40afa05eb5e58cc62cdb@huawei.com> <DM6PR14MB3178AAF2A80CE63ED8A11C1DD71B9@DM6PR14MB3178.namprd14.prod.outlook.com>
In-Reply-To: <DM6PR14MB3178AAF2A80CE63ED8A11C1DD71B9@DM6PR14MB3178.namprd14.prod.outlook.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Mon, 28 Mar 2022 11:33:59 -0500
Message-ID: <CAM5+tA-zjL4hiL6uSTj3mUJYBAY==kuDUMynA=rCQTtmoSAmGA@mail.gmail.com>
To: "Ackermann, Michael" <mackermann=40bcbsm.com@dmarc.ietf.org>
Cc: Paolo Volpato <paolo.volpato=40huawei.com@dmarc.ietf.org>, "Philipp S. Tiesel" <phils@in-panik.de>, IPv6 Ops WG <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NvNKWWuWf4oVNYJNdFq-Fgf76X0>
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, 28 Mar 2022 16:34:19 -0000

On Fri, Mar 25, 2022 at 7:55 PM Ackermann, Michael
<MAckermann=40bcbsm.com@dmarc.ietf.org> wrote:
>
> Paolo
> Thanks for following up.
> I was intrigued by when you said "involving cloud providers may increase the representation of enterprises at IETF"    I am not sure what that means, or how this could effect enterprise attendance/representation  at IETF,  but increasing enterprise attendance/represetation at IETF is a very important topic to me (that I have had little success with to date), so you definitely have my attention.   Can you elaborate on how this might work?

Anecdotally, from my experience working through IPv6-only requirements
I am seeing significant concern and questions about cloud support for
IPv6. As noted, non-ISPs have been (and are accelerating) adoption of
cloud services. As Michael has alluded to below, the complexity of
adding multiple layers of NAT is potentially problematic as compared
to end to end IPv6. The cloud providers have (seemingly begrudgingly
in many cases) started offering both dual stack and in some cases
IPv6-only services. With my work hat on, we have been attempting to
encourage IPv6 adoption within the major cloud providers in order to
accomodate our required move to IPv6-only, but it is definitely slow
going and is a significant amount of effort. This is only half of the
conversation, though, as enterprises are very often driven by support,
so if the IPv6 pieces and parts are considered "new" or "beta" or
whatever, then they are perceived as a risk. In many cases cloud IPv6
support is not as well supported or documented within the cloud
providers, so we have that to consider. In addition, finding the
"right folks" to engage can be a challenge.

>
> As you probably know,  enterprises are doing a LOT with Clouds right now and more planned for the future.     As we move apps to the cloud,  we are finding limitations in addressing and routing.  Sometimes resulting in lack of connectivity, degraded performance, unexpected costs and other issues.  NAT's seem to be particularly problematic in certain areas with clouds.    IPv6 seems to be a good potential solution.   Currently, we are trying to find out the specifics of these issues,  with the various cloud vendors,  regarding addressing formats, limits, routing, costs and other involved operational details.   This should provide a more efficient, effective and capable ecosystem, for both the customers and the cloud vendors.   These issues are of particular significance when apps span VPCs, geographic boundaries, or even cloud vendors.
> IMHO the cloud vendors are starting to see that IPv6 would be good for them as well.  (more addresses, less NATs & other performance issues, and not to even mention the cost of acquiring more IPv4 space if we don't jointly pursue v6.

This needs to be reinforced at every opportunity. RFPs, purchase order
requirements, evaluation criteria. Money talks.

>
> So if you,  or anyone else at IETF,  can assist with either of the two subjects above,  or anything else in this space,  we (enterprises) need LOTSA help and like I said,  you very much have my attention.

It's not the most efficient, but what I have personally done is
basically a grassroots campaign - if I engage with the right people, I
refer them here. Part of what they should be interested in is scoping
and helping shephard the direction of what will likely be their future
path. I have certainly encouraged people to participate - or at least
pay attention - here and on 6man. It's a bit of a slog, but if it can
push things forward even an inch, I'll keep doing it.


>
> Thanks
>
> Mike
>
>
> -----Original Message-----
> From: Paolo Volpato <paolo.volpato=40huawei.com@dmarc.ietf.org>
> Sent: Friday, March 25, 2022 6:21 AM
> To: Philipp S. Tiesel <phils@in-panik.de>; IPv6 Ops WG <v6ops@ietf.org>
> Cc: Ackermann, Michael <MAckermann@bcbsm.com>
> Subject: RE: [v6ops] Thoughts about wider operational input
>
> [External email]
>
>
> Hi,
> Following on what you and Michael provided, I wonder if involving the cloud providers more in this domain may prove useful to increase the representativeness of enterprises in the IETF.
> In any case, if there is enough interest from the community to deal with the aspects related to IPv6 in the enterprise I would also happy to contribute.
> BR
> Paolo
>
>
> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Philipp S. Tiesel
> Sent: Thursday, March 24, 2022 1:24 PM
> To: IPv6 Ops WG <v6ops@ietf.org>
> Subject: Re: [v6ops] Thoughts about wider operational input
>
> Hi,
>
> as someone who has transitioned from academia and ISP land towards cloud and enterprise territory, I begin to realise that being representation through the vendors is a very problematic assumption. As usually ISPs have huge equipment footprints compared to enterprises, at least budget wise, it is much easier for them getting their needs addrsses at the vendors and, thus, being represented by vendors if they choose not to be present on their own.
>
> Most enterprise networks, are far less technology driven that ISPs and get far less management attention.
> For larger enterprises, a transition to IPv6 involves many internal teams to coordinate, it is more an organisational challenge than a technical challenge that is hard to drive without management attention. Pushing for IPv6 because of technological arguments won’t work – you need red flags it solves to get the necessary attention.
>
> What can the IETF do to push IPv6 in the enterprise?
> - Most effective would be to lobby to make IPv6 transition a hype topic.
>   ISP and vendor lobby and sales could help.
> - Second, actively engaging consulting firms and education them could push that too.
>   There are a bunch of very good IPv6 consultants there, but getting an IPv6 expert from
>   one of the usual large consulting companies is difficult.
> - Third, reaching out to PaaS communities like Kubernetes or Cloud Foundry could help to
>   improve the IPv6 support there and make these platforms spread the word about IPv6.
> - Last, take a look at the IaaS providers and try to engage them here.
>   IPv6 support from AWS got usable in 2021.
>   GCP is fine for PoCs, but functionality still very limited.
>   Azure's IPv6 support is IPv4 with 128bit addresses.
>
> AVE!
>   Philipp
>
> > On 24. Mar 2022, at 11:06, Ackermann, Michael <MAckermann=40bcbsm.com@dmarc.ietf.org> wrote:
> >
> > Thank you Paolo
> > Good comments IMHO.
> > This thread has gotten into topics other than what I thought Fred was asking about, so I stopped responding.
> > I agree with what you say and your ideas for moving this forward. I think this could be important and I would attempt to help in any way the WG or others would like. The warning I would provide is that it is VERY difficult to get enterprises to participate in initiatives such as this.
> >
> > Only one question I have is in regards to your statement about Enterprises are represented at IETF, directly or indirectly. My impression is that directly, not much at all. And if indirectly, means vendors, I do not see that as an effective mechanism for articulating enterprise requirements,(challenges, use cases, preferences, etc).
> > But having made both of those statements I believe that this is largely our own fault for not participating. We all have our reasons/excuses (lack of understanding, money, time, etc.), but I believe all could be addressable, if IETF is serious. I hope they are!
> >
> > Thanks again
> >
> > Mike
> >
> >
> >
> >
> > -----Original Message-----
> > From: Paolo Volpato <paolo.volpato=40huawei.com@dmarc.ietf.org>
> > Sent: Thursday, March 24, 2022 5:33 AM
> > To: Ackermann, Michael <MAckermann@bcbsm.com>; Fred Baker <fredbaker.ietf@gmail.com>; IPv6 Ops WG <v6ops@ietf.org>
> > Subject: RE: [v6ops] Thoughts about wider operational input
> >
> > [External email]
> >
> >
> > I go back to the initial question posed by Fred and discussed by Michael here below (and echoed by others in the thread).
> >
> > Personally, I agree with what Michael says and this is also one of the conclusions I would draw from the analysis done in draft-ietf-v6ops-ipv6-deployment. Enterprises, whatever we mean by that term and with the due exceptions, don't care about IPv6, unless it supports/enables their business goals.
> >
> > But I believe that enterprises are represented in the IETF, either directly or indirectly.
> > As discussed at the v6ops session on Monday, if the proposal is to listen to the people who have challenges or are even opposing to IPv6 then we can think of finding room for listening/interacting with enterprises on that. Without discussing here how and where, Fred's idea to have a meeting at the next RIPE could be a first step (and if accepted I would be happy to give support).
> >
> > I am pretty sure that the contributions we may collect as a WG could be the subject of an operational draft.
> >
> > BR
> > Paolo
> >
> >
> > -----Original Message-----
> > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Ackermann, Michael
> > Sent: Tuesday, March 22, 2022 2:13 PM
> > To: Fred Baker <fredbaker.ietf@gmail.com>; IPv6 Ops WG <v6ops@ietf.org>
> > Subject: Re: [v6ops] Thoughts about wider operational input
> >
> > Good question Fred.
> > As one of those enterprises "Dragging their heels" on IPv6, and knowing MANY others in the same state, I believe the following are the core issues:
> > 1. Lack of technical knowledge regarding IPv6 implementation and operation.
> > 2. Lack of understanding of compelling reason(s) to deploy IPv6. Both Technical and Business reasons.
> >
> > There is progress in both areas, but definitely not enough and results are slow (or worse).
> >
> > Another area that COULD be compelling is to highlight what issues may be faced if an Org stays on IPv4 only, for either the short or long term
> >
> > Any help, guidance or info regarding either of the above would be helpful and appreciated.
> >
> > The best methods for doing this is a probably a longer discussion(s), so I will not attempt to address related details in this email.
> > But I do believe this is any topic which warrants attention and would glad to contribute, if I can.
> >
> > Thanks
> >
> > Mike
> >
> >
> >
> > -----Original Message-----
> > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Fred Baker
> > Sent: Monday, March 21, 2022 4:33 PM
> > To: IPv6 Ops WG <v6ops@ietf.org>
> > Subject: [v6ops] Thoughts about wider operational input
> >
> > [External email]
> >
> >
> > 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
> >
> >
> > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
> >
> > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> >
> >
> > This message was secured by Zix(R).
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
> >
> > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> >
> >
> > This message was secured by Zix(R).
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> AVE!
>    Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
>
>
> This message was secured by Zix(R).
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops