Re: [mpls] Warren Kumari's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

<stephane.litkowski@orange.com> Thu, 05 July 2018 23:09 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA7130E14; Thu, 5 Jul 2018 16:09:06 -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 2Dhoqh6k2QsT; Thu, 5 Jul 2018 16:09:03 -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 973F8130E13; Thu, 5 Jul 2018 16:09:02 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 41MD7d1gPsz8vsw; Fri, 6 Jul 2018 01:09:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 41MD7c6nPXz1xqB; Fri, 6 Jul 2018 01:09:00 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0399.000; Fri, 6 Jul 2018 01:09:00 +0200
From: stephane.litkowski@orange.com
To: Warren Kumari <warren@kumari.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mpls-spring-entropy-label@ietf.org" <draft-ietf-mpls-spring-entropy-label@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Loa Andersson <loa@pi.nu>, Joe Clarke <jclarke@cisco.com>
Thread-Topic: Warren Kumari's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)
Thread-Index: AQHUE8FdcxjsTQkZx0CbNINqg7u7ZaSAgOGQgAAZ9YCAAKeksA==
Date: Thu, 05 Jul 2018 23:08:59 +0000
Message-ID: <20117_1530832141_5B3EA50C_20117_94_1_9E32478DFA9976438E7A22F69B08FF924B1F01E1@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <153072742469.27345.10568037891590813544.idtracker@ietfa.amsl.com> <23533_1530791022_5B3E046E_23533_427_1_9E32478DFA9976438E7A22F69B08FF924B1EFCBA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <CAHw9_i+9t+wG7aQPgNRtzBqOgiwU2K3=PjmJY57Ts==1rPtvzA@mail.gmail.com>
In-Reply-To: <CAHw9_i+9t+wG7aQPgNRtzBqOgiwU2K3=PjmJY57Ts==1rPtvzA@mail.gmail.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_9E32478DFA9976438E7A22F69B08FF924B1F01E1OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/jZoEpxxoQ1rQ9fDZkAmTkpfBqOw>
Subject: Re: [mpls] Warren Kumari's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 23:09:07 -0000

I have added the following text:
“There may also be a case where a router has a fast switching path (handled by an ASIC or network processor) and a slow switching path (handled by a CPU) with a different ERLD for each switching path. Again, for simplicity reasons, an implementation MAY use the minimum ERLD as the ERLD value for the system.”

I have also highlighted the drawback as per Joe’s comment:
“The drawback of using a single ERLD for a system lower than the capability of one or more specific component is that it may increase the number of ELI/ELs inserted. This leads to an increase of the label stack size and may have an impact on the capability of the ingress node to push this label stack.”


From: Warren Kumari [mailto:warren@kumari.net]
Sent: Thursday, July 05, 2018 17:08
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; draft-ietf-mpls-spring-entropy-label@ietf.org; mpls@ietf.org; BRUNGARD, DEBORAH A; mpls-chairs@ietf.org; Loa Andersson; Joe Clarke
Subject: Re: Warren Kumari's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)



On Thu, Jul 5, 2018 at 7:43 AM <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> wrote:
Thanks Warren,

I agree with your comments and I will address them in the next revision.

​Thanks!​


You are right (at least from a theoretical point of view) about fast path vs slow path for ERLD. I think for this kind of switching implementation, we have several options: advertising the fast path ERLD (slow path will never be triggered), advertising the slow path ERLD (there is a possibility that slow path will be triggered for each packet), let this configurable by the user. I do not think that this fast path/slow path implementation is still popular at least for the SP router market.

​I'm fine with whatever you select, I just wanted it to be considered.​
W


-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net<mailto:warren@kumari.net>]
Sent: Wednesday, July 04, 2018 20:04
To: The IESG
Cc: draft-ietf-mpls-spring-entropy-label@ietf.org<mailto:draft-ietf-mpls-spring-entropy-label@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; db3546@att.com<mailto:db3546@att.com>; draft-ietf-mpls-spring-entropy-label@ietf.org<mailto:draft-ietf-mpls-spring-entropy-label@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; loa@pi.nu<mailto:loa@pi.nu>; mpls@ietf.org<mailto:mpls@ietf.org>; jclarke@cisco.com<mailto:jclarke@cisco.com>
Subject: Warren Kumari's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-mpls-spring-entropy-label-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this - it provides useful functionality.

Please see Joe Clarke's OpsDir review here:
https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-11-opsdir-lc-clarke-2018-06-25/
 - it mirrors comments made by a number of ADs, and also contains a significnat
number of nits (which would make the document better / more readable).

I had a question:
Section 4.  Entropy Readable Label Depth
" 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."
...
"In a distributed switching architecture, each linecard may have a different
capability in terms of ERLD."

In many cases, a device may have a different readable label depth in hardware /
fastpath than it does by punting the packet to the CPU / control plane. Perhaps
the ERLD should be defined as 'Use in its load-balancing function in the
dataplace / fast-path" (or something, this will need some wording).

I'd also like to say that I like Section 10 (Options considered) - sections
like this make a document much more satisfying (otherwise one has niggling
questions like "What didn't they do single ELs at the bottom of the stack?!") -
thank you for including it.

I also have some nits:
Section 1.  Introduction
"The hashing technique is required to perfom a per-flow load-balancing and thus
prevent packet disordering. " 1: Perform is a type 2: While 'disordering'
explains it well, 'reordering' is a much more common term, and will (I think)
cause less confusion.

"The MPLS architecture brings some challenges on the load-balancing as an LSR
(Label Switch Router) should be able to look at header fields that are beyond
the MPLS label stack." "on the load-balancing" doesn't really parse. Perhaps:
"... brings some load-balancing challenges, as..."?

Section 2.  Abbreviations and Terminology
SRGB is not defined on first use, nor it is in the Terminology section. Also,
sorting this alphabetically would be appreciated.



_________________________________________________________________________________________________________________________

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.


--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

_________________________________________________________________________________________________________________________

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.