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

"xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn> Mon, 29 March 2021 14:03 UTC

Return-Path: <xiechf@chinatelecom.cn>
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 E32B53A14F7; Mon, 29 Mar 2021 07:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 yAwkPe2BFgFK; Mon, 29 Mar 2021 07:03:54 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id CF4573A14B6; Mon, 29 Mar 2021 07:03:53 -0700 (PDT)
HMM_SOURCE_IP: 172.18.8.226:50566.179694176
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-61.149.108.93?logid-0ceef4a9179c4f3dae1a2fe4dadc0bd6 (unknown [172.18.8.226]) by chinatelecom.cn (HERMES) with SMTP id CCA0A280029; Mon, 29 Mar 2021 22:03:53 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.35]) by filter002 with ESMTP id 0ceef4a9179c4f3dae1a2fe4dadc0bd6 for fredbaker.ietf@gmail.com; Mon Mar 29 22:03:55 2021
X-Transaction-ID: 0ceef4a9179c4f3dae1a2fe4dadc0bd6
X-filter-score: filter<0>
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.35
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Mon, 29 Mar 2021 22:03:48 +0800
From: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>
To: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Cc: "draft-lmhp-v6ops-transition-comparison@ietf.org" <draft-lmhp-v6ops-transition-comparison@ietf.org>, "draft-vf-v6ops-ipv6-deployment@ietf.org" <draft-vf-v6ops-ipv6-deployment@ietf.org>
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com>, <59B5C1F7-48E4-4915-BAAC-41D8ADA29E8F@gmail.com>, <18ea74665936408bb33f20630da95311@huawei.com>, <E0757B36-8FFB-43A8-8F8B-A7F152F81156@gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.20.273[cn]
Mime-Version: 1.0
Message-ID: <202103292203478620919@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart266005468842_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/33i1KTyMLC6KOX2y18uNADpuS68>
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 14:03:59 -0000


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. 

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.

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.

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.

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.

         "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."

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."

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.

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 


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