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

[Aijun Wang <[e-mail]>]

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 <[e-mail]> 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) <[e-mail]> wrote:
>>>