Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Tue, 30 March 2021 08:27 UTC

Return-Path: <giuseppe.fioccola@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 3D9903A2B3F for <v6ops@ietfa.amsl.com>; Tue, 30 Mar 2021 01:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Rce_WCkahZkQ for <v6ops@ietfa.amsl.com>; Tue, 30 Mar 2021 01:27:19 -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 C81013A2B1C for <v6ops@ietf.org>; Tue, 30 Mar 2021 01:27:18 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F8j7R1Gwzz68444; Tue, 30 Mar 2021 16:20:35 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 30 Mar 2021 10:27:17 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2106.013; Tue, 30 Mar 2021 10:27:16 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment
Thread-Index: AQHXIsXkv/dCiwCMNkqKworNQJ5cEKqbA0atgAAGQFCAAA23AIABG0HQ
Date: Tue, 30 Mar 2021 08:27:16 +0000
Message-ID: <9c8f1072f8c141c6b4742e9174ce5fca@huawei.com>
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com> <59B5C1F7-48E4-4915-BAAC-41D8ADA29E8F@gmail.com> <18ea74665936408bb33f20630da95311@huawei.com> <E0757B36-8FFB-43A8-8F8B-A7F152F81156@gmail.com> <202103292203478620919@chinatelecom.cn> <c9bb235695594a82a32a704300ccf0d4@huawei.com> <632078E0-50ED-4227-BC4C-4A099CCCB107@consulintel.es>
In-Reply-To: <632078E0-50ED-4227-BC4C-4A099CCCB107@consulintel.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.211.187]
Content-Type: multipart/alternative; boundary="_000_9c8f1072f8c141c6b4742e9174ce5fcahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OG66T0mCbpuNvk6dHYZd5YZ1bLE>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment
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, 30 Mar 2021 08:27:24 -0000

Hi Jordi,
I see your point. IPv6-only alone can be misinterpreted. It can be referred to different portions of the network, to the underlay, to the overlay (services).
So I think it is good to put order and be aligned with the terminology. In section 8.1.2 we have to distinguish between IPv6-only services (IPv4aaS) and IPv6-only network, according to draft-palet-v6ops-ipv6-only.

Regards,

Giuseppe


From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, March 29, 2021 7:16 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Regarding 8.1.2, I think that’s not correct.

Some operators may do IPv6-only at the access network only. It is a case-by-case basis.

I will try to update ASAP I’ve some free time:

https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05


Regards,
Jordi
@jordipalet



El 29/3/21 17:09, "v6ops en nombre de Giuseppe Fioccola" <v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org> en nombre de giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>> escribió:

Hi Chongfeng,
Thanks a lot for your support.
I appreciate your comments which we can address in the next version.
Please find my answers inline tagged as [GF]

Regards,

Giuseppe

From: xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn> [mailto:xiechf@chinatelecom.cn]
Sent: Monday, March 29, 2021 4:04 PM
To: Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>; v6ops@ietf.org<mailto:v6ops@ietf.org>
Cc: draft-lmhp-v6ops-transition-comparison@ietf.org<mailto:draft-lmhp-v6ops-transition-comparison@ietf.org>; draft-vf-v6ops-ipv6-deployment@ietf.org<mailto:draft-vf-v6ops-ipv6-deployment@ietf.org>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment



Hi,Giuseppe, Paolo,

This draft provide latest worldwide IPv6 status from various aspects,it is a constructive and useful document and I support its adoption. In addition, I provide some comments and personal suggestions as below,


P4.    Section 2 mentions "NAT and the address transfer to counter the IPv4 exhaustion".

It should be noted that in some cases, private address space can not provide adequate address,  it is reused in the same network which make the network even more complex, so NAT can not solve the problem of address shortage.
Since each address blocks of Internet is owned by specific owner, which is stored in routing DB for the verification of the authenticity of routing information, frequent address transfer may make the global routing unstable and even in disorder.

[GF]: Agree, it is important to highlight in this section how private 10.0.0.0/8 space (RFC1918) is not enough in some cases. Also the transfer of IPv4 addresses has also some drawbacks for the global routing as you noted.

