[v6ops] New Version Notification for draft-xiao-v6ops-nd-deployment-guidelines-01.txt

Xipengxiao <xipengxiao@huawei.com> Wed, 16 February 2022 15:03 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 569BE3A1367 for <v6ops@ietfa.amsl.com>; Wed, 16 Feb 2022 07:03:58 -0800 (PST)
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_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 0_tg79u7Lz-4 for <v6ops@ietfa.amsl.com>; Wed, 16 Feb 2022 07:03:53 -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 09D933A1364 for <v6ops@ietf.org>; Wed, 16 Feb 2022 07:03:53 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JzLmc2r9Cz67yc1; Wed, 16 Feb 2022 23:02:56 +0800 (CST)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) 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; Wed, 16 Feb 2022 16:03:49 +0100
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.2308.021; Wed, 16 Feb 2022 16:03:49 +0100
From: Xipengxiao <xipengxiao@huawei.com>
To: IPv6 Ops WG <v6ops@ietf.org>
CC: Eduard Metz <eduard.metz@kpn.com>, Gyan Mishra <gyan.s.mishra@verizon.com>, "dthaler@microsoft.com" <dthaler@microsoft.com>, "furry13@gmail.com" <furry13@gmail.com>, "ek.ietf@gmail.com" <ek.ietf@gmail.com>, "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
Thread-Topic: New Version Notification for draft-xiao-v6ops-nd-deployment-guidelines-01.txt
Thread-Index: AQHYIz98439UvRL2iU6nRBD2EHq5BqyWOYgA
Date: Wed, 16 Feb 2022 15:03:49 +0000
Message-ID: <ab188fe8e98b42f384707afcef8cbc50@huawei.com>
References: <164502085113.24069.4978601616080071202@ietfa.amsl.com>
In-Reply-To: <164502085113.24069.4978601616080071202@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.209.49]
Content-Type: multipart/alternative; boundary="_000_ab188fe8e98b42f384707afcef8cbc50huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/svkJG1gr5-7sA0nRVMrNFOnDEio>
Subject: [v6ops] New Version Notification for draft-xiao-v6ops-nd-deployment-guidelines-01.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: Wed, 16 Feb 2022 15:03:59 -0000

Dear WG,



We have published a new version of draft-xiao-v6ops-nd-deployment-guidelines-01.txt<https://datatracker.ietf.org/doc/draft-xiao-v6ops-nd-deployment-guidelines/>.  This version addresses the comments from Dave Thaler, Nalini Elkins, Jen Linkova, Erik Kline in IETF 112.  The changes are:

  *   Changed “L3 isolation” to “subnet isolation”, to reflect more accurately what we mean
  *   Added a paragraph in Section 3.2 on IPv6/6man WG’s concern about multi-link subnet (MLSN)  to address Dave’s comment in IETF112, and added RFC4903 "Multi-Link Subnet Issues" as a reference.  This hopefully address Erik’s comment as well.
  *   Added “Many more interfaces or sub-interfaces are needed on the router” as an disadvantage for L2 isolation & subnet isolation, and an paragraph in Section 4 about its impact to the IPv6 first-hop.  This is to address Jen Linkova’s comment in IETF 112.
  *   Fixed some minor English problems

This document summarized the known Neighbor Discovery issues and solutions that are dispersed in 20+ RFCs in a single document for easy reference.  It also extracted an insight from these solutions.  We use this insight to provide some guidelines for future IPv6 first-hop deployment.  We believe it’s a useful document for the community.  Your comments will be appreciated!



On behalf of the authors,

XiPeng Xiao



-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Wednesday, February 16, 2022 3:14 PM
To: Eduard Metz <eduard.metz@kpn.com>; Gyan Mishra <gyan.s.mishra@verizon.com>; Xipengxiao <xipengxiao@huawei.com>
Subject: New Version Notification for draft-xiao-v6ops-nd-deployment-guidelines-01.txt





A new version of I-D, draft-xiao-v6ops-nd-deployment-guidelines-01.txt

has been successfully submitted by XiPeng Xiao and posted to the IETF repository.



Name:                        draft-xiao-v6ops-nd-deployment-guidelines

Revision:       01

Title:               Neighbor Discovery Protocol Deployment Guidelines

Document date:     2022-02-16

Group:                       Individual Submission

Pages:                        22

URL:            https://www.ietf.org/archive/id/draft-xiao-v6ops-nd-deployment-guidelines-01.txt

Status:         https://datatracker.ietf.org/doc/draft-xiao-v6ops-nd-deployment-guidelines/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-xiao-v6ops-nd-deployment-guidelines

Diff:           https://www.ietf.org/rfcdiff?url2=draft-xiao-v6ops-nd-deployment-guidelines-01



Abstract:

   Neighbor Discovery (ND) is an integral part of IPv6 first-hop. Due

   to limitation of certain L2 media's support to ND, a number of

   issues can happen in certain scenarios. Solutions for these issues

   have been designed. These issues and solutions are summarized in

   RFC3756, RFC6583, RFC9099.  However, there is no guideline on how to

   prevent the issues or how to select the proper solutions.



   This document analyzes the existing solutions and summarizes their

   wisdoms into an insight: isolating hosts into different L2 links or

   different L3 subnets can be effective in preventing ND issues. In

   deployment scenarios where the ND issues can occur, this prevention

   approach can be more effective than deploying the corresponding

   solutions to solve the issues. Based on this insight, a set of

   guidelines is proposed for future ND deployments. These guidelines

   describe where to isolate hosts in L2 or in subnet to prevent ND

   issues, and how to select suitable solutions for the remaining

   issues. This will likely simplify ND deployment. The impact of such

   isolation to other components of IPv6 first-hop is also analyzed.

   The impact appears small. Therefore, the guidelines will likely

   simplify the overall IPv6 first-hop deployment.









The IETF Secretariat