On (2014-06-30 13:28 +0930), Glen Turner wrote:
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.
This is what I tried to tackle,
On 30 Jun 2014, at 3:47 pm, Saku Ytti s...@ytti.fi wrote:
On (2014-06-30 13:28 +0930), Glen Turner wrote:
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
On (2014-06-30 17:21 +0930), Glen Turner wrote:
What you really want isn’t DHCP-like, but simple AND-mask OR-set register
handling. You’d provide your customers with the magic numbers.
interface …
gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]…
Perhaps such lag could be avoided in future if we'd specify some 'host to SFP'
high level protocol, perhaps in much the same way as DHCP 'option' handling?
The SFF Committee specifies GBIC registers. They’d be the appropriate group to
add registers for features such as MACsec, Ethernet OAM
I was wondering: Would there be an interest in a similar IPsec SFP or is
that part already well taken care of by the router market?
Kind regards,
Pieter Hulshoff
On (2014-06-25 22:45 +0200), Pieter Hulshoff wrote:
chosen communication protocol. This will in part depend on the customer
feedback I get, which currently range from our current layer-2 solution to a
web interface to a CLI. If we go layer-3, we'll probably use a standard like
SSL/TLS for web
That's a large number of proposals. :) I'll have a chat with some
colleagues about the types outside my areas of expertise to see what
they think about it.
You're not the first to mention separately tunable transmitters and
receivers. Do you think there would be a great demand for this
Those 'proposals' are really just things that would have been useful in
module form at one point or another, not necessarily anything that I've
given any serious thought to what sort of market they would have. Some are
probably impractical, some would probably be far too expensive to actually
be
On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote:
That said, I do think the separately tunable tunable transmitters and
receivers could be huge, especially if they came at only a reasonably small
I don't think this technology exists. The receivers are always wideband and
there is some
On Wed, Jun 25, 2014 at 8:40 AM, Saku Ytti s...@ytti.fi wrote:
On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote:
That said, I do think the separately tunable tunable transmitters and
receivers could be huge, especially if they came at only a reasonably
small
I don't think this
Would be nice if we knew what the protocol was that communicated this
information down to the SFP and would also be nice if that was an open
protocol subject to review. UDP something? is my guess but ow do those
messages look?
I'm new to the MACsec idea but I would hope we could watch for such
On Wed, Jun 25, 2014 at 4:17 PM, John Schiel jsch...@flowtools.net wrote:
Would be nice if we knew what the protocol was that communicated this
information down to the SFP and would also be nice if that was an open
protocol subject to review. UDP something? is my guess but ow do those
messages
protocol was that communicated this information down to the SFP
For EEPROM access in a SFP+ it's I2C with is well documented and used in tons
of embedded stuff .. commercial logic analysis tools can handle this protocol,
as can your average $10 Arudrino.
Of course writing certain parts of the
On 25-06-14 22:17, John Schiel wrote:
Would be nice if we knew what the protocol was that communicated this
information down to the SFP and would also be nice if that was an open
protocol subject to review. UDP something? is my guess but ow do those
messages look?
I'm new to the MACsec idea
On 25-06-14 22:45, Christopher Morrow wrote:
today you program the key (on switches that do macsec, not in an SFP
that does it for you, cause those don't exist, yet) in your router
config and as near as I have seen there isn't a key distribution
protocol aside from that which you write/manage
On Wed, Jun 25, 2014 at 4:51 PM, Pieter Hulshoff phuls...@aimvalley.nl wrote:
On 25-06-14 22:45, Christopher Morrow wrote:
today you program the key (on switches that do macsec, not in an SFP
that does it for you, cause those don't exist, yet) in your router
config and as near as I have seen
On Cisco equipment supporting MACsec, EAP and MKA is of course configured
through the normal cli.
On Wednesday, June 25, 2014, Pieter Hulshoff phuls...@aimvalley.nl wrote:
On 25-06-14 22:45, Christopher Morrow wrote:
today you program the key (on switches that do macsec, not in an SFP
that
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
feature and market information for such a device, and I would welcome some
feedback from interested people. Discussion about other types of smart SFPs
would also be welcome. Feel free to contact me directly using the contact
information
Totally agree with Ytti subrated sfp Yummy
Andreas Larsen
IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6
Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70
843 10 56
www.ip-only.se
24 jun 2014 kl. 08:37 skrev Saku Ytti s...@ytti.fi:
On 24-6-2014 8:37, Saku Ytti wrote:
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
feature and market information for such a device, and I would welcome some
feedback from interested people. Discussion about other types of smart SFPs
would also be welcome. Feel free to contact me directly
On Tue, Jun 24, 2014 at 12:59 AM, Pieter Hulshoff phuls...@aimvalley.nl wrote:
On 24-6-2014 8:37, Saku Ytti wrote:
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
feature and market information for such a device, and I would welcome
some
feedback from interested people. Discussion about
On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote:
Hi Pieter,
I've seen this request from others as well. Do you have any
proposal/preference to limit the data rate from the switch?
For this solution to be marketable, it needs to be extremely cheap, as you're
essentially competing against
On 24-6-2014 10:21, Saku Ytti wrote:
For this solution to be marketable, it needs to be extremely cheap, as
you're essentially competing against cheapest consumer grade switches
to subrate a port. These ports would not be revenue generating, but
almost invariably MGMT ports to legacy
On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote:
So basically a 1G connection to the switch, buffering with frame drop, and a
tri-rate RJ45 connector? Sounds like something that could easily be built
Yes, also similar solution for 10GE SFP+.
Not sure what price should be 50EUR for 1GE and
On 24-6-2014 11:09, Saku Ytti wrote:
On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote:
So basically a 1G connection to the switch, buffering with frame drop, and a
tri-rate RJ45 connector? Sounds like something that could easily be built
Yes, also similar solution for 10GE SFP+.
What about
On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff phuls...@aimvalley.nl wrote:
features they should have. I'll then try to build a business case to get the
product developed. MACsec is currently on the top of my own list, but I'll
gladly pass other ideas to my colleagues.
what would be your
On 24-6-2014 15:50, Christopher Morrow wrote:
On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff phuls...@aimvalley.nl wrote:
features they should have. I'll then try to build a business case to get the
product developed. MACsec is currently on the top of my own list, but I'll
gladly pass other
On Tue, Jun 24, 2014 at 9:59 AM, Pieter Hulshoff phuls...@aimvalley.nl wrote:
On 24-6-2014 15:50, Christopher Morrow wrote:
On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff phuls...@aimvalley.nl
wrote:
features they should have. I'll then try to build a business case to get
the
product
On (2014-06-24 11:50 -0400), Christopher Morrow wrote:
Programmable seems like the way to go, provided there's a path to do
that in the cli of the device you plugged the SFP into? (which I think
is the hard part actually, right?)
Solution could be same as for tunable optics, first you tune
On Tue, Jun 24, 2014 at 12:07 PM, Saku Ytti s...@ytti.fi wrote:
On (2014-06-24 11:50 -0400), Christopher Morrow wrote:
Programmable seems like the way to go, provided there's a path to do
that in the cli of the device you plugged the SFP into? (which I think
is the hard part actually, right?)
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
On Tue, Jun 24, 2014 at 1:19 PM, Saku Ytti s...@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
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
DIP switches?
Frank
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Saku Ytti
Sent: Tuesday, June 24, 2014 3:21 AM
To: nanog@nanog.org
Subject: Re: MACsec SFP
On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote:
Hi Pieter,
I've seen this request from
On 24-06-14 17:50, Christopher Morrow wrote:
So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia
AND it's paired link in west caledonia? yikes. Also, is that a
'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd'
Gosh joe I'm not sure...
Obviously this
Solution could be same as for tunable optics, first you tune with
eeprommer until CLI gets support.
Remote legs could have their own eeprommer, which can be easy enough
to use not to require training and costs like 10EUR.
it's going to be hard to schedule a key roll then, right?
i have
How much ahead of my time would I be if I was to ask for CFP/CFP2
transceivers supporting MACsec? (at a reasonably competitive price)
--Aris
On Tue, Jun 24, 2014 at 6:30 PM, Randy Bush ra...@psg.com wrote:
Solution could be same as for tunable optics, first you tune with
eeprommer until CLI gets support.
Remote legs could have their own eeprommer, which can be easy enough
to use not to require training and costs like 10EUR.
it's
i have always been fond of rfc 4808 and not the unnecessarily complex
alternatives such as tcp-ao.
sure... but to do this you have to be able to program the keys from
the platform the SFP is plugged into.. .not via the sfp itself
(outside the chassis)
i was advocating the general method,
On 25-06-14 04:57, Aris Lambrianidis wrote:
How much ahead of my time would I be if I was to ask for CFP/CFP2
transceivers supporting MACsec? (at a reasonably competitive price)
So far, most requests I got were for 1 Gbps, and some for 10 Gbps.
You're the first to mention 100 Gbps, so my
All,
Last year some people on this list expressed interest in smart SFP
options, like e.g. MACsec. As a network consultant and systems architect
with AimValley in the Netherlands, I'm currently in the process of
gathering feature and market information for such a device, and I would
welcome
41 matches
Mail list logo
