Re: MACsec SFP

["Eric Flanery (eric)" <eric () flanery us>]

Hmm, wandering pie-in-the-sky module wish list...

MACsec would be great, hopefully in an easy to manage/replace form.

Separately tunable transmitters and receivers; in both DWDM and CWDM
flavors. This would reduce the number of different parts to track/stock,
and enable the use of simple splitters/combiners in place of mux/demux
shelves for some short links.

Fully functional (as a manageable device) whatever-PON 'OLT in a module',
so that we can use any old host device that lacks specific support. (ONTs
too)

'Channelized SFP+', that talks on multiple wavelengths (CWDM/DWDM) at a 1G
rate simultaneously, to support a sort of WDM-PON. And/or SFP+ modules that
talk on multiple strands at a 1G rate simultaneously, with something like a
MPO/MTP connector, to increase density. I suppose there would need to be
some sort of switch or mux built into the module in either case.

A SFP(+) microwave modem, to connect to a radio head. Hopefully with wide
support of many licensed and unlicensed bands.

802.11-whatever APs in a SFP(+) form factor, preferably controller-based.
Perhaps doing some sort of RF-over-Ethernet to enable widely distributed
antenna systems.

Mini MPLS LER/PE routers in SFP form. All sorts of customer-facing
interface types could be interesting, but mostly (sub-rate) Ethernet with
QoS of some sort.

Self power-leveling and/or attenuating with wide ranges, again reducing
part tracking/stocking, and eliminating discrete attenuator pads.

SIP ATA in SFP form.

Small flash-based NAS in SFP form.

'Computational resources' in SFP(+) form (ARM chips maybe?).

OTDR functionality built into modules, hopefully able to operate without
disrupting the data flow, perhaps continuously.

Manageable (CLI and SNMP, please) modules of all sorts, to enable whatever
'special' features to be operated without requiring any particular support
from the host device beyond the MSA.

1G/100M SFPs that provide PoE ('passive' 18v or 24v would be most
appreciated.)

No vendor lock!

--Eric


On Tue, Jun 24, 2014 at 10:19 AM, Saku Ytti <saku () ytti fi> wrote:

> On (2014-06-24 12:30 -0400), Christopher Morrow wrote:
>
> > it's going to be hard to schedule a key roll then, right? I would
> > expect that in most/many deployments where someone enters a 'key'
> > there has to be some compliance process that includes: "And you change
> > that key every X days" right? So you'll NOT want to be in a situation
> > that involves coordinating a few thousand truck rolls every X months
> > to have this deployed.
>
> Hopefully you could offer date when new keys take effect.
>
> > > Maybe some customer would then enter need for this in CLI in their
> multimillion
> > > dollar RFQ, and then we'd get the feature.
> >
> > maybe so... multi-million of sfp is a lot of sfp though.
>
> Of course this would be for the equipment where SFP sits, SFP vendor can't
> solve this. But if you're making it mandatory in router RFQ, it seems
> pretty
> much guaranteed vendors would comply and winning bid at least would
> implement
> it.
>
>
> --
>   ++ytti