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

[Greg Mirsky <[e-mail]>]

Hi Jie,
Having entropy as part of NAS, in my opinion, makes a lot of sense and
improves efficiency and useability of MNA ISD, particularly if ancillary
data are mutable. I see benefits of such option.
As to you question whether any operator explicitly asked for this option in
MNA, I don't think that this is question is relevant to the discussion.
Each vendor, working with its customers, will decide whether to implement
this option or not. We, as a group, can ensure that this option is well
defined.

Regards,
Greg

On Tue, Oct 8, 2024, 21:02 Dongjie (Jimmy) <jie.dong=
[e-mail]> wrote:

> 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:[e-mail]]
> > Sent: Thursday, October 3, 2024 3:30 PM
> > To: Stewart Bryant <[e-mail]>; Tony Li <[e-mail]>
> > Cc: mpls <[e-mail]>
> > 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 <[e-mail]> 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
> > <[e-mail]> 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
> > <[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://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 -- [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]
> > >>>>>
> > >>>
> > >>> --
> > >>> Loa Andersson
> > >>> Senior MPLS Expert
> > >>> Bronze Dragon Consulting
> > >>> [e-mail]
> > >>> [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]
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>