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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 29 March 2021 17:16 UTC

Return-Path: <prvs=172215dd68=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 0B2EC3A1B5F for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 10:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 gNSzCHhoUgOK for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 10:16:07 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id B78D53A1B65 for <v6ops@ietf.org>; Mon, 29 Mar 2021 10:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1617038152; x=1617642952; 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; bh=n0ZCvVnAhA4hZaFf8tTHvoMl2Gfo55h+EV SYszzbz2w=; b=iBkLrEhlRsV+rWapeGeBUYe9yZfQ9QfBdAsEUCXJAaXrq2IZYx QaDxsKEXkhaleDMOgmDEsZvXamxqeR0r06MuXiXl5AYGnbNFCH/KWcL1r/rc373K i5NL+HLQL2mWRySsb5huWGGPcyQ0z4kMsySjietLlgDOwVx50swgy14aM=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 29 Mar 2021 19:15:52 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 29 Mar 2021 19:15:49 +0200
Received: from [10.10.10.145] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000560285.msg for <v6ops@ietf.org>; Mon, 29 Mar 2021 19:15:49 +0200
X-MDRemoteIP: 2001:470:1f09:495:51bc:4bc3:1db:56d2
X-MDHelo: [10.10.10.145]
X-MDArrival-Date: Mon, 29 Mar 2021 19:15:49 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=172215dd68=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.47.21031401
Date: Mon, 29 Mar 2021 19:15:46 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <632078E0-50ED-4227-BC4C-4A099CCCB107@consulintel.es>
Thread-Topic: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment
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>
In-Reply-To: <c9bb235695594a82a32a704300ccf0d4@huawei.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3699890146_619372201"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/671NhVfnM1f1IWABIUoJgsvggY4>
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: Mon, 29 Mar 2021 17:16:13 -0000

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 en nombre de 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] 
Sent: Monday, March 29, 2021 4:04 PM
To: Fred Baker <fredbaker.ietf@gmail.com>; v6ops@ietf.org
Cc: draft-lmhp-v6ops-transition-comparison@ietf.org; 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

Date: 2021-03-27 12:58

To: v6ops@ietf.org

CC: draft-lmhp-v6ops-transition-comparison@ietf.org; 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> 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 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.