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

<stephane.litkowski@orange.com> Thu, 05 July 2018 22:19 UTC

Return-Path: <stephane.litkowski@orange.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 9436612777C; Thu, 5 Jul 2018 15:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GvK-ush0ugCi; Thu, 5 Jul 2018 15:19:30 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3422130DD3; Thu, 5 Jul 2018 15:19:29 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 41MC2S08wBz7wQY; Fri, 6 Jul 2018 00:19:28 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 41MC2R5ywJzBrLM; Fri, 6 Jul 2018 00:19:27 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0399.000; Fri, 6 Jul 2018 00:19:27 +0200
From: <stephane.litkowski@orange.com>
To: =?utf-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?= <xiaohu.xxh@alibaba-inc.com>, "mpls@ietf.org" <mpls@ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [mpls] Comments on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHUFBEZ4EJ3HXR8sUadOhOWKPsIEqSBKPaQ
Date: Thu, 5 Jul 2018 22:19:26 +0000
Message-ID: <7608_1530829167_5B3E996F_7608_323_1_9E32478DFA9976438E7A22F69B08FF924B1F0131@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <43768014-1ce8-43d0-9f9b-04eba6f87904.xiaohu.xxh@alibaba-inc.com>
In-Reply-To: <43768014-1ce8-43d0-9f9b-04eba6f87904.xiaohu.xxh@alibaba-inc.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924B1F0131OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xHDCmnuBr0nWYAft_eJw-1YcW8w>
Subject: Re: [Lsr] [mpls] 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 22:19:33 -0000

Hi,

Thanks for your comment.
Pls find some inline replies

Brgds,

Stephane

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of ???(??)
Sent: Thursday, July 05, 2018 05:34
To: mpls@ietf.org
Cc: lsr@ietf.org; pce@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

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.

[SLI] Using SRTE and label stacking is not different from nested LSP. Each tail-end of a segment should be ELC to ensure that it can pop the ELI/EL if the ingress decides to push it. The current text does not mandate anything regarding the analysis of transit nodes. It says without using normative language that the implementation may try to find the minimum ERLD along the path. But behaving as RFC6790 is for sure simpler and is compliant.


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<https://tools.ietf.org/html/rfc6790>]0>].



   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?
[SLI] If they are pure transit for a node SID, there is no need for them to advertise the ERLD.

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?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.