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

[Loa Andersson <[e-mail]>]

Bruno,

Inline please

Den 04/09/2024 kl. 17:49, skrev [e-mail]:
> Loa, Tony,
>
>>    - legacy style hashing
> It's not clear whether the above refers to MPLS label stack hashing or hashing based on post stack header. Or both

The background is what Stewart wrote in a very early mail in this thread:

     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.

So counting (based on Stewart's text) we have

1. MNA based draft-li
2. Legacy routers looking for EL/ELI
3. older routers that just hash the stack

For me that is three ways of doing (close to) the same thing, and adding
the third new way (MNA) just complicates operaations, unless we takes step
to remove one or two of the others.

The #3 method obviously have a name that is easily misunderstood, anyone
that want to propose something, please feel free to do so.

When I called #3 "legacy style hashing", that was not the brightest 
thing I have done, but it was for hashing the stack, so if we want to 
extend it to post-stack hashing, that need to be discussed and agreed 
upon. I mean that "older routers that just hash the stack", does not do 
post- stack hashing, right? /Loa
>
> Hashing on the label stack seems endorsed by RFC 6790
> "   If a transit LSR recognizes the ELI, it MAY choose to load balance
>     solely on the following label (the EL); otherwise, it SHOULD use as
>     much of the whole label stack as feasible as keys for the load-
>     balancing function.  In any case, reserved labels MUST NOT be used as
>     keys for the load-balancing function."
>
> https://datatracker.ietf.org/doc/html/rfc6790#section-4.3
>
> Hashing based on the post stack header seems a recognized behavior, that IETF needs to work with, e.g., by RFC 8469
> https://datatracker.ietf.org/doc/html/rfc8469
>
> I'm not sure how much a BCP counts as endorsement, but RFC4928 may be a relevant pointer.
>
> I'm also not sure how much draft-ietf-mpls-1stnibble is an endorsement but it seems relevant.
> It also claims to " updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS."
>
> --Bruno
>
> -----Original Message-----
> From: Tony Li <[e-mail]> On Behalf Of Tony Li
> Sent: Tuesday, September 3, 2024 8:20 PM
> To: Loa Andersson <[e-mail]>
> Cc: mpls <[e-mail]>
> Subject: [mpls] Re: New Version Notification for draft-li-mpls-mna-entropy-03.txt
>
> --------------------------------------------------------------------------------------------------------------
> CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.
> --------------------------------------------------------------------------------------------------------------
>
>
> Loa,
>
> AFAICT, what you call ‘legacy style hashing’ was never endorsed by an RFC.  As it was never endorsed, it cannot be deprecated.
>
> 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 <[e-mail]> 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 <[e-mail]>
>>> *Sent:* 02 September 2024 08:15
>>> *To:* Tony Li <[e-mail]>
>>> *Cc:* mpls <[e-mail]>
>>> *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 <[e-mail]> 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"
>>>         <[e-mail]>
>>>
>>>         *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" <[e-mail]>, "Tony Li"
>>>         <[e-mail]>
>>>
>>>         *Reply-To: *[e-mail]
>>>
>>>         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://aut/
>>> hor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-li-mpls-mna-entropy-03&dat
>>> a=05%7C02%7Cbruno.decraene%40orange.com%7C048dabbeafef4b7d99da08dccc4
>>> 5ef0c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638609847950841985
>>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
>>> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CoJNsZ0O1IOg5Yq8sWbewSLcPpm
>>> 6cHvGZRWDCA%2B5NVY%3D&reserved=0
>>>
>>>         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 -- [e-mail]
>>>     To unsubscribe send an email to [e-mail]
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> --
>> Loa Andersson
>> Senior MPLS Expert
>> Bronze Dragon Consulting
>> [e-mail]
>> [e-mail]
>>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]