Re: [spring] 答复: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Aijun Wang <wangaijun@tsinghua.org.cn> Sun, 24 May 2020 15:00 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F613A0A6C; Sun, 24 May 2020 08:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MBjYS3TDgRFV; Sun, 24 May 2020 08:00:26 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E013C3A09DD; Sun, 24 May 2020 08:00:24 -0700 (PDT)
Received: from [100.50.36.230] (unknown [106.121.178.38]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 542B9663C46; Sun, 24 May 2020 23:00:18 +0800 (CST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Subject: =?utf-8?Q?Re:_[spring]_=E7=AD=94=E5=A4=8D:_CRH_is_back_to_the_SP?= =?utf-8?Q?RING_Use-Case_-_Re:_Size_of_CR_in_CRH?=
Date: Sun, 24 May 2020 23:00:17 +0800
Message-Id: <2E208583-73A5-4DA6-9E7B-C026DA20A11E@tsinghua.org.cn>
References: <734d9b94-b09d-a2db-da7a-ace58dc5e3a3@joelhalpern.com>
Cc: rtg-ads <rtg-ads@ietf.org>, spring <spring@ietf.org>, 6man <6man@ietf.org>
In-Reply-To: <734d9b94-b09d-a2db-da7a-ace58dc5e3a3@joelhalpern.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
X-Mailer: iPhone Mail (17E262)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZVktVTENJS0tKSExNSk5JS0hCWVdZKF lBSkxLS0o3V1ktWUFJV1kJDhceCFlBWTU0KTY6NyQpLjc#WQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MyI6Lgw5GjgxSi4ZGQFNLzkw SBIKC0JVSlVKTkJLSEhJT0lKSUtPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpMQ1VIQ1lXWQgBWUFITkNCNwY+
X-HM-Tid: 0a724732e92a9373kuws542b9663c46
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/snp4mCdyzk-zdv4Nz-B1WpAkGnk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 15:00:30 -0000

Hi, Joel:
No, not the two things that you mentioned. These are distributed only protocols and are difficult to differentiate the traffic in near real time.
What I worried is that CRH may not bypass the constraint of source routing mechanism(must put the segment list within every packet of the priority flow). Using it to achieve the TE may not the optimal objective. If we want to dive into the CRH related solutions, we should aim to other scenarios.

Aijun Wang
China Telecom

> On May 24, 2020, at 21:44, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
> 
> Aijun, I am not sure I properly understand your request.
> In some qys, it sounds like what you are asking for is conventional MPLS.
> In other ways, it sounds like you are asking for Ross Callon's old writeup on adjusting routing metrics to achieve traffic engineering.
> 
> Are those objections to CRH?
> Those are not even within the 6man remit.
> 
> Yours,
> Joel
> 
>> On 5/24/2020 4:16 AM, Aijun Wang wrote:
>> Hi,
>> We know the advantages of these proposals. But we also pay more attention to their deployment in large network.
>> Considering the flows that needs to be steered away the default path are often small packets, adding the path list overhead on it is not efficient. And we need to add these overhead to every packet of the flow...
>> I am wondering why we go from one extreme solution(keep state on network device) to another extreme solution(keep state on every packet)? Network device has the capability to keep state, why put these capabilities aside?
>> There are other aspects that we needs to consider, for example the SID allocation across the AS boundary, The Path MTU, the Binding SID, the complexities of different behavior based on these SIDS. All these Issues have been discussed intensely in the mail list but it seems one solution will induce another issue and formed one endless loop... ...
>> My thought is that if we depends on the central control/PCE  to accomplish the E2E QoS assurance, we should simplify the protocol, not just the number of them, but also the complexity of implementation and deployment.
>> Aijun Wang
>> China Telecom
>>>> On May 23, 2020, at 08:23, Pengshuping (Peng Shuping) <pengshuping@huawei.com> wrote:
>>>