Re: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines

Xipengxiao <xipengxiao@huawei.com> Sun, 10 July 2022 10:14 UTC

Return-Path: <xipengxiao@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 E7B1BC14F6E5 for <v6ops@ietfa.amsl.com>; Sun, 10 Jul 2022 03:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 JViA6WfT23JL for <v6ops@ietfa.amsl.com>; Sun, 10 Jul 2022 03:14:35 -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 7AD5EC14F692 for <v6ops@ietf.org>; Sun, 10 Jul 2022 03:14:34 -0700 (PDT)
Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LgjSP6Ypmz67NYP; Sun, 10 Jul 2022 18:10:13 +0800 (CST)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sun, 10 Jul 2022 12:14:32 +0200
Received: from fraeml712-chm.china.huawei.com ([10.206.15.61]) by fraeml712-chm.china.huawei.com ([10.206.15.61]) with mapi id 15.01.2375.024; Sun, 10 Jul 2022 12:14:31 +0200
From: Xipengxiao <xipengxiao@huawei.com>
To: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, "fredbaker.ietf" <fredbaker.ietf@gmail.com>, list <v6ops@ietf.org>
Thread-Topic: RE: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines
Thread-Index: AQHYiYbgp+9d0GgLS0uHU3KRl4J2mK1iSLuggAD3LHSAAAfgMIASPTS7gAHVlWA=
Date: Sun, 10 Jul 2022 10:14:31 +0000
Message-ID: <aebc03b812f74f20ad7301410a1bd8e0@huawei.com>
References: <CABKBHwfbSb3zsWqB1-_SfktSWdzU1oVWgBk1RqBborW7rMoJsg@mail.gmail.com>, <3211bc43c94a428f91893bdc8cebfc4a@huawei.com>, <2022062721255777237036@chinatelecom.cn>, <f002d9c3d04a4aaa80d2fbfb7c5d983e@huawei.com> <202207091225588208695@chinatelecom.cn>
In-Reply-To: <202207091225588208695@chinatelecom.cn>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.223.117]
Content-Type: multipart/alternative; boundary="_000_aebc03b812f74f20ad7301410a1bd8e0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/o726PObv11l8Rttx0pQ-j1xXSPM>
Subject: Re: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines
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: Sun, 10 Jul 2022 10:14:37 -0000

Hi Chongfeng,

Thank you very much for the review and comments.  I can see that we have different intention and assumptions.  So let me first state the co-authors’ intention and assumptions.

There are a large number of “ND optimization solutions”, e.g. SEND, CGA, ND Proxy, DAD Proxy, SAVI, RA-Guard, WiND, SARP, unique prefix per host, GRAND, etc, and people may not have time to keep track of all these issues and solutions.  These may lead many people to think that “ND has many issues and I don’t know them well”.  This “don’t know them well” feeling may cause reluctance for deployment. Therefore, it would be good to provide an overview so that the issues and solutions become clear.  From this angle, we want this review to be as complete as possible, to give people confidence that they don’t miss anything.  Therefore, we include some solutions that some people may feel not directly relevant, e.g. ND Mediation (or SAVI as you said).

While writing this draft, we got multiple requests to write the guidelines per scenario. I think this has pros and cons.  The pro is, if people can find their scenarios covered in the draft, then their job becomes very easy: just apply the guidelines we provide.  The con is, if people don’t find their scenarios, then this draft is not useful.  Our basic assumption is, while the IPv6 first-hop scenarios for operators are limited and clear (mainly MBB, FBB and possibly public Wi-Fi), the scenarios for enterprises are too many to enumerate.  Therefore, we chose to provide an isolation methodology instead: from strongest isolation to no isolation, and let the deployers choose the right one based on their own scenario.

With these in mind, please see my reply in line.

From: xiechf@chinatelecom.cn <xiechf@chinatelecom.cn>
Sent: Saturday, July 9, 2022 6:26 AM
To: Xipengxiao <xipengxiao@huawei.com>; fredbaker.ietf <fredbaker.ietf@gmail.com>; list <v6ops@ietf.org>
Subject: Re: RE: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines



Hi,Xipeng,

I put forward some comments after reading your draft, but it does not mean that this draft should be  revised immediately. This draft is about deployment, my personal understanding is that it is mainly for network operator or enterprise who operator their own network.

Since ND process of first-hop is usually included in other mechanisms, such as the interaction between CPE and BNG, it is usually paid less attention in network deployment. The problems caused by ND at the edge of the network are often underestimated, actually they should be given attention. This draft puts forward the idea of host isolation for this problem, which is a supplementary enhancement to the existing IPv6 deployment, the subject is valuable.

XiPeng: thanks for seeing the value.

For the illustration of issues of first-hop ND in section 2, it is recommended to be combined with the network scenarios of operators, such as mobile network, fixed network or data center network etc., and analyze of the ND problems in different scenarios, which may be more intuitive to operators.

XiPeng: I explained above why we didn’t do this.  To a large extent, we feel that operators don’t need further help.  Their scenarios are limited and clear, and 3GPP, IETF, BBF have defined the solutions clearly for them.  Our draft is written more for enterprises whose IPv6 first-hop scenarios can have many varieties.

