Re: [mpls] 2nd Working Group Last call on draft-ietf-mpls-mna-requirements

[Igor Malyushkin <[e-mail]>]

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
>