P7,    Section 4 listed several transtion technologies, they mainly provide access to users at the edge of the network, so it better to add "for user access" when they are introdueced.

[GF]: Will do.

P8.  Section 5 illustrate about IPv6 for enterprise, IPv6 show its advantages in the case of acqiusition, when enterprise merge two networks which use IPv4 private addresses, the address space of the two networks may overlap which make the merging difficult.

[GF]: Good point. We can add this motivation for IPv6 for enterprise.

P9. "In this latter case, the service is delivered solely on IPv6." should be changed to "In this latter case, the traffic is delivered solely on IPv6, Including the traffic originated from IPv4-based nodes.

     In addition,  "6to4" should be deleted since it has been outdated in IETF.

[GF]: Will do.

P10.    In  "The CPE has only an IPv6 address at the WAN side and uses an IPv6 connection to the operator gateway, e.g"
         My understanding is that In dual-stack mode, CPE has an IPv6 address and IPv4 address simultaneously.

[GF]: Ok, I will revise this sentence.

         "when IPv6 increases to a certain limit, it would be better to switch to the IPv6-only stage." should be changed to "when IPv6 usage increases to a certain limit, it would be better to switch to the IPv6-only stage."

[GF]: There was some discussion on this statement in a related thread. We plan to extend the concept of this paragraph and we will try to better define the "limit" that could be "when IPv4 traffic is vanishingly small" or "when IPv6 usage increases to a certain limit" as you suggested. We will include some considerations about what is a reasonable limit, in particular based on the data from the mailing list discussion or that we can find looking at public statistics.

In section 8.1.2, the following clause should be added,
    "For an network operator, IPv6-only means that the whole network use IPv6 as the universal network protocol for all traffic delivery."

[GF]: Sure, Will do.

P12.  In "All MPLS services can be guaranteed in IPv6 as well through 6PE/6VPE protocols."

        It should be noted that the coverage of MPLS is limted, for instance, it does not reach into the cloud/DC generally, therefore, it can not take effect in this scenario.

[GF]: Ok, it is better to specify.

p13, I propose the following clause about IPv6 action plan should be added following the clause of  "The  Call for Comment is at [US-FR] and [US-CIO]."

     "In China, the goverment launched IPv6 action plan in 2017, which requires that networks, applications and terminal devices will fully support the adoption of IPv6 by the end of 2025."

      Reference: http://www.china.org.cn/business/2017-11/27/content_41948814.htm

[GF]: This is a very good reference about the government incentives in China. We will surely add it.

Regards
Chongfeng


From: Fred Baker<mailto:fredbaker.ietf@gmail.com>
Date: 2021-03-27 12:58
To: v6ops@ietf.org<mailto:v6ops@ietf.org>
CC: draft-lmhp-v6ops-transition-comparison@ietf.org<mailto:draft-lmhp-v6ops-transition-comparison@ietf.org>; draft-vf-v6ops-ipv6-deployment@ietf.org<mailto:draft-vf-v6ops-ipv6-deployment@ietf.org>
Subject: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment


> On Mar 19, 2021, at 1:39 AM, Paolo Volpato <paolo.volpato@huawei.com<mailto:paolo.volpato@huawei.com>> wrote:
>
> For lmhp-v6ops-transition-comparison, on behalf of the authors of draft-vf-v6ops-ipv6-deployment I can say we are in favor of the WG adoption. Not only is it a good description of the transition technologies to IPv6, but it also constitutes a basis for our draft.

OK, let me put this to the working group. We asked about adoption of draft-lmhp-v6ops-transition-comparison once before (in January 2020), and got essentially no response. It has come up on the list twice since, in July and in November. The authors of draft-vf-v6ops-ipv6-deployment would like to see it adopted. The two sets of authors are disjoint. I therefore have at least nine people that would like to see us adopt and publish it. What other folks have opinions, pro or con?

Along the same lines, are there opinions regarding the adoption of draft-vf-v6ops-ipv6-deployment?

https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22
https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22
_______________________________________________ v6ops mailing list v6ops@ietf.org<mailto: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.