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]…
> gbic-re
On 30 Jun 2014, at 3:47 pm, Saku Ytti 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 registers w
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,
>
> 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
On Cisco equipment supporting MACsec, EAP and MKA is of course configured
through the normal cli.
On Wednesday, June 25, 2014, Pieter Hulshoff 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, c
On Wed, Jun 25, 2014 at 4:51 PM, Pieter Hulshoff 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 there isn't a
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 you
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 b
>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 Wed, Jun 25, 2014 at 4:17 PM, 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?
today you
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 key
On Wed, Jun 25, 2014 at 8:40 AM, Saku Ytti 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 technolo
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 f
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 us
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 device?
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 guess
>> 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 metho
On Tue, Jun 24, 2014 at 6:30 PM, Randy Bush 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 g
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
>> 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 ha
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
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 requ
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 splitter
On Tue, Jun 24, 2014 at 1:19 PM, Saku Ytti 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 inc
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 12:07 PM, Saku Ytti 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 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 9:59 AM, Pieter Hulshoff wrote:
> On 24-6-2014 15:50, Christopher Morrow wrote:
>>
>> On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff
>> wrote:
>>
>>> features they should have. I'll then try to build a business case to get
>>> the
>>> product developed. MACsec is current
On 24-6-2014 15:50, Christopher Morrow wrote:
On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff 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
On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff 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 key management strate
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 (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 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 equipment,
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 c
On Tue, Jun 24, 2014 at 12:59 AM, Pieter Hulshoff 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 other
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
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 :
> On (2014-06-
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 b
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 s
41 matches
Mail list logo
