Re: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05

Qin Wu <bill.wu@huawei.com> Sat, 03 December 2022 15:06 UTC

Return-Path: <bill.wu@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 A2717C1522C4 for <v6ops@ietfa.amsl.com>; Sat, 3 Dec 2022 07:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haPdJpgAdDiY for <v6ops@ietfa.amsl.com>; Sat, 3 Dec 2022 07:06:02 -0800 (PST)
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 81ADEC1522C2 for <v6ops@ietf.org>; Sat, 3 Dec 2022 07:06:02 -0800 (PST)
Received: from lhrpeml500006.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NPY330T90z67JVF for <v6ops@ietf.org>; Sat, 3 Dec 2022 23:03:11 +0800 (CST)
Received: from canpemm500007.china.huawei.com (7.192.104.62) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 3 Dec 2022 15:05:59 +0000
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500007.china.huawei.com (7.192.104.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 3 Dec 2022 23:05:57 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2375.031; Sat, 3 Dec 2022 23:05:57 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05
Thread-Index: AdkHJvu2jCTY7o/fSEy7bckCgbpR8g==
Date: Sat, 03 Dec 2022 15:05:57 +0000
Message-ID: <00c02818baca42c0af17b433a8dc40a7@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_00c02818baca42c0af17b433a8dc40a7huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/scj5KfkubWqYo92sfF7X_0xx71A>
Subject: Re: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 03 Dec 2022 15:06:04 -0000

Hi, Xie and authors:
Thanks for writing this document, it is very useful guideline document which helps operators and developers understand how to migrate toward IPv6 only network while still not disrupt IPv4 service.
Here are few comments and suggestions:
Title
How about change it into Framework for IPv4 service over IPv6 only underlay network in multi-domain setting?
Abstract:
I think transfer lack accuracy, what you propose to support IPv6 bearer or IPv6 transport in the underlay
And support IPv6 as a service and IPv4 as a service simultaneously in the overlay network.
How about change it into IPv6 bearer?
Add service behind “both IPv6 and IPv4 (usually known as IPv4aaS).”

I don’t think we should emphasize security consideration sine security consideration is MUST for every IETF documents.

Section 2, definition of IPv6 only network
s/multi-domain IPv6-only network: An IPv6-only network which consists / multi-domain IPv6-only network: An IPv6-only underlay network which consists

Section 2
The short names of ASBR, AFBR, ADPT need to be expanded? E.g., AFBR is short name of Address Family Border Router

Section 4:
For multi-domain network, should we add reference to RFC8299, RFC8466? I think these two RFCs are most relevant one which have already considered both IPv4 and IPv6 support.

s/transporation/transport

Section 5:
I am wondering whether requirements should be separated from this framework document as independent I-D? or maybe change requirements into principles?

Section 7
I believe Ipv4 delivery from ingress PE to egress PE is related to PE based VPN while IPv4 delivery from UE/CPE to egress PE is more related to CE based VPN or SD-WAN
For IPv6 data path from Ingress PE to Egress PE, Can this IPv6 Data Path IPSEC tunnel or there are multiple random paths between Ingress PE to Egress PE and each Path traverses across multiple domains and has multiple hops?
If it can be the IPSEC tunnel, I am wondering whether this tunnel will be shared by all UE/CPE who send the traffic over this data path? Would it be great to add some IPSEC example in this draft to explain this?

-Qin
发件人: v6ops [mailto:v6ops-bounces@ietf.org] 代表 Ron Bonica
发送时间: 2022年11月19日 5:54
收件人: v6ops@ietf.org
主题: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05

Folks,

This message initiates a WG call for adoption for draft-xie-v6ops-framework-md-ipv6only-underlay-05. To accommodate the American holiday, the call for adoption will end on December 9, 2022.

                                                       Ron



Juniper Business Use Only