Mailing List Archive

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"?

Mark.

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: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.

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 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<

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.