Re: [v6ops] Thoughts about wider operational input

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 29 March 2022 15:03 UTC

Return-Path: <vasilenko.eduard@huawei.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 730203A1A14 for <v6ops@ietfa.amsl.com>; Tue, 29 Mar 2022 08:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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
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 D6jqopQTRFCt for <v6ops@ietfa.amsl.com>; Tue, 29 Mar 2022 08:03:36 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0203A1253 for <v6ops@ietf.org>; Tue, 29 Mar 2022 08:03:36 -0700 (PDT)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KSXnR73Sjz67YJk; Tue, 29 Mar 2022 23:00:59 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 29 Mar 2022 17:03:32 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 29 Mar 2022 18:03:32 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Tue, 29 Mar 2022 18:03:32 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Paolo Volpato <paolo.volpato=40huawei.com@dmarc.ietf.org>, "buraglio@es.net" <buraglio@es.net>, "Ackermann, Michael" <mackermann@bcbsm.com>
CC: "Philipp S. Tiesel" <phils@in-panik.de>, IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: [v6ops] Thoughts about wider operational input
Thread-Index: AQHYPWL+5ay9cZSrXUWG+DzsIaGQi6zLL/EAgALnPICAAAlQgIAAJqCAgAFv3YCAAPRUAIAEKuGAgAF1zQCAADPzIA==
Date: Tue, 29 Mar 2022 15:03:32 +0000
Message-ID: <bd9bf578d6b243c9841b6d1182ee0e3e@huawei.com>
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> <CAM5+tA-zjL4hiL6uSTj3mUJYBAY==kuDUMynA=rCQTtmoSAmGA@mail.gmail.com> <bdd02e1bc8f5468ea4501f071a9e95a7@huawei.com>
In-Reply-To: <bdd02e1bc8f5468ea4501f071a9e95a7@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.190.210]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/97NpBmIYTkyH4omfs_uGLGC7CU8>
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: Tue, 29 Mar 2022 15:03:43 -0000

A few years ago there was a Hype "Hybrid Cloud" (that accelerated Microsoft so much as the most successful on this topic),
Where Enterprise is totally dependent on the technology of the particular cloud provider.
Current heavy push in the US on all Cloud providers to become IPv6-only
Would almost automatically change the IP type of hybrid-dependent Enterprises.
Good sign at the end of the tunnel. I hope it is not the train.
Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Paolo Volpato
Sent: Tuesday, March 29, 2022 5:52 PM
To: buraglio@es.net; Ackermann, Michael <mackermann@bcbsm.com>
Cc: Philipp S. Tiesel <phils@in-panik.de>; IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Thoughts about wider operational input

The cloudification process puts anyway the cloud providers in a position that allows them to influence the choices of an enterprise.
I know I am probably simplifying the problem but in many cases it's likely that enterprises base their decision whether to use a cloudified service just considering the economic side without looking that much at its technical aspects. 
Cloud providers have the scale to take in consideration also the technical aspect in their equation when defining a service.
Most of them have adopted (or are adopting) IPv6 to solve the addressing issues in their DCs and some have started to offer IPv6-based services. I think they have the experience to deal with IPv6 and discuss its benefits.
I agree that, being based on a bottom-up approach, it is a lengthy process but with their involvement in explaining the advantages of IPv6 would be useful to change the enterprises' attitude.
As Nick suggested, I also see a role for them to contribute in defining an evolution path to IPv6. I see this something that can be addressed in the IETF. 
Hopefully this would bring to increased attention by them to the operational/support aspects mentioned below (which are a critical part of the problem).

BR
Paolo

-----Original Message-----
From: Nick Buraglio <buraglio@es.net>
Sent: Monday, March 28, 2022 6:34 PM
To: Ackermann, Michael <mackermann@bcbsm.com>
Cc: Paolo Volpato <paolo.volpato@huawei.com>; Philipp S. Tiesel <phils@in-panik.de>; IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Thoughts about wider operational input

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
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops