Re: [mpls] Do you care about MNA?

[Igor Malyushkin <[e-mail]>]

Hi Jie,

Please, see the inline below.

чт, 4 апр. 2024 г. в 09:49, Dongjie (Jimmy) <[e-mail]>:

> Hi Igor,
>
>
>
> Thanks for sharing your considerations on the requirements and deployments
>
>
>
> Please see some comments inline:
>
>
>
>
>
> *From:* mpls <[e-mail]> *On Behalf Of *Igor Malyushkin
> *Sent:* Wednesday, April 3, 2024 9:48 AM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Tianran Zhou <zhoutianran=[e-mail]>; mpls <
> [e-mail]>; Andrew Alston <Andrew.Alston=
> [e-mail]>; Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>;
> [e-mail]
> *Subject:* Re: [mpls] Do you care about MNA?
>
>
>
> Hi Tianran,
>
>
>
> Please, see my comments inline.
>
>
>
> ср, 3 апр. 2024 г. в 08:11, Tianran Zhou <[e-mail]>:
>
> The document LC is concluded. So I split this dedicated thread.
>
>
>
> Hi Igor,
>
>
>
> Thanks very much for your feedback. Really interesting to know your use
> case.
>
> I have some further questions.
>
>
>
> As Stewart mentioned, NFRR can be achieved with existing MPLS architecture.
>
> [IM] Sure. Currently, folks are trying to implement it on a service layer,
> like the EVPN FRR. From our point of view, it is cumbersome.
>
>
>
> [Jie] In my understanding, what Stewart mentioned is NFFRR on the LSP
> layer, which can also be achieved by giving additional semantics to MPLS
> labels. That will be only based on control plane extensions.
>
[IM] Yes, I understood Stewart's idea but never saw a proposal for any LSP
signaling technology. That's why I mentioned the service layer only.
Speaking about the LSP layer, we will need a dedicated solution for every
possible signaling technology. Despite having fewer limitations than the
service layer's approach, it is still much work. Not to mention that
vendors now are crazy to sell all kinds of SR, and they probably wouldn't
be happy to implement anything for "legacy" protocols. We've encountered
such problems already. It is not wise to develop legacy stuff, they said.

Correct me if I'm wrong, but MNA may give us a solution that is independent
of an underlying signaling protocol. If we have a solution for our current
LSP layer, we will use it without MNA. There is no blind evangelism. Still,
when MNA comes (and if it comes) we definitely will consider using its
capabilities because it gives us some flexibility.


>
> Would you accept other way to achieve NFRR or you must use MNA?
>
> [IM] As a tactical solution we may use an alternative way if and only if
> it does not depend on a service layer. At the same time, if MNA emerges,
> and gives us a framework for many possibilities (like network slicing or
> programming, that we may consider for future needs), it is more interesting
> to have a unified solution.
>
>
>
> [Jie] My reading is what you want now is a NFFRR solution on the LSP
> layer, which may or may not require MNA. Do you have urgent requirements on
> other MNA use cases (e.g. slicing, IOAM, etc.)? You mentioned the MNA
> framework gives the possibilities, while it would be better if you can also
> provide the estimated time frame for them.
>
[IM] No, we don't have other urgent requirements. About the time frame, I
can't say I fully understand your question.

>
>
> If you want to get this feature/MNA, are you going to replace existing
> devices or only upgrade software/firmware?
>
> [IM] It depends on many factors. Of course, nobody wants to replace all
> devices only to receive a single feature, and a software/firmware upgrade
> is always preferable. Nevertheless, some work with gear upgrades is always
> active. If we have the option to upgrade devices incrementally (for some
> confined parts of the network), receiving the required functionality in
> parallel, we can consider this way either.
>
>
>
> [Jie] Fully agree that the deployment and upgrade plan is something
> operators would pay much attention to, that information is also valuable to
> the vendors. If the recent requirement is just NFFRR (a single feature as
> you said), solutions with software upgrade would be preferable. If you also
> want other features in addition to NFFRR, it may be helpful to know the
> capability of the existing hardware to figure out which MNA functionalities
> require a gear upgrade, and whether they can be done incrementally.
>
[IM] I agree with you on that.

