IETF Logo Mail Archive

Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Sri <sriganeshkini@gmail.com> Wed, 04 May 2016 13:56 UTC

Return-Path: <sriganeshkini@gmail.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 506E212D1DF; Wed, 4 May 2016 06:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 84AJSNOld3pE; Wed, 4 May 2016 06:56:25 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168E412D1CC; Wed, 4 May 2016 06:56:25 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id x201so65729181oif.3; Wed, 04 May 2016 06:56:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rJDZSwitT+AqZiVxKK7iI/keGR+kPW/zs/vJxKw8VmQ=; b=R2ydcLFKyyt/h7fZStf5Sip5mA96J/R54/zg+k/5yE8DQbZF+T8ZPQbcxjTn64lctM RNIWXUiY3l70qpgVG4eXWISHn55d7bHo3vXZJOcwchNGckh5hCtWVO0FUzHxWjjWhPQl 5Q1RgGmRfQ6n8I43gakvZh6vqxC38qRK8aqIUBDPAfnNOneQhVNlxzcyOATX0ke/4zft gbmWwd/M8G8vf8wO51ePY42yrYxGGH65DVZjlD9eDW72ZDHLUlXaJbRc1for0zlk0AFC qxkFdMrY+37NURVNc0cJx3QLHJfMK2kVooERNPBQjjdgTeC7r1Le/MBGn9oxPW376mST dvpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rJDZSwitT+AqZiVxKK7iI/keGR+kPW/zs/vJxKw8VmQ=; b=MEMeUDT+kPAO/AysIRbo9aUPU19nndSEVNClv/Gg5df82uoZlTVrA4HN0NmX7XCyYG 3uaS2QSWhXRpFZyi+qHd8QiskqjV/POP/9L+xs0AFJv6er4H2AIJ74jNR6ZeQxqfkIu6 UEe8SxSyjibe5QNKho3BKeOCsJaOeELTbr/Qt4z3D2vBicAOVlR2ZEpI+ZKxqpP5wrk2 7fQ5cSZQMZaU1eEz2H0MXCyBqBuD9YfisOAQCRuVBv5EAuzeXwhKLNzOY5uf9nGDh5DA zJ4rg2BgOGKN/Hsg6YfAdKo7MacLGBRb/CUY7QOSv/ANl3/u/72XXy509DhMnjmKdJRF lqIw==
X-Gm-Message-State: AOPr4FX/p8dvBiXUs8nLLU7Js85p9jnz6t135ald+PsMHR9QVP7vjA4l4vf9fkomgeMeeQbnRqiXAdqeZAICqw==
X-Received: by 10.157.41.162 with SMTP id n31mr4259255otb.62.1462370184345; Wed, 04 May 2016 06:56:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Wed, 4 May 2016 06:55:54 -0700 (PDT)
In-Reply-To: <28277_1462369514_5729FCEA_28277_10459_1_978925b5-4e17-4253-ac27-564e15e3bd5a@OPEXCLILM22.corporate.adroot.infra.ftgroup>
References: <571B29F8.1060301@pi.nu> <6755_1462365901_5729EECD_6755_4861_1_53C29892C857584299CBF5D05346208A0F8956EC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9E32478DFA9976438E7A22F69B08FF921BB4735A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <28277_1462369514_5729FCEA_28277_10459_1_978925b5-4e17-4253-ac27-564e15e3bd5a@OPEXCLILM22.corporate.adroot.infra.ftgroup>
From: Sri <sriganeshkini@gmail.com>
Date: Wed, 04 May 2016 06:55:54 -0700
Message-ID: <CAOndX-uknt6QRCxWUmCCp77TJh6Yu-R=CaEHc3PRY8iqFcZspg@mail.gmail.com>
To: Bruno Decraene <bruno.decraene@orange.com>
Content-Type: multipart/alternative; boundary="001a113df6c25e447e0532049760"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/HVvkIVsqrUw58zuxgtF_8svC3Kc>
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" <draft-ietf-mpls-spring-entropy-label@tools.ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 04 May 2016 13:56:28 -0000

Hi Bruno,

On Wed, May 4, 2016 at 6:45 AM, <bruno.decraene@orange.com> wrote:

> Hi Stéphane,
>
>
>
> Thanks for the quote. I had read that sentence, and I think it could be
> made more precise.
>
> e.g.
>
> OLD: This limitation expressed in terms of the number of label stack
> entries that the LSR  can read is henceforth referred to as the Readable
> Label Depth (RLD)  capability of that LSR.
>
> NEW: This limitation expressed in terms of the number of label stack
> entries that the LSR  can read. This document defines the Readable Label
> Depth (RLD) as the number of labels that a transit LSR can read for
> load-balancing purpose.  When EL is used, both ELI and EL MUST be within
> the RLD, in order for the EL to be used during load-balancing.
>

The definition of RLD must not specify conditions on when an EL must be
used. RLD is a per LSR characteristic. Any recommendations on placing the
EL must be specified outside of the definition.


Sri

v2.23.0 | Report a Bug | By Email