Re: [Idr] On the Calculation of Entropy Labels

liu.yao71@zte.com.cn Wed, 02 June 2021 10:42 UTC

Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBF3A3E1B for <idr@ietfa.amsl.com>; Wed, 2 Jun 2021 03:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GcQJh0ODii8N for <idr@ietfa.amsl.com>; Wed, 2 Jun 2021 03:42:18 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 6E1AE3A2A81 for <idr@ietf.org>; Wed, 2 Jun 2021 03:42:17 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id D458FE61A7B63FEDD6C5 for <idr@ietf.org>; Wed, 2 Jun 2021 18:42:14 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id B578822153D5B5058CA3; Wed, 2 Jun 2021 18:42:14 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 152AeDmE012817; Wed, 2 Jun 2021 18:40:13 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Wed, 2 Jun 2021 18:40:13 +0800 (CST)
Date: Wed, 02 Jun 2021 18:40:13 +0800
X-Zmail-TransId: 2afd60b7600de8acfec9
X-Mailer: Zmail v1.0
Message-ID: <202106021840133062647@zte.com.cn>
In-Reply-To: <63e9c5834e9646bda4d0922e0326f47d@huawei.com>
References: 202103151908216203531@zte.com.cn, 63e9c5834e9646bda4d0922e0326f47d@huawei.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: lizhenbin@huawei.com
Cc: idr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 152AeDmE012817
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LGdtmtMwmiZjXWtgNnx9Ipv_c_I>
Subject: Re: [Idr] On the Calculation of Entropy Labels
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 10:42:23 -0000

Hi Robin,
Sorry for my late reply.  Please see inline.

Best Regards,
Yao


------------------原始邮件------------------
发件人:Lizhenbin
收件人:刘尧00165286;
抄送人:idr@ietf.org;
日 期 :2021年03月22日 11:35
主 题 :RE: [Idr] On the Calculation of Entropy Labels
" _ue_custom_node_="true">
Hi Yao,
Sorry for the late reply. The following information is for your reference:
1. The draft is as follows. In the presentation, we proposed the example to calculate the entropy label for the specific prefix and download the  entropy label and the VPN label together for better load sharing in the network.
https://tools.ietf.org/html/draft-li-idr-mpls-path-programming-04

Yao>> Thanks for offering the information and I've read the draft. 
2. After the IDR session om which you did the presentation, I thought there is the difference between the idea in the draft and the draft in your  draft. The draft is calculate the entropy label for the PREFIX and the idea is to calculate the entropy label position for the SR path.

Yao>> Yes, you're right. The main idea of draft-zhou-idr-bgp-srmpls-elp is that the controller calculates the entropy label position and indicates it when distributing SR Policy.
3. I am a little doubtful about the benefit of calculating the position only. I am not sure about how will the position is calculated. If the fixed  position is calculated for the SR path, but the traffic flows with different destination address will be carried by the SR path and the entropy labels is randomly calculated, can the load sharing be improved?

Yao>> As introduced in RFC6790, the ingress router computes a hash based on a given packet to get the value of entropy label.
RFC8662 implies that the controller can be used to program a label stack while leaving room for the local node to add entropy labels.
draft-zhou-idr-bgp-srmpls-elp follows the ideas in RFC6790 and RFC8662, it mainly focuses on the inter-domain scenario where the end-to-end path is calculated by the controller and the ingress LSR doesn't know the ERLD and MSD of the nodes in other domains, so the controller just calculates the placement of ELs and tells the ingress node where to insert them. And the considerations for the placement of ELs in RFC8662 are still applicable.
Other mechanisms like your draft may provide better load balancing than RFC6790, but it's out of scope of this draft.
Best Regards,
Robin


From: liu.yao71@zte.com.cn [mailto:liu.yao71@zte.com.cn]
Sent: Monday, March 15, 2021 7:08 PM
To: idr@ietf.org; Lizhenbin <lizhenbin@huawei.com>
Subject: [Idr] On the Calculation of Entropy Labels
Hi Robin,
Thanks for your comments on draft-zhou-idr-bgp-srmpls-elp at the IDR meeting last week.
You mentioned that there's a work about calculating both the vlaue and the position of the entropy labels using the controller.
(Sorry I haven't find the draft, I would appreciate it if you could offer the name of the draft.)
Since the entropy label value for each flow may be different, the control needs to calculate the value and the position of ELs per flow, and needs to maintain the state of the label stack per flow.
The solution introduced in draft-zhou-idr-bgp-srmpls-elp is that the controller calculates the position of the ELs for each path. The method for calculating the EL value  is unchanged, the ingress router computes a hash based on several fields from a given packet.
The calculation and state in the controller is per path. This method is applicable to a network with many flows and ingress nodes.
Regards,
Yao