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

Aijun Wang <> Sun, 24 May 2020 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0F613A0A6C; Sun, 24 May 2020 08:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MBjYS3TDgRFV; Sun, 24 May 2020 08:00:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E013C3A09DD; Sun, 24 May 2020 08:00:24 -0700 (PDT)
Received: from [] (unknown []) by (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 <>
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: <>
References: <>
Cc: rtg-ads <>, spring <>, 6man <>
In-Reply-To: <>
To: Joel Halpern Direct <>
X-Mailer: iPhone Mail (17E262)
X-HM-Tid: 0a724732e92a9373kuws542b9663c46
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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) <> wrote: