[Lsr] Comments on draft-ietf-mpls-spring-entropy-label

" 徐小虎(义先) " <xiaohu.xxh@alibaba-inc.com> Thu, 05 July 2018 03:34 UTC

Return-Path: <xiaohu.xxh@alibaba-inc.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79964130E94; Wed, 4 Jul 2018 20:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.02
X-Spam-Level:
X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com
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 ZNqcpgh28SXm; Wed, 4 Jul 2018 20:34:19 -0700 (PDT)
Received: from out0-154.mail.aliyun.com (out0-154.mail.aliyun.com [140.205.0.154]) (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 9160B130E7B; Wed, 4 Jul 2018 20:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1530761654; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=BEdnHL9Tj8ppa+S+lcON9O8sDZrMlZM56GerXng1BMI=; b=ineQ0FeP9jNT+gBwj4dmBfQ9djWOO/T4348aIHCrY9sq4Pw7pipPa4DE0ruyI/s/Erhb96rr8hp1NROAlpzVSATOwhgpleg98Yfh9Hd7W2jFLGcvksB0bqsOGAXSkoPm1Tzou7JQBMn0/fu2hr8zfLOdlVebHQz86s4BdNSpNNo=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07423; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=W4_5295521_v5ForWebDing_0A9326CA_1530758935735_o7001c8062;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5295521_v5ForWebDing_0A9326CA_1530758935735_o7001c8062]) by e02c03268.eu6 at Thu, 05 Jul 2018 11:34:11 +0800
Date: Thu, 05 Jul 2018 11:34:11 +0800
From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" <xiaohu.xxh@alibaba-inc.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "pce@ietf.org" <pce@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Reply-To: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <43768014-1ce8-43d0-9f9b-04eba6f87904.xiaohu.xxh@alibaba-inc.com>
X-Mailer: [Alimail-Mailagent revision 268][W4_5295521][v5ForWebDing][Safari]
MIME-Version: 1.0
x-aliyun-mail-creator: W4_5295521_v5ForWebDing_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA0LjUuNiAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4zIFNhZmFyaS82MDQuNS42La
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_44258_56241940_5b3d91b3_12aec5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/HZ0e-B8StPOQonOQVwqW8fKFt_s>
Subject: [Lsr] =?utf-8?q?Comments_on_draft-ietf-mpls-spring-entropy-label?=
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 03:34:22 -0000

Hi all,

I have the following comments and hope it' s not too late.

1. In fact, RFC6790 doesn't require intermediate routers to have the capability of performing EL-based load-balancing mechanism. Instead, it just provides an entropy in the MPLS packet which may be available for intermediate routers to perform load-balancing.  In contrast, the recommended approach as defined in draft-ietf-mpls-spring-entropy-label requires the ingress of a given SR-TE path to take into account the ERLD capability of all intermediate routers on that path. However, in the loose explicit route case, those intermediate routers that the explicit path traverses may change over time due to IGP convergence or there may exist multiple ECMPs from one segment towards the next segment. That would make the ELI/EI imposition decision much complex. I personally believe that the principle used in RFC6790 would make the implementation and deployment much easier and therefore should be kept.

2. It said in section 4 that "
   The Entropy Readable Label Depth (ERLD) is defined as the number of
   labels a router can both:

   a.  Read in an MPLS packet received on its incoming interface(s)
       (starting from the top of the stack).

   b.  Use in its load-balancing function.:

However, it said later that:


 To advertise an ERLD value, a SPRING router:

   o  MUST be entropy label capable and, as a consequence, MUST apply
      the dataplane procedures defined in [RFC6790].

   o  MUST be able to read an ELI/EL which is located within its ERLD
      value.

   o  MUST take into account this EL in its load-balancing function.
Why should intermediate routers be required to meet the first requirement (e.g. the ELC as defined in RFC6790 ) if they would never be used as an LSP egress?

3. Section 5 introduces the MSD concept. I wonder whether this concept is aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.

In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "

If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR draft==the Base MSD (i.e., the MSD of type 1), No?
Best regards,
Xiaohu