Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 31 January 2022 11:26 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 6B8833A2D32 for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 03:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ENqspqPAiSFn for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 03:26:19 -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 1046A3A2D2F for <v6ops@ietf.org>; Mon, 31 Jan 2022 03:26:19 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JnQdh67mvz67xW5; Mon, 31 Jan 2022 19:22:32 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 31 Jan 2022 12:26:14 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 31 Jan 2022 14:26:14 +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.2308.021; Mon, 31 Jan 2022 14:26:14 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
Thread-Index: AQHYFjZpmo7ciMyVgUGVpoZAFltCkqx84WmQgAARghCAAAn58A==
Date: Mon, 31 Jan 2022 11:26:14 +0000
Message-ID: <27153a1e0dd348d3bb64855ecb16fa7d@huawei.com>
References: <94961E2C-DEFE-429B-BCEC-2228472747D7@chinatelecom.cn> <FB97EF2F-5174-48A8-AC1C-230B6621F66E@gmail.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.191]
Content-Type: multipart/alternative; boundary="_000_27153a1e0dd348d3bb64855ecb16fa7dhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BJyLIhD7oC_KHZr9UNPov022agY>
Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
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, 31 Jan 2022 11:26:25 -0000
The 3rd option comes to my mind (everyone next is worse than the previous) for How to push traffic to “VPNv4aaS cross-carrier PLAT” on the Server side: Let’s push all IPv4 traffic to the PLAT bottleneck! If the destination is not on the filter as “VPNv4aaS cross-carrier PLAT” accessible then just forward it to the IPv4 Internet without any change of headers. Traffic that is possible to access inside “VPNv4aaS cross-carrier” should be translated or encapsulated. And again, I am very doubtful of acceptance. Eduard From: Vasilenko Eduard Sent: Monday, January 31, 2022 1:52 PM To: 'Fred Baker' <fredbaker.ietf@gmail.com>; 'v6ops@ietf.org' <v6ops@ietf.org> Subject: RE: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt Theoretically, this policy filtering could be moved to carriers PEs. It looks like yet another Lawful Intercept: if the destination address is in the long filter of Carrier’s prefixes supporting “VPNv4aaS cross-carrier” then forward it to “VPNv4aaS cross-carrier PLAT” (for translation or encapsulation to IPv6). I doubt that many carriers would agree to such a solution. Ed/ From: Vasilenko Eduard Sent: Monday, January 31, 2022 1:29 PM To: 'Fred Baker' <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>; v6ops@ietf.org<mailto:v6ops@ietf.org> Subject: RE: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt Hi all, Of course, it would be good to have “VPNv4aaS cross-carrier”, but … IMHO: this draft rises the bar to “impossible” because it requests cooperation (and small expenses) from owners of the legacy IPv4 servers. If such cooperation is possible then it is better to just activate IPv6 on all servers on the Internet (no need for VPNv4aaS at all). More detailed explanation: https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00 is discussing only control plane unification to IPv6-only. The Data plane still assumes Dual-Stack. It is perfectly possible. draft-xie-v6ops-reqirements-multi-domain-ipv6only is asking for IPv6-only for the cross-carrier data plane too. Consider any IPv4 session. The IPv4 source could use any VPNv4aaS technology for all IPv4 traffic – it is not a problem (well, RFC 8585 compliancy is still a huge problem for FBB, but let's assume the best). The IPv4 destination is a principal problem. It should send the traffic of some sessions to the special carrier gateway (for some sort of cross-carrier VPNv4aaS) but other sessions to IPv4 Internet. Because would be some IPv4 sources that do not participate yet in “cross-carrier VPNv4aaS”. Every owner of server resources should have some special policy forwarding (probably, on the gateway router) to split traffic properly between - A special carrier gateway (like PLAT) that would tunnel or translate (probably in IPv6) to cross-carrier VPNv4aaS - Normal IPv4 routing to the internet for Carriers that do not participate in cross-carrier VPNv4aaS This policy forwarding should be managed from Carrier’s side! The carrier should update what is reachable by “cross-carrier VPNv4aaS” and what is not. IMHO: such an additional policy forwarding requirement for legacy IPv4 servers defeats the purpose of the solution. The server owner would probably prefer to enable IPv6 than to add special functionality to the router in front of the server farm, especially in the situation when it should be updated by Carrier. The good news is that any server owner that would agree to activate policy routing managed by his carrier on the Internet gateway Could start participation in “cross-carrier VPNv4aaS“ immediately, he does not need to wait for all other server owners – they could continue to send plain IPv4 to the global IPv4 Internet. The particular Carrier would not become IPv6-only till the last one server owner would not enable Dual-Stack or install policy forwarding in front of it. Eduard From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Monday, January 31, 2022 3:06 AM To: v6ops@ietf.org<mailto:v6ops@ietf.org> Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt I’m very interested in working group comments on this. Sent from my iPad On Jan 29, 2022, at 6:37 PM, Chongfeng Xie <xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>> wrote: Hi, all, We have submitted a new draft as below. It mainly specifies requirements of multi-domain IPv6-only network from the perspective of operators. Mutli-domain herein means a network is compose of multiple ASes and serves multiple scenarios, which is a common model for large-size operators. This is only -00 draft and a start point, we are looking forward to receiving more comments and suggestions. Thank you! Best regards Chongfeng A new version of I-D, draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Name: draft-xie-v6ops-reqirements-multi-domain-ipv6only Revision: 00 Title: Requirements to multi-domain IPv6-only network Document date: 2022-01-29 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt Status: https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/ Htmlized: https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only Abstract: Dual-stack requires IPv4 and IPv6 are deployed in parallel, as it costs more to run two technologies than one. IPv6-only is considered to be the next stage of IPv6 development from dual-stack. This document specifies requirements when deploying IPv6-only in multi- domain networks. The IETF Secretariat
- [v6ops] Fwd: New Version Notification for draft-x… Chongfeng Xie
- Re: [v6ops] Fwd: New Version Notification for dra… Gyan Mishra
- Re: [v6ops] New Version Notification for draft-xi… Chongfeng Xie
- Re: [v6ops] New Version Notification for draft-xi… Fred Baker
- Re: [v6ops] New Version Notification for draft-xi… Gyan Mishra
- Re: [v6ops] New Version Notification for draft-xi… Vasilenko Eduard
- Re: [v6ops] New Version Notification for draft-xi… Vasilenko Eduard
- Re: [v6ops] New Version Notification for draft-xi… Vasilenko Eduard
- Re: [v6ops] New Version Notification for draft-xi… Chongfeng Xie
- Re: [v6ops] New Version Notification for draft-xi… Chongfeng Xie
- Re: [v6ops] Fwd: New Version Notification for dra… Giuseppe Fioccola
- Re: [v6ops] New Version Notification for draft-xi… Chongfeng Xie