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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 09 October 2024 04:01 UTC

Return-Path: <jie.dong@huawei.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 E87F6C1D52FA for <mpls@ietfa.amsl.com>; Tue, 8 Oct 2024 21:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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
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 0SVKrulu5zO6 for <mpls@ietfa.amsl.com>; Tue, 8 Oct 2024 21:01:37 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCCDC1D52ED for <mpls@ietf.org>; Tue, 8 Oct 2024 21:01:37 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XNfLB16mVz6K6fP; Wed, 9 Oct 2024 12:00:18 +0800 (CST)
Received: from lhrpeml100005.china.huawei.com (unknown [7.191.160.25]) by mail.maildlp.com (Postfix) with ESMTPS id 9ECDE140114; Wed, 9 Oct 2024 12:01:34 +0800 (CST)
Received: from dggpemf500009.china.huawei.com (7.185.36.50) by lhrpeml100005.china.huawei.com (7.191.160.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 9 Oct 2024 05:01:33 +0100
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf500009.china.huawei.com (7.185.36.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 9 Oct 2024 12:01:31 +0800
Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.011; Wed, 9 Oct 2024 12:01:31 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Loa Andersson <loa@pi.nu>, Stewart Bryant <stewart.bryant@gmail.com>, Tony Li <tony.li@tony.li>
Thread-Topic: [mpls] Re: New Version Notification for draft-li-mpls-mna-entropy-03.txt
Thread-Index: AQHa/i7jaE7deXAAfkGcAdb7Y9RMmrJG1GiAgABuHoCALDVUgIAA0c+AgAm2b6A=
Date: Wed, 09 Oct 2024 04:01:31 +0000
Message-ID: <640a2715f3b5483bad47f9bfe6b22042@huawei.com>
References: <4D34C954-5D55-436B-949C-6AEC1AD57D69@tony.li> <DD82C15B-3CFD-4AC4-9D69-9F468CC22E6B@gmail.com> <0c75dd98-652b-45b4-acb9-86bab55f4b9f@pi.nu>
In-Reply-To: <0c75dd98-652b-45b4-acb9-86bab55f4b9f@pi.nu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: VHK4CXFXBUJHFGT6DQEFGOE5W7RUAXI5
X-Message-ID-Hash: VHK4CXFXBUJHFGT6DQEFGOE5W7RUAXI5
X-MailFrom: jie.dong@huawei.com
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.9rc5
Precedence: list
Subject: [mpls] Re: 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/DQJwKaLyN4jfpxYVcgmxb7I_ulI>
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>

Agree with Loa and Stewart here. There are several existing mechanisms for providing entropy in MPLS, and they have been deployed in production networks. 

It is not clear whether MNA based entropy is required by any operator. 

Best regards,
Jie

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Thursday, October 3, 2024 3:30 PM
> To: Stewart Bryant <stewart.bryant@gmail.com>; Tony Li <tony.li@tony.li>
> Cc: mpls <mpls@ietf.org>
> Subject: [mpls] Re: New Version Notification for
> draft-li-mpls-mna-entropy-03.txt
> 
> Stewart, et.al.,
> 
> Thanks, this is how I remember it also. Though I had forgotten about the FAT
> label.
> 
> The question that I have not seen an answer to is "Why should we crate a
> new method (MNA-based) if we already have a well working one (ELI/EL)?"
> 
> If the answer is that there will be synergies with other MNA solutions, maybe
> we should wait until we see those MNA solutions deployed.
> 
> /Loa
> 
> Den 02/10/2024 kl. 20:59, skrev Stewart Bryant:
> > Returning to this old thread.
> >
> > Hashing the stack does not require an EL. Stack hashing was widely
> deployed, and indeed gave considerable issues with operators misECMPing
> Ethernet PWs without a control word. Entropy is derived from the VPN or
> PW label is some networks.
> >
> > I therefore think it is a method in its own right.
> >
> > However there is another widely deployed method: FAT label.
> >
> > The difference between these methods and EL is the number of labels you
> need to hash. With these methods you MUST hash as many labels as you can
> see. With EL you can optimise by having h/w to spot the ELI and do a simple
> fetch.
> >
> > Stewart
> >
> >> On 4 Sep 2024, at 4:53 PM, Tony Li <tony.li@tony.li> wrote:
> >>
> >> 
> >> Loa,
> >>
> >> Let me try to be very clear:
> >>
> >> Hashing the label stack is not a third mechanism. It is one way of
> >> extracting the entropy but still requires that EL be present in the label
> stack.  It is part of the EL/ELI mechanism.  It does not need to be
> deprecated.
> >>
> >> Tony
> >>
> >>
> >>
> >>
> >>> On Sep 4, 2024, at 2:18 AM, Loa Andersson - loa at pi.nu
> <mailforwards@cloudmails.net> wrote:
> >>>
> >>> Tony,
> >>>
> >>>
> >>>> Den 04/09/2024 kl. 02:20, skrev Tony Li:
> >>>> Loa,
> >>>>
> >>>> AFAICT, what you call ‘legacy style hashing’ was never endorsed by an
> RFC.  As it was never endorsed, it cannot be deprecated.
> >>>
> >>> That is one statement - not been endorsed by any RFC. Which is possibly
> true.
> >>>
> >>> And one conclusion - cannot be deprecated, which I don't think is
> necessarily true.
> >>>
> >>> Deprecating is a nice way of phasing things that does not serve us well in
> a nice way.
> >>>
> >>> If we want we can do it. Even if it never were endorsed.
> >>>
> >>> Alternatively we could write a "considered harmful document"
> >>>
> >>> /Loa
> >>>>
> >>>> For hashing to be effective, there must be variability in the label
> >>>> stack.  Historically, that has meant that EL/ELI was in use and that
> hashing the stack was done to extract the entropy.
> >>>>
> >>>> In that light, your categorization really should be only two items: EL/ELI
> and MNA.
> >>>>
> >>>> Tony
> >>>>
> >>>>
> >>>>> On Sep 3, 2024, at 2:18 AM, Loa Andersson - loa at pi.nu
> <mailforwards@cloudmails.net> wrote:
> >>>>>
> >>>>> 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-entro
> >>>>>> py-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
> >>>>>
> >>>
> >>> --
> >>> Loa Andersson
> >>> Senior MPLS Expert
> >>> Bronze Dragon Consulting
> >>> loa@pi.nu
> >>> loa.pi.nu.@gmail.com
> >>>
> >>
> 
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> loa@pi.nu
> loa.pi.nu.@gmail.com
> 
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org