[mpls] Re: Fwd: New Version Notification for draft-li-mpls-mna-entropy-03.txt

Loa Andersson <loa@pi.nu> Tue, 03 September 2024 09:18 UTC

Return-Path: <loa@pi.nu>
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 40BE8C14CEFE for <mpls@ietfa.amsl.com>; Tue, 3 Sep 2024 02:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJsa-XEpx4rF for <mpls@ietfa.amsl.com>; Tue, 3 Sep 2024 02:18:47 -0700 (PDT)
Received: from srv.pi.nu (srv.pi.nu [IPv6:2a00:1a28:1410:5::1348]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF63C151065 for <mpls@ietf.org>; Tue, 3 Sep 2024 02:18:46 -0700 (PDT)
Message-ID: <dc848efb-3098-4baa-a555-0b2892778ac2@pi.nu>
Date: Tue, 03 Sep 2024 17:18:39 +0800
MIME-Version: 1.0
To: adrian@olddog.co.uk, 'Stewart Bryant' <stewart.bryant@gmail.com>, 'Tony Li' <tony.li@tony.li>
References: <C46E4867-89A7-4AAA-8C5F-515B5AA0FEFF@tony.li> <9A9F1679-120D-4E40-A34F-0476513BE2E5@gmail.com> <03cc01dafd10$fdacb830$f9062890$@olddog.co.uk>
Content-Language: sv, en-GB
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <03cc01dafd10$fdacb830$f9062890$@olddog.co.uk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: QMKSZCUPHGABBMTGVPWMGZIJ74TBLJRV
X-Message-ID-Hash: QMKSZCUPHGABBMTGVPWMGZIJ74TBLJRV
X-MailFrom: loa@pi.nu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'mpls' <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Fwd: New Version Notification for draft-li-mpls-mna-entropy-03.txt
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/028LqWaOBE1AduLos0ihiV4SP3Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Adrian,

It seem to me that Stewart talks about three ways of doing entropy

   - legacy style hashing
   - EL/ELI
   - MNA

So having three ways of doing "the same thing" is more complicated than
having two.

Having two ways of doing the same thing is more complicated that having
just one.

Would you agree to deprecate "legacy style hashing"? Understanding
"deprecate" as not including it in new implementations and not deploying
it in new networks.

/Loa

Den 02/09/2024 kl. 16:20, skrev Adrian Farrel:
>
> I think there is an “if” here. If MNA is standardised and if other MN 
> actions become common in usage, then including the entropy marker in 
> the MNA would be an efficient approach saving one LSE (the ELI) as the 
> cost of the LSE-A and LSE-B are already covered by the other uses of MNA.
>
> This **is** a benefit, but possibly not earth-shattering. But, so far, 
> we have no consensus on any MN actions.
>
> The SPL used as the ELI (7) is unlikely to be deprecated and released 
> back for reassignment any time soon as it’s use is in the field. So 
> that can’t be counted as a benefit.
>
> The other benefit (that I can see, and which is noted in the document) 
> is the reduction in complexity caused by having only one construct, 
> not two, to process.
>
> There are three choices that can be made by the ingress when there are 
> legacy routers on the path:
>
>  1. Decide that the legacy nodes shall not have access to entropy –
>     use MNA
>  2. Decide that all nodes shall have access to entropy through EL/ELI
>     – new implementations must continue to support EL/ELI, but never
>     see MNA and EL/ELI at the same time
>  3. Decide that all nodes shall have access to entropy through a mix
>     of EL/ELI and MNA – implementations find entropy where they may
>
> I believe that the document attempts to cover the case of legacy 
> routers on the path.
>
>   * It notes that EL/ELI is deployed and likely to persist.
>   * It recommends not using EL/ELI and MNA in the same packet (but
>     does not prohibit it).
>
> Cheers,
>
> Adrian
>
> *From:*Stewart Bryant <stewart.bryant@gmail.com>
> *Sent:* 02 September 2024 08:15
> *To:* Tony Li <tony.li@tony.li>
> *Cc:* mpls <mpls@ietf.org>
> *Subject:* [mpls] Re: Fwd: New Version Notification for 
> draft-li-mpls-mna-entropy-03.txt
>
> Hi Tony
>
> I am struggling to see whether this has a sufficient advantage over 
> the existing EL/ELI mechanism to justify us recommending it existence.
>
> It is obvious that this can be done, and it saves an LSE, but is that 
> sufficient justification for the complexity introduced by having two 
> mechanisms that of necessity need to co-exist?
>
> We also need to understand what happens in a legacy routers that are 
> looking for EL/ELI and older routers that just hash the stack. I think 
> they just provide less (no?) entropy.
>
> I imagine this ends with routers needing to parse for both types of 
> entropy which is not a great position to be in.
>
> Best regards
>
> Stewart
>
>
>
>     On 30 Aug 2024, at 5:26 PM, Tony Li <tony.li@tony.li> wrote:
>
>     [WG chair hat: off]
>
>     Hi,
>
>     This update addresses comments from Adrian Farrel as part of the
>     WG adoption process.
>
>     Comments and corrections are most welcome.
>
>     Thanks,
>
>     Tony
>
>
>
>         Begin forwarded message:
>
>         *From: *"internet-drafts at ietf.org"
>         <mailforwards@cloudmails.net>
>
>         *Subject: New Version Notification for
>         draft-li-mpls-mna-entropy-03.txt*
>
>         *Date: *August 30, 2024 at 9:24:05 AM PDT
>
>         *To: *"John Drake" <je_drake@yahoo.com>, "Tony Li"
>         <tony.li@tony.li>
>
>         *Reply-To: *internet-drafts@ietf.org
>
>         A new version of Internet-Draft
>         draft-li-mpls-mna-entropy-03.txt has been
>         successfully submitted by Tony Li and posted to the
>         IETF repository.
>
>         Name:     draft-li-mpls-mna-entropy
>         Revision: 03
>         Title:    MPLS Network Action for Entropy
>         Date:     2024-08-28
>         Group:    Individual Submission
>         Pages:    5
>         URL:
>         https://www.ietf.org/archive/id/draft-li-mpls-mna-entropy-03.txt
>         Status:
>         https://datatracker.ietf.org/doc/draft-li-mpls-mna-entropy/
>         HTMLized:
>         https://datatracker.ietf.org/doc/html/draft-li-mpls-mna-entropy
>         Diff:
>         https://author-tools.ietf.org/iddiff?url2=draft-li-mpls-mna-entropy-03
>
>         Abstract:
>
>           Load balancing is a powerful tool for engineering traffic
>         across a
>           network and has been successfully used in MPLS as described
>         in RFC
>           6790, "The Use of Entropy Labels in MPLS Forwarding".  With the
>           emergence of MPLS Network Actions (MNA), there is signficant
>         benefit
>           in being able to invoke the same load balancing capabilities
>         within
>           the more general MNA infrastructure.
>
>           This document describes a network action for entropy to be
>         used in
>           conjunction with "MPLS Network Action (MNA) Sub-Stack Solution".
>
>
>
>         The IETF Secretariat
>
>     _______________________________________________
>     mpls mailing list -- mpls@ietf.org
>     To unsubscribe send an email to mpls-leave@ietf.org
>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@pi.nu
loa.pi.nu.@gmail.com