In section 3,
-3.1 and 3.2 do not seem to have the same dimension as other parts. 3.1 and 3.2 is based on scenarios, while others focus on solutions. In addition, both 3.1 and 3.2 mention assigning an independent IPv6 address prefix to each host, but 3.3 also talks about “Unique IPv6 prefix per host”, it is ok to put this point is 3.3 from the perspective of solutions. Therefore, I propose to move 3.1 and 3.2 from this chapter to section 2, the remaining chapter focuses on the illustration of ND solutions.

XiPeng: indeed different solutions in Section 3 have different scope, but we want to review them all.  I don’t feel that we can move 3.1 & 3.2 to Section 2 as Section 2 are issues while Section 3 are solutions.

   -SAVI is mentioned in 3.10, RA guard is used to prevent fake RA messages. SAVI is mainly used to prevent fake source IP address on the access side, not to solve the problem of ND, so it is recommended not to list it here.

XiPeng: to solve spoofing issues, SAVI may be needed for ND.

4.5 describes deployment guidelines from the perspective of different schemes, I think it is better from the perspective of different deployment scenarios, for example, in the mobile network scenario, the section can give network operators guidelines how to choose different isolation methods and considerations. In addition, considering the importance of this part, it is suggested to take it as a separate chapter, such as Chapter 5.

XiPeng: 3GPP has chosen the strongest isolation method for MBB, i.e. P2P link + subnet isolation.

Section 4.6 is about the impact of host isolation mechanism on other protocols. This part does not seem to be the same dimension as other parts of section 4, and it is suggested to be a separate chapter or put into other sections.

XiPeng: Section 4.6 was indeed an independent chapter in previous versions.  But we found that its content is largely repetitive.  Because each isolation method’s disadvantages are already discussed in its applicability section and explicitly considered in the guidelines, this “Impact Section” just says the disadvantages again.  So in this version, we opt to just say that the impact (i.e. disadvantages) have already been considered.

Thank you again for your review and comments.  XiPeng

Best regards
Chongfeng


________________________________
xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>

From: Xipengxiao<mailto:xipengxiao@huawei.com>
Date: 2022-06-27 22:19
To: xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>; fredbaker.ietf<mailto:fredbaker.ietf@gmail.com>; list<mailto:v6ops@ietf.org>
Subject: RE: Re: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines
Hi Dr. Xie,

Thanks for your review and comments on the draft.   Please see my reply in line.

From: xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn> <xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>>
Sent: Monday, June 27, 2022 3:26 PM
To: Xipengxiao <xipengxiao@huawei.com<mailto:xipengxiao@huawei.com>>; fredbaker.ietf <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>; list <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: Re: Re: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines

Hi, Xipeng,

In section 5, there is the following statement,

      "MBB and FBB will end at Step 1.a: isolating hosts in L2 and in subnet, with MBBv6 as the solution with SLAAC and FBBv6 as the solution with DHCPv6, respectively;"

I have two questions,

1.       What are the fist-hop in MBB and FBB respectively? As far as I know, in FBB, the link from user terminal to the edge equipment, such as BNG, comprises two segments, the segment from user terminal to home gateway and the segment from home gateway to the BNG.  But In MBB, generally there is only one hop between user terminal and the edge of the network, such as PGW/UPF,  in some cases, the mobile user terminal may play a hotsport to provide access service to other termianls.  I think the illustration of the ND solution should be in combination with the network architecture.

XiPeng: first-hop is between the “host” and the “router”.  In MBBv6/FBBv6, the “router” is the PGW/BNG while the “host” is the UE/routed RG.  You are right that the laptop and the routed RG also form  a first-hop.  We consider it as the first-hop of the homenet.

2) The second question may be related to the first one, why MBBv6 uses SLAAC but FBBv6 use DHCPv6, for the  isolation hosts in L2 and in subnet? As far as I know, SLAAC has been widely used in FBB too, and it can allocate different prefixes for different users, so as to provide some kind of isolation.

XiPeng: you are right again. SLAAC can also be used in FBBv6, but many FBBv6 deployments use DHCP PD.

Again, we are going to post a new version this week.  Please wait and review the new version.  Thanks.

XiPeng

________________________________
xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>

From: Xipengxiao<mailto:xipengxiao=40huawei.com@dmarc.ietf.org>
Date: 2022-06-27 06:43
To: Fred Baker<mailto:fredbaker.ietf@gmail.com>; v6ops list<mailto:v6ops@ietf.org>
Subject: Re: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines
Hi folks,

We will post another new version this week.  Please wait for that.  Thank you.

XiPeng

From: v6ops <v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>> On Behalf Of Fred Baker
Sent: Sunday, June 26, 2022 8:00 PM
To: v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: [v6ops] draft-xiao-v6ops-nd-deployment-guidelines

With this email, let me invite commentary on draft-xiao-v6ops-nd-deployment-guidelines. Please read the draft and raise any issues you might have with it.