[j-nsp] MX304 Port Layout

[Saku Ytti]

On Tue, 27 Jun 2023 at 06:02, Mark Tinka via juniper-nsp
<juniper-nsp at puck.nether.net> wrote:

> > Similar use case here but we use a QFX as a fusion satellite if port expansion is required.
> > Works well as an small site start up option.
>
> Are vendors still pushing their satellite switches :-)?
>
> That technology looked dodgy to me when Cisco first proposed it with
> 9000v, and then Juniper and Nokia followed with their own implementations.

Juniper messaging seems to be geo-specific, in EU their sales seems to
sell them more willingly than in US. My understanding is that
basically fusion is dead, but they don't actually have solution for
access/SP market front-plate, so some sales channels are still
pitching it as the solution.

Nokia seems very committed to it.

I think the solution space is
   a) centralised lookup engines - so you have cheap(er) line cards
for high density low pps/bps
   b) satellite
   c) vlan aggregation

Satellite is basically a specific scenario of c), but it does bring
significant derisking compared to vlan aggregation, as a single
instance is designing it and can solve some problems better than can
be solved by vendor agnostic vlan aggregation. Vlan aggregation looks
very simple on the surface but is fraught with problems, many of which
are slightly better solved in satellites, and these problems will not
be identified ahead of time but during the next two decades of
operation.

Centralised boxes haven't been available for quite a few years, but
hopefully Cisco is changing that, I think it's the right compromise
for SPs.

But in reality I'm not sure if centralised actually makes sense, since
I don't think we can axiomatically assume it costs less to the vendor,
even though there is less BOM, the centralised design does add more
engineering cost. It might be basically a way to sell boxes to some
market at lower margins, while ensuring that hyperscalers don't buy
them, instead of directly benefiting from the cost reduction.





-- 
  ++ytti