>
>
> Best regards,
>
> Jie
>
>
>
> Best,
>
> Tianran
>
>
>
> *发件人:* mpls <[e-mail]> *代表 *Igor Malyushkin
> *发送时间:* 2024年4月2日 23:24
> *收件人:* Tianran Zhou <zhoutianran=[e-mail]>
> *抄送:* mpls <[e-mail]>; Andrew Alston <Andrew.Alston=
> [e-mail]>; Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>;
> [e-mail]
> *主题:* Re: [mpls] 2nd Working Group Last call on
> draft-ietf-mpls-mna-requirements
>
>
>
> Hi Tianran,
>
>
>
> I'm obviously not Andrew, but as an operator, we are particularly
> interested in the NFRR case described
> in draft-ietf-mpls-mna-usecases (section 2.1).
> We are not going to deploy SRv6 in the near future, and we extensively use
> MPLS (not SR-like), NFRR will give us the ability to prevent temporal
> looping in case of node failures with egress protection technologies.
>
>
>
> вт, 2 апр. 2024 г. в 22:02, Tianran Zhou <zhoutianran=
> [e-mail]>:
>
> Hi Andrew,
>
>
>
> No, I did not ask who will not deploy NMA. I care about who will deploy
> NMA, and what’s the use case.
>
> I did not say IETF can only work on one solution. But I want to understand
> the value of the solution.
>
> The fact is I do not see any real user nor operator sharing the
> requirement and use case.
>
> Now I know you claim the need of MNA as an operator, which is perfect.
>
> I appreciate your input to the requirement and use case. How will you use
> MNA?
>
>
>
>
>
> Best,
>
> Tianran
>
>
>
>
>
>
>
> *发件人:* Andrew Alston <Andrew.Alston=[e-mail]>
> *发送时间:* 2024年4月2日 21:05
> *收件人:* Tianran Zhou <[e-mail]>; Tony Li <[e-mail]>;
> Adrian Farrel <[e-mail]>
> *抄送:* mpls <[e-mail]>; [e-mail];
> Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]>
> *主题:* Re: [mpls] 2nd Working Group Last call on
> draft-ietf-mpls-mna-requirements
>
>
>
> Hi Tianran,
>
>
>
> I find this email to be a little… confusing.
>
>
>
> Firstly it is very well documented that there are multiple operators that
> do not want – and will not deploy – srv6 (particularly with its
> divergence from Ipv6 standards and potential security flaws.). These
> operators are free to make a choice in technologies – and the IETF does
> not prohibit the creation of multiple solutions to the same problem.
> Indeed RFC7221 deals with competing design goals by citing
> http://dl.acm.org/ft_gateway.cfm?id=966726 – specifically it states “Helicopters
> are great, and so are submarines.  The problem is that if you try to build
> one vehicle to perform two fundamentally different jobs, you’re going to
> get a vehcile that does neither job well.”
>
>
>
> You therefore need to acknowledge that operators may have different use
> cases and different environments, and may choose to decide to use one
> technology over another.  Yes, there are times when we want a single
> solution, but at the end of the day, the operators, who are your employers
> customers, should be the ultimate determinants of what they choose to run,
> and there is no requirement in any IETF process to state that there can
> only be a single solution to a problem.
>
>
>
> Secondly, you refer to reinventing the wheel – it can be strongly argued
> that parts of SRv6 did indeed reinvent the sr-mpls wheel, while reinventing
> various other competing technologies.  By way of example, it is entirely
> possible to create L3VPN’s – and has been for years – without the use of
> SRv6.  So in this sense, you are correct that we sometimes reinvent the
> wheel – for various reasons and various purposes – and to meet operator
> requirements.  This is exactly what happened in the case of SRv6, and it is
> part and parcel of what the ietf does, to create solutions that cater to
> the needs of the internet in general, not a single vendor, not a single
> operator.  SRv6 does NOT meet the requirements of all operators, and to
> insist that it does is to disregard potential customers.
>
>
>
> You are also correct in stating that many people do not care about MNA –
> because they are quite happy with what they are running and are happy to
> continue using their currect technologies.  However, the statement seems
> predicated on the fact that everyone cares about SRv6 – let me 100%
> assure you that is not the case.  Indeed – if you watch the MSR6 BOF
> (which should be available on youtube), a particular individual from a
> large operator directly stated (slightly paraphrased) “This presentation
> is predicated on the fact that we all care about SRv6 – I am here to tell
> you we don’t” So while your statement is accurate – it is not in any way
> an argument against the adoption of MNA.
>
>
>
> I would STRONGLY suggest you read RFC7282 as well – which heavy refers to
> technical objections and even deals with a situation where one thing is
> considered a more elegant and clean solution, yet consensus is still found
> (Please see section 3 of the aforementioned RFC)
>
>
>
> In this particular case, on the specific grounds that there are operators
> who wish to have extended network functionality – but are not comfortable
> with SRv6 and do not believe in its security compromises – I fully
> support the advancement of MNA.
>
>
>
> I am curious however if you have any substantive technical issues with the
> document – that go beyond “There is something else to do this” (which as
> stated – some operators do not agree with and do not want – and will
> never run until outstanding issues have been resolved)
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
>
>
> Internal All Employees
>
> *From: *mpls <[e-mail]> on behalf of Tianran Zhou <
> zhoutianran=[e-mail]>
> *Date: *Saturday, 30 March 2024 at 03:29
> *To: *Tony Li <[e-mail]>, Adrian Farrel <[e-mail]>
> *Cc: *mpls <[e-mail]>, [e-mail] <
> [e-mail]>, Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>
> *Subject: *Re: [mpls] 2nd Working Group Last call on
> draft-ietf-mpls-mna-requirements
>
> Hi Adrian,
>
> IMO, this document still cannot address the question why the industry or
> operators need the MNA, given there is already SRv6.
> >From the very beginning, we just reinvent a wheel.
> There is no surprise many people do not care about MNA.
> I do not support.
>
> Tianran
>
> -----Original Message-----
> From: mpls [mailto:[e-mail] <[e-mail]>] On
> Behalf Of Tony Li
> Sent: Friday, March 29, 2024 11:35 PM
> To: Adrian Farrel <[e-mail]>
> Cc: mpls <[e-mail]>; [e-mail]
> Subject: Re: [mpls] 2nd Working Group Last call on
> draft-ietf-mpls-mna-requirements
>
>
> [WG chair hat: off]
>
> Looks good, ship it, modulo Greg’s comments.
>
> T
>
>
> > On Mar 21, 2024, at 8:21 AM, Adrian Farrel <[e-mail]> wrote:
> >
> > Hi all,
> >
> > I know it is IETF week and you all have other things to do (nice
> > meals, sight-seeing, combatting jet-lag), but I just wanted to remind
> > you to look at this document and make your comments about the last call.
> >
> > With last calls, silence generally means no support!
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: mpls <[e-mail]> On Behalf Of Adrian Farrel
> > Sent: 12 March 2024 16:46
> > To: 'mpls' <[e-mail]>
> > Cc: [e-mail]
> > Subject: [mpls] 2nd Working Group Last call on
> > draft-ietf-mpls-mna-requirements
> >
> > This email starts a second MPLS working group last call on
> > draft-ietf-mpls-mna-requirements.
> >
> > (You may recall that the first last call produced a lot of discussion
> > and issues that Matthew, as editor, has worked valiantly to resolve.)
> >
> > Please re-review the document (it has changed a lot since last time)
> > and express an opinion on the list.
> > - Is the document complete?
> > - Does it contain any errors?
> > - Is it ready to move forward for publication as an Informational RFC?
> >
> > There is no IPR disclosed against this document or its predecessors.
> > All authors, contributors, and active working group participants are
> > reminded of their responsibilities under BCP 79.
> >
> > This last call will run for three weeks (covering the IETF period). It
> > will end at 17.00 UTC on Tuesday 2nd April (narrowly avoiding ending
> > on 1st April and confusing us all).
> >
> > Thanks,
> > Adrian (for the MPLS chairs)
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7CAndrew.Alston%40liquidtelecom.com%7Cb97d64aadac747b8099308dc50507d32%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638473553836866595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wNHRWK%2BXX%2FYGEkpi6HOtobZ2VE808UwNI6HPskoWv7M%3D&reserved=0
> <https://www.ietf.org/mailman/listinfo/mpls>
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7CAndrew.Alston%40liquidtelecom.com%7Cb97d64aadac747b8099308dc50507d32%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638473553836873706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=39TEbGr0J4zPapoOtN2u1%2FDWSnZm2plQGFVmixEQS1g%3D&reserved=0
> <https://www.ietf.org/mailman/listinfo/mpls>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7CAndrew.Alston%40liquidtelecom.com%7Cb97d64aadac747b8099308dc50507d32%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638473553836876881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7zspvfKxxD%2FrHudXHqGZto5E%2BoRcdr5PQ4E6KXFjolI%3D&reserved=0
> <https://www.ietf.org/mailman/listinfo/mpls>
> _______________________________________________
> mpls mailing list
> [e-mail]
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7CAndrew.Alston%40liquidtelecom.com%7Cb97d64aadac747b8099308dc50507d32%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638473553836879980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e5QppspRhNVRmd%2FV%2BmYqbnG0ZZb%2F3vb2zuMZ2Nip7Bs%3D&reserved=0
> <https://www.ietf.org/mailman/listinfo/mpls>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>