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

Adrian Farrel <adrian@olddog.co.uk> Mon, 02 September 2024 08:20 UTC

Return-Path: <adrian@olddog.co.uk>
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 5DEC6C17C8A5 for <mpls@ietfa.amsl.com>; Mon, 2 Sep 2024 01:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
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 5Gy_TAz77NXp for <mpls@ietfa.amsl.com>; Mon, 2 Sep 2024 01:20:43 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8622FC14F5FA for <mpls@ietf.org>; Mon, 2 Sep 2024 01:20:42 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 4828KdCi011951; Mon, 2 Sep 2024 09:20:39 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 37DE44604B; Mon, 2 Sep 2024 09:20:39 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1808A4603D; Mon, 2 Sep 2024 09:20:39 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Mon, 2 Sep 2024 09:20:39 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 4828KcY7020154 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Sep 2024 09:20:38 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: '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>
In-Reply-To: <9A9F1679-120D-4E40-A34F-0476513BE2E5@gmail.com>
Date: Mon, 02 Sep 2024 09:20:37 +0100
Organization: Old Dog Consulting
Message-ID: <03cc01dafd10$fdacb830$f9062890$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03CD_01DAFD19.5F720A90"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGOzffeHxSpg+vawmPe3keXo4MNFgGGAjkcstBEnUA=
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=lAKipBftauCuOrKuJtZOA 46ImJdafNJKBHvN26Ed39o=; b=Vy3vHwjlTqHyXyOlueaeG0rWyYHxHepQEpryN +eeJ4BeDs8S1OzMbTRimJqFldrVoLODLW06FTRBWn4f4y+Tlb47QrwtUQwhlee0l 4ui3mMpf7FOpp4x8QPE1aveIISZnM658pw5ywVTy75f4XBv5vyAFiQ4FwkrJjF4p MPHdTpNy6mG4y/8+qldvX/uxr+sKKjivl8O5bgDOP/EJ3OVKiotoAxKfNcyC3evu aW0/+4KydnInQMBbnSK/aO07YHr1+BXEuKEIK24xjkBxfgQ5gKdsVF7/Nlk2WhOO a6NQ7QVnL1JEqwaW/28KfNE0w7VBCAbUMDACPBIpIifn/0y4A==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--40.420-10.0-31-10
X-imss-scan-details: No--40.420-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--40.420000-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/aYagUwgwslArbNLv1mr49aMmm586o4gCGD9O3ui1h2C3Y F7Jv3mFm1NTuvHSU9Nb+9HWhuYqJbqv1EhjVKf5XYPyK201ebhtzGpNq69FY/l4a0aNSuN1V+gp j5xgLUr5skKjVaoMzslj+0tQMojxADc2BUvrv0psLwUwfdPoXvvlSepWcgdLPiD/LcljEZHlpV2 KD2Vh7xB9Nqts0sKGSJ476U6plzdrSTJFGW0jY22zBijri5+RVNroBpCbt+GZLcvHInxh9FKAZP 1l+21PH+7QmOJudfuOUcqEAkfOLxi6J9Tt/SpAqxkszn8tNF/8t81T+vai/ZyDGLLbElle9fuxg plZyxPVtbpIUAPtFxpKn9vyWeGuEc13SxYDdtvXvdQQaH57xxgg0tb+cLiELoAoxVgRvhNtpOkp BuCb1GdDaNZpK9gNY3cXVpJpf3njIRZRfI7CCocdIMosX9xY4x287VGn6yCaqiYlNpOMcxa1SA8 yCaZPAh7w8b9AwvtUwcyw/JIpenV0ieHN50/kHKwi7MItzaY3pKYVp5Qz298C5DTEMxpeQyZPX8 JNqz0njzUu2NznfJbtCTHP7ezI2d9aHpH+lOW+4V0/u9pqUzUl3rVD3hKjhth6QveQfsqOf7y5O BAioaDba6gSbbjl+gVo1o+4QhtLHt8FegNoXIRxA1AKmVGTOCCo+lsDuynUDLr9vPVWwiMVA08S 977kgXVsEWVqYqahmYaQ4XR/HzG/M6LH3OjWrYrc32n84WHp+kAcS0i53MJxi3Y4kqpOAH0Gq6g h+ZlAJD3QdagyJ7f2T8UEMCCmoiI7lIVtyKjF9dWbpg7kae30tCKdnhB58r10pknZXGJqy5/tFZ u9S3BKyB0H2+Sg3U6baA36eiaw+Mqg+CyrtwA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: 7BDAYMQTFGVCUFM2KVRSWQRVM2MXA3RT
X-Message-ID-Hash: 7BDAYMQTFGVCUFM2KVRSWQRVM2MXA3RT
X-MailFrom: adrian@olddog.co.uk
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
Reply-To: adrian@olddog.co.uk
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/ziXvtmfjAFqaad_11W0Psz-oCBQ>
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>

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 <mailto: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 <mailto: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 <mailto:je_drake@yahoo.com> >, "Tony Li" <tony.li@tony.li <mailto:tony.li@tony.li> >

Reply-To: internet-drafts@ietf.org <mailto: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 <mailto:mpls@ietf.org> 
To unsubscribe send an email to mpls-leave@ietf.org <mailto:mpls-leave@ietf.org>