Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <0c75dd98-652b-45b4-acb9-86bab55f4b9f@pi.nu>
Date: Thu, 3 Oct 2024 06:59:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <74DA4EB9-53CF-44FB-B15C-26DE63348F1A@tony.li>
References: <4D34C954-5D55-436B-949C-6AEC1AD57D69@tony.li>
 <DD82C15B-3CFD-4AC4-9D69-9F468CC22E6B@gmail.com>
 <0c75dd98-652b-45b4-acb9-86bab55f4b9f@pi.nu>
To: Loa Andersson <loa@pi.nu>
Message-ID-Hash: TRMOLPJARDBB54A3G6JA7ZQ7BLEQY5DT
CC: mpls <mpls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_New_Version_Notification_for_draft-li-mpls-mna-en?=
 =?utf-8?q?tropy-03=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/n5hEv2iBDe7sgzuO2U7QFVsk1rA>


[WG chair hat: off]

Hi Loa,

By this logic, we can never ever approve anything as we will always be =
waiting to find something else to deploy first.  A classic chicken and =
egg situation.

Tony


> On Oct 3, 2024, at 12:30=E2=80=AFAM, Loa Andersson - loa at pi.nu =
<mailforwards@cloudmails.net> wrote:
>=20
> Stewart, et.al.,
>=20
> Thanks, this is how I remember it also. Though I had forgotten about =
the FAT label.
>=20
> 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)?"
>=20
> If the answer is that there will be synergies with other MNA =
solutions, maybe we should wait until we see those MNA solutions =
deployed.
>=20
> /Loa
>=20
> 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=E2=80=AFPM, Tony Li <tony.li@tony.li> wrote:
>>>=20
>>> =EF=BB=BF
>>> Loa,
>>>=20
>>> Let me try to be very clear:
>>>=20
>>> 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.
>>>=20
>>> Tony
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Sep 4, 2024, at 2:18=E2=80=AFAM, Loa Andersson - loa at pi.nu =
<mailforwards@cloudmails.net> wrote:
>>>>=20
>>>> Tony,
>>>>=20
>>>>=20
>>>>> Den 04/09/2024 kl. 02:20, skrev Tony Li:
>>>>> Loa,
>>>>>=20
>>>>> AFAICT, what you call =E2=80=98legacy style hashing=E2=80=99 was =
never endorsed by an RFC.  As it was never endorsed, it cannot be =
deprecated.
>>>>=20
>>>> That is one statement - not been endorsed by any RFC. Which is =
possibly true.
>>>>=20
>>>> And one conclusion - cannot be deprecated, which I don't think is =
necessarily true.
>>>>=20
>>>> Deprecating is a nice way of phasing things that does not serve us =
well in a nice way.
>>>>=20
>>>> If we want we can do it. Even if it never were endorsed.
>>>>=20
>>>> Alternatively we could write a "considered harmful document"
>>>>=20
>>>> /Loa
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> In that light, your categorization really should be only two =
items: EL/ELI and MNA.
>>>>>=20
>>>>> Tony
>>>>>=20
>>>>>=20
>>>>>> On Sep 3, 2024, at 2:18=E2=80=AFAM, Loa Andersson - loa at pi.nu =
<mailforwards@cloudmails.net> wrote:
>>>>>>=20
>>>>>> Adrian,
>>>>>>=20
>>>>>> It seem to me that Stewart talks about three ways of doing =
entropy
>>>>>>=20
>>>>>>  - legacy style hashing
>>>>>>  - EL/ELI
>>>>>>  - MNA
>>>>>>=20
>>>>>> So having three ways of doing "the same thing" is more =
complicated than
>>>>>> having two.
>>>>>>=20
>>>>>> Having two ways of doing the same thing is more complicated that =
having
>>>>>> just one.
>>>>>>=20
>>>>>> Would you agree to deprecate "legacy style hashing"? =
Understanding
>>>>>> "deprecate" as not including it in new implementations and not =
deploying
>>>>>> it in new networks.
>>>>>>=20
>>>>>> /Loa
>>>>>>=20
>>>>>> Den 02/09/2024 kl. 16:20, skrev Adrian Farrel:
>>>>>>> I think there is an =E2=80=9Cif=E2=80=9D 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.
>>>>>>>=20
>>>>>>> This **is** a benefit, but possibly not earth-shattering. But, =
so far, we have no consensus on any MN actions.
>>>>>>>=20
>>>>>>> The SPL used as the ELI (7) is unlikely to be deprecated and =
released back for reassignment any time soon as it=E2=80=99s use is in =
the field. So that can=E2=80=99t be counted as a benefit.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> There are three choices that can be made by the ingress when =
there are legacy routers on the path:
>>>>>>>=20
>>>>>>> 1. Decide that the legacy nodes shall not have access to entropy =
=E2=80=93
>>>>>>>   use MNA
>>>>>>> 2. Decide that all nodes shall have access to entropy through =
EL/ELI
>>>>>>>   =E2=80=93 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 =E2=80=93 implementations find entropy where =
they may
>>>>>>>=20
>>>>>>> I believe that the document attempts to cover the case of legacy =
routers on the path.
>>>>>>>=20
>>>>>>> * 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).
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>>=20
>>>>>>> Adrian
>>>>>>>=20
>>>>>>> *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
>>>>>>>=20
>>>>>>> Hi Tony
>>>>>>>=20
>>>>>>> I am struggling to see whether this has a sufficient advantage =
over the existing EL/ELI mechanism to justify us recommending it =
existence.
>>>>>>>=20
>>>>>>> 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?
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> I imagine this ends with routers needing to parse for both types =
of entropy which is not a great position to be in.
>>>>>>>=20
>>>>>>> Best regards
>>>>>>>=20
>>>>>>> Stewart
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>   On 30 Aug 2024, at 5:26=E2=80=AFPM, Tony Li <tony.li@tony.li> =
wrote:
>>>>>>>=20
>>>>>>>   =EF=BB=BF[WG chair hat: off]
>>>>>>>=20
>>>>>>>   Hi,
>>>>>>>=20
>>>>>>>   This update addresses comments from Adrian Farrel as part of =
the
>>>>>>>   WG adoption process.
>>>>>>>=20
>>>>>>>   Comments and corrections are most welcome.
>>>>>>>=20
>>>>>>>   Thanks,
>>>>>>>=20
>>>>>>>   Tony
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>       Begin forwarded message:
>>>>>>>=20
>>>>>>>       *From: *"internet-drafts at ietf.org"
>>>>>>>       <mailforwards@cloudmails.net>
>>>>>>>=20
>>>>>>>       *Subject: New Version Notification for
>>>>>>>       draft-li-mpls-mna-entropy-03.txt*
>>>>>>>=20
>>>>>>>       *Date: *August 30, 2024 at 9:24:05=E2=80=AFAM PDT
>>>>>>>=20
>>>>>>>       *To: *"John Drake" <je_drake@yahoo.com>, "Tony Li"
>>>>>>>       <tony.li@tony.li>
>>>>>>>=20
>>>>>>>       *Reply-To: *internet-drafts@ietf.org
>>>>>>>=20
>>>>>>>       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.
>>>>>>>=20
>>>>>>>       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=3Ddraft-li-mpls-mna-entropy-03
>>>>>>>=20
>>>>>>>       Abstract:
>>>>>>>=20
>>>>>>>         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.
>>>>>>>=20
>>>>>>>         This document describes a network action for entropy to =
be
>>>>>>>       used in
>>>>>>>         conjunction with "MPLS Network Action (MNA) Sub-Stack =
Solution".
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>       The IETF Secretariat
>>>>>>>=20
>>>>>>>   _______________________________________________
>>>>>>>   mpls mailing list -- mpls@ietf.org
>>>>>>>   To unsubscribe send an email to mpls-leave@ietf.org
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>=20
>>>>=20
>>>> --
>>>> Loa Andersson
>>>> Senior MPLS Expert
>>>> Bronze Dragon Consulting
>>>> loa@pi.nu
>>>> loa.pi.nu.@gmail.com
>>>>=20
>>>=20
>=20
> --=20
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> loa@pi.nu
> loa.pi.nu.@gmail.com
>=20