[spring] 答复: Beyond SRv6.
Lizhenbin <lizhenbin@huawei.com> Mon, 02 September 2019 17:50 UTC
Return-Path: <lizhenbin@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9712002F for <spring@ietfa.amsl.com>; Mon, 2 Sep 2019 10:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable 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 2cQv2UrVa9cP for <spring@ietfa.amsl.com>; Mon, 2 Sep 2019 10:50:52 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723F012004E for <spring@ietf.org>; Mon, 2 Sep 2019 10:50:52 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id F075192C0E2EA954F89A for <spring@ietf.org>; Mon, 2 Sep 2019 18:50:49 +0100 (IST)
Received: from lhreml711-chm.china.huawei.com (10.201.108.62) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 2 Sep 2019 18:50:49 +0100
Received: from lhreml711-chm.china.huawei.com (10.201.108.62) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 2 Sep 2019 18:50:49 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 2 Sep 2019 18:50:49 +0100
Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.113]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0439.000; Tue, 3 Sep 2019 01:50:43 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Rob Shakir <robjs=40google.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwg4pjGTjbYQ9EuFdis3JEUL5KcYw8Wm
Date: Mon, 02 Sep 2019 17:50:42 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F696571@DGGEMM532-MBX.china.huawei.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com>
In-Reply-To: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.63.36]
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8F696571DGGEMM532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/QuVy3W-I0M6ClcGmUohIptuO4Cs>
Subject: [spring] 答复: Beyond SRv6.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 17:50:55 -0000
Hi Folks, I have explained opinions in the session meeting of IETF104. Here I would like to summarize it agian: 1. Problem Statement There are three three major concerns about SRH: 1) Path MTU: In theory it may be an issue. But as the develoment of the link layer technology, the network administrators always configure the MTU as the size of Jambo Frame (That is up to 9000B) to prevent unnecessary problems. Even without SRv6 they already do like this way. So the MTU is not a big issue in the current network. 2) Payload efficiency: According to the statistics information from CAIDA and other sources, the average packet size is above 512B. When introduce 3-5 SRv6 segment ,the decreas of payload efficiency is under control. We do not think in a short time we will need up to 10 or 10+ segments which is only theoretic or to extensively use SRv6 segment. 3) Forwarding efficiency: Huawei product already supports up to 10 layers of segments for SRv6 SRH. I believe more hardware can support enough segments in a short time which is faster than the standardization process for the new encapsulation. Besides above fact in the existing network, we can also take SR-MPLS as the example. Five years ago, people also worried about such issues. After 5 years we can learn what happens which is much less serious than what was concerned. 2. Solutions According to the analysis of the problem statement, for the possible solutions I have following suggesions: 1) The price should be low. Compressing is just optimizaiton and will not add new services. We need not introduce a new set of control plane and forwarding plane extensions which will take a long time for standardization. That is the reason why we proposed the C-SRH (https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 ). We think its price is low enough since it will not change the existing control plane of SRv6. Even so we still think Binding SID should be the first choice. It is simplest and more mature after the verication in SR-MPLS. 2) Avoid the repeated work: After a long work the solutions based on SRH is already mature. Firstly we should avoid a new set of protocol extensions. Secondly if there is concern on the size of IPv6 dataplane which may be caused by strict TE or SFC, it is uncessary to repeat work on VPN, OAM, etc. Thinking about the comming IGP/BGP/PCEP/BESS/6MAN/etc. work on the topic, in order to avoid the possible waste on the standarization effort and we already learned much from the discussion on the problem statement and requirement, we could have a draft to consolidate them as a base firstly for further discussion, then begin to do possible protocol work. Best Regards, Zhenbin (Robin) ________________________________ 发件人: spring [spring-bounces@ietf.org] 代表 Rob Shakir [robjs=40google.com@dmarc.ietf.org] 发送时间: 2019年8月5日 5:03 收件人: SPRING WG List 主题: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE. These encapsulations are past WG last call (in IESG or RFC Editor). During the SPRING WG meeting at IETF 105, two presentations were related to the reduction of the size of the SID for IPv6 dataplane: * SRv6+ / CRH -- https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04 * uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01 During the IETF week, two additional drafts have been proposed: * https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 * https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 As we expressed during the meeting, it is important for the WG to understand what the aims of additional encapsulations are. Thus, we think it is important that the WG should first get to a common understanding on the requirements for a new IPv6 data plane with a smaller SID - both from the perspective of operators that are looking to deploy these technologies, and from that of the software/hardware implementation. Therefore, we would like to solicit network operators interested in SR over the IPv6 data plane to briefly introduce their: * use case (e.g. Fast Reroute, explicit routing/TE) * forwarding performance and scaling requirements * e.g., (number of nodes, network diameter, number of SID required in max and average). For the latter, if possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would typically be different (*). * if the existing SRv6 approach is not deployable in their circumstances, details of the requirement of a different solution is required and whether this solution is needed for the short term only or for the long term. As well as deployment limitations, we would like the SPRING community to briefly describe the platform limitations that they are seeing which limit the deployment of SRv6 In particular limitations related to the number of SIDs which can be pushed and forwarded and how much the use of shorter SIDs would improve the deployments . For both of these sets of feedback if possible, please post this to the SPRING WG. If the information cannot be shared publicly, please send it directly to the chairs & AD (Martin). This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs via spring-chairs@ietf.org<mailto:spring-chairs@ietf.org> and ADs via spring-ads@ietf.org<mailto:spring-ads@ietf.org>. Thank you, -- Rob & Bruno (*) As expressed on the mailing list, a 128 bit SID can encode two instructions a node SID and an adjacency SID hence less SID may be required.
- [spring] Beyond SRv6. Rob Shakir
- Re: [spring] Beyond SRv6. Rob Shakir
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. 徐小虎(义先)
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. 徐小虎(义先)
- Re: [spring] Beyond SRv6. Yuji Kamite
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Satoru Matsushima
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Sébastien Parisot
- Re: [spring] Beyond SRv6. Dirk Steinberg
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Gaurav Dawra
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. James Guichard
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Joel M. Halpern
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Darren Dukes (ddukes)
- Re: [spring] Beyond SRv6. Voyer, Daniel
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Andrew Alston
- [spring] 答复: Beyond SRv6. Lizhenbin
- Re: [spring] Beyond SRv6. Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] Beyond SRv6. li zhenqiang
- Re: [spring] Beyond SRv6. Kamran Raza (skraza)
- Re: [spring] Beyond SRv6. Parag Kaneriya
- Re: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Reji Thomas
- Re: [spring] Beyond SRv6. Sander Steffann
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. sthaug
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Ca By
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Gyan Mishra
- [spring] 答复: Beyond SRv6.(CCDR Proposal) Aijun Wang
- Re: [spring] Beyond SRv6. 松嶋聡
- Re: [spring] Beyond SRv6. Dirk Steinberg
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Andy Smith (andsmit)
- Re: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. xiechf@chinatelecom.cn
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Bernier, Daniel
- Re: [spring] Beyond SRv6. Xiejingrong
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Bernier, Daniel
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Brian E Carpenter
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Xiejingrong
- Re: [spring] Beyond SRv6. Bernier, Daniel
- Re: [spring] Beyond SRv6. Bernier, Daniel
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Stewart Bryant
- [spring] “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Andrew Alston
- Re: [spring] “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: [spring] “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Dirk Steinberg
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Gaurav Dawra
- Re: [spring] “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Fred Baker
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Srihari Sangli
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Chengli (Cheng Li)
- Re: [spring] “SRV6+” complexity in forwarding Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Stewart Bryant
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] =?utf-8?Q?=E2=80=9CSRV6+=E2=80=9D_?=… Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra