[172669] in North American Network Operators' Group
Re: MACsec SFP
daemon@ATHENA.MIT.EDU (Glen Turner)
Mon Jun 30 03:52:40 2014
X-Original-To: nanog@nanog.org
From: Glen Turner <gdt@gdt.id.au>
In-Reply-To: <20140630061727.GA20635@pob.ytti.fi>
Date: Mon, 30 Jun 2014 17:21:30 +0930
To: Saku Ytti <saku@ytti.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
On 30 Jun 2014, at 3:47 pm, Saku Ytti <saku@ytti.fi> wrote:
> On (2014-06-30 13:28 +0930), Glen Turner wrote:
>=20
>> After the SFF Committee specifies the registers the operating system =
vendors or vendors of devices would then add commands to support to =
toggle the I2C needed to program those registers with MACsec keys, etc.
>=20
> This is what I tried to tackle, this creates chicken/egg scenario, no =
one is
> buying optic, because you can't program it from your router, and you =
can't
> program it in your router, as no one is using the optic and vendor =
won't put
> development hours on it.
> If instead there would be standardized (DHCP option like) system to =
code
> arbitrary value to arbitrary location, you could code the feature, =
without
> router understanding what it is, after a while, syntactic sugar might =
be added
> for convenience.
What you really want isn=92t DHCP-like, but simple AND-mask OR-set =
register handling. You=92d provide your customers with the magic =
numbers.
interface =85
gbic-register [if REGISTER AND-MASK VALUE]=85 [set REGISTER AND-MASK =
OR-VALUE]=85
gbic-register =85
Assuming that the GBIC programming doesn=92t change PHY requirements you =
are done.
--=20
Glen Turner <http://www.gdt.id.au/~gdt/>
