MSA’s and network architecture
All, Why do MSA’s matter as related to network architecture? Thanks all — -M<
On Wed, May 18, 2022 at 01:59 Mark Tinka <mark@tinka.africa> wrote:
On 5/18/22 03:55, Martin Hannigan wrote:
All,
Why do MSA’s matter as related to network architecture?
As in "Master Services Agreement"?
Admittedly vague, but deliberate. Perhaps the thread answered the question. :-) Metropolitan Statistical Area.The easy answer is "its where the eyeballs are". If so, that's great and it is (was) that simple. A lot of companies are predicting where the "edge" will actually shake out and most are using MSA. It's not that simple, there are certainly other attributes, but it may be that simple. Sorting by MSA and descending population you would think it is a no-brainer. Not necessarily? So perhaps a bolt on to the question, "and what attributes influence that importance?". Thanks -- -M<
Asking good questions is much harder than answering good questions. You could have improved the quality of question here by staging what MSA is and in what context you've run into this. I am assuming MSA here is a metro statistical area, and if so, I can answer for the context of my employer, where MSA has similar functions as your region (roughly continent), country and pop. MSA is a way to discuss and name areas, between pop and country for us, not much different to city in our use. On Wed, 18 May 2022 at 04:59, Martin Hannigan <hannigan@gmail.com> wrote:
All,
Why do MSA’s matter as related to network architecture?
Thanks all —
-M<
-- ++ytti
Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :) Cheers, Etienne On Wed, May 18, 2022 at 3:59 AM Martin Hannigan <hannigan@gmail.com> wrote:
All,
Why do MSA’s matter as related to network architecture?
Thanks all —
-M<
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
We could also add an explanation to our proposals for the acronym. :) In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk. On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG <nanog@nanog.org> wrote:
Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :)
Cheers,
Etienne
On Wed, May 18, 2022 at 3:59 AM Martin Hannigan <hannigan@gmail.com> wrote:
All,
Why do MSA’s matter as related to network architecture?
Thanks all —
-M<
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
-- ++ytti
In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk.
Amen to that. Cheers, Etienne On Wed, May 18, 2022 at 8:39 AM Saku Ytti <saku@ytti.fi> wrote:
We could also add an explanation to our proposals for the acronym. :)
In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk.
On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG <nanog@nanog.org> wrote:
Just to add a bit of fun to the mix - perhaps multi-source agreement was
intended :)
Cheers,
Etienne
On Wed, May 18, 2022 at 3:59 AM Martin Hannigan <hannigan@gmail.com>
wrote:
All,
Why do MSA’s matter as related to network architecture?
Thanks all —
-M<
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
-- ++ytti
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
On 5/18/22 08:39, Saku Ytti wrote:
We could also add an explanation to our proposals for the acronym. :)
In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk.
Unless you are truly desperate and/or happy to get stuck in vendor-land, always wise to be slightly behind the curve when it comes to optics. Mark.
On Wed, 18 May 2022 at 11:35, Mark Tinka <mark@tinka.africa> wrote:
Unless you are truly desperate and/or happy to get stuck in vendor-land, always wise to be slightly behind the curve when it comes to optics.
Agreed, if possible do boring things and get boring results. Even in vendor land, a boring result is not guaranteed. Vendor had one 100GE LR4 SKU approved for their platform and it had problems performing under some conditions. Issue was with something LBW (loop bandwidth?) some optics have this at 10MHz others 20MHz, and the former does not perform with certain jitter, latter does and the former was only one approved by the vendor. Vendor addressed this by removing approval for the only version that was approved and approved another one. It was not blatantly broken, it would almost certainly work fine in your lab, as environmental conditions needed to apply. Also testing goes only so far, because vendors change suppliers and hardware all the time, without changing SKU. Cisco is the only vendor I know who has very detailed change logs of what they are doing to the SKUs with each change. Single order might contain multiple versions of the SKU and the versions may not behave the same. We recently had this problem with 3rd party optic, where a new version of SKU didn't work for us, and we had to discover it in the field and we only knew of the SKU change after the problem occurred. Of course probably more than 99 SKU changes out of 100 are invisible to end users. -- ++ytti
Considered that, but that would be obvious - we need optics :-).
Agreed - but wouldn't it be fair to say that, nonetheless, the availability of an MSA supports the development of network architecture? With an MSA, there is some limited, common basis for a discussion in an ecosystem of vendors and network operators. That should support development of architecture. Cheers, Etienne On Wed, May 18, 2022 at 10:32 AM Mark Tinka <mark@tinka.africa> wrote:
On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote:
Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :)
Considered that, but that would be obvious - we need optics :-).
Mark.
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
On 5/18/22 11:30, Etienne-Victor Depasquale wrote:
Agreed - but wouldn't it be fair to say that, nonetheless, the availability of an MSA supports the development of network architecture?
Of course, it would. After all, we want two sides to be able to speak to each other, to create this Internet :-).
With an MSA, there is some limited, common basis for a discussion in an ecosystem of vendors and network operators. That should support development of architecture.
It's nice and stable as a technology stabilizes. But when the next thing needs to be built (400Gbps today, 800Gbps tomorrow, maybe 1Tbps in 5 years or less), vendors like to compete on who can come up with the first (not the best) solution. Industry then catches up a while later. Just look at what Cisco tried with the CPAK. While novel, didn't work out too well for them, and the customers that bought tons of them. But, fair point, CFP2 was still dithering, so... We've seen the same with Apple, and how ship their devices with "unproven" tech. They've been lucky, so far... Mark.
participants (4)
-
Etienne-Victor Depasquale -
Mark Tinka -
Martin Hannigan -
Saku Ytti