[mpls] Re: 答复: Re: 答复: Working Group Adoption Poll on draft-li-mpls-mna-entropy

[Loa Andersson <[e-mail]>]

Aijun,

I think you are right.

There might be some marginal operational benefits with synergy between 
operation between of several MNA solutions. But for that to be true a 
substantial penetration is needed,we simply don't see that.

Swapping from an EL/ELI based solution to a MNA based, does not create 
that penetration.

Also swapping from the EL/ELI based solution to the MNA based, does not 
come without cost.

I think the MNA entropy draft might be processed once we have sufficient 
MNA deployment, and enough implementation experience.

/Loa

Den 12/10/2024 kl. 09:41, skrev Aijun Wang:
> Hi, Greg:
> 
> As you said, would you like to clarify that how the proposal in this 
> draft “elaborate on how use of MNA enables more efficient realization 
> compared to other methods.”, when compared with the existing entropy 
> label that defined in RFC6790?
> 
> And, in this draft, the author state clearly that “This document adds an 
> alternative encoding that may be more efficient if other MNA actions are 
> in use.”, that is to say, there is no distinct advantage when using it 
> independently for entropy action.
> 
> My attitude is that we should postpone the adoption of this draft, and 
> focus the WG’s energy on other key use cases, for example that listed in 
> draft-ietf-mpls-mna-usecases <https://datatracker.ietf.org/doc/draft- 
> ietf-mpls-mna-usecases/>.
> 
> There is already the implementation and deployment of RFC 6790, and they 
> can coexist with MNA based solutions(for other scenarios), why devote 
> the energy to this standardization that has trivial influence of the 
> overall network operation performance?
> 
> Best Regards
> 
> Aijun Wang
> 
> China Telecom
> 
> *发件人:*Greg Mirsky [mailto:[e-mail]]
> *发送时间:*2024年10月12日4:42
> *收件人:*Aijun Wang <[e-mail]>
> *抄送:*Joel Halpern <[e-mail]>; [e-mail]
> *主题:*Re: [mpls] Re: 答复: Working Group Adoption Poll on draft-li- 
> mpls-mna-entropy
> 
> Hi Aijun,
> 
> could you please clarify which criteria you consider when determining 
> whether a particular case is "the key use case for the MNA based solution"?
> 
> In the course of the WG discussion of draft-ietf-mpls-mna-usecases 
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>, as I 
> understand it, it was agreed to progress the draft with current content 
> while new cases that use MNA would elaborate on how use of MNA enables 
> more efficient realization compared to other methods. In my opinion, 
> this draft is useful for cases that also use MNA solution, e.g., Network 
> Resource Partition Selector (which is listed in draft-ietf-mpls-mna- 
> usecases <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>).
> 
> Regards,
> 
> Greg
> 
> On Fri, Oct 11, 2024 at 7:07 AM Aijun Wang <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi, Joel:
> 
>     What’s my main concern is that the entropy function is not the key
>     use case for the MNA based solution, there is also no any mention of
>     such use case in https://datatracker.ietf.org/doc/html/draft-ietf-
>     mpls-mna-usecases-15 <https://datatracker.ietf.org/doc/html/draft-
>     ietf-mpls-mna-usecases-15>.
> 
>     What’s the reason to adopt such MNA -based solution for one non-
>     killer application(also not indispensable) to encourage the industry
>     to implement, deployment of the new MNA based forward plane?
> 
>     Aijun Wang
> 
>     China Telecom
> 
> 
> 
>         On Oct 11, 2024, at 21:38, Joel Halpern <[e-mail]
>         <mailto:[e-mail]>> wrote:
> 
>         
> 
>         It sounds like you consider that the use cases draft, which the
>         working group approved for publication, is insufficient.  If so,
>         it would have seemed appropriate for you to raise the objection
>         in the WG to that draft.  I don't recall you doing so.  Did I
>         miss it?
> 
>         Yours,
> 
>         Joel
> 
>         On 10/11/2024 4:34 AM, Aijun Wang wrote:
> 
>             Hi, Nic and WG:
> 
>             Although this draft provide one solution to implement the
>             entropy function, it is not the necessary and killer
>             application for the MNA based solution.
> 
>             If there is no other prominent function for MNA based
>             architecture, what’s the reason to design the new architecture?
> 
>             I would like the WG to focus firstly other prominent(if
>             exists) functions that can utilize/exploit the flexibility
>             of MNA based architecture.
> 
>              From the POV of the operator, there is no impetus to put
>             forward such new knob for the existing function(also
>             considering the existing MPLS entropy label can fulfill its
>             task perfectly)
> 
>             I suggest the WG to stop adopt it as the WG document, and
>             devote more energies to others fascinate proposals.
> 
>             Best Regards
> 
>             Aijun Wang
> 
>             China Telecom
> 
>             *发件人:*[e-mail]
>             <mailto:[e-mail]>
>             [mailto:[e-mail]
>             <mailto:[e-mail]>] *代表
>             *[e-mail] <mailto:[e-mail]>
>             *发送时间:*2024年10月1日22:04
>             *收件人:*[e-mail] <mailto:[e-mail]>
>             *抄送:*[e-mail] <mailto:[e-mail]>;
>             [e-mail] <mailto:draft-li-mpls-
>             [e-mail]>
>             *主题:*[mpls] Working Group Adoption Poll on draft-li-mpls-
>             mna-entropy
> 
>             Dear WG,
> 
>             This email starts a two-week poll on adopting draft-li-mpls-
>             mna-entropy as a MPLS working group document.
> 
>             Please send your comments (support/not support) to the MPLS
>             working group mailing list ([e-mail]
>             <mailto:[e-mail]>).
> 
>             Please give a technical motivation for your support/not
>             support, especially if you think that the document
> 
>             should not be adopted as a working group document.
> 
>             Currently, there are no IPR disclosure against this
>             document. All the authors/contributors have stated on
> 
>             the MPLS WG mailing list that they are unaware of any
>             undisclosed IPRs that relates to this document.
> 
>             This working group adoption poll ends October 16, 2024.
> 
>             Regards,
> 
>             Nic (as MPLS WG co-chair)
> 
>             _______________________________________________
> 
>             mpls mailing list -- [e-mail] <mailto:[e-mail]>
> 
>             To unsubscribe send an email to [e-mail]
>             <mailto:[e-mail]>
> 
>     _______________________________________________
>     mpls mailing list -- [e-mail] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail] <mailto:mpls-
>     [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]