SDN APE, and IX stats from Citylink

Tim Hoffman

20 Jul 2015 20 Jul '15

10:14 a.m.

Greetings, There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX. Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list; 1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project? 2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be? I am sure many of us in the peering community will be eager to hear the answers to these questions.... Cheers, Hoff

Attachments:

attachment.htm (text/html — 1.1 KB)

Show replies by date

Jonathan Brewer

27 Jul 27 Jul

5:04 a.m.

Any news on this? Anyone at home at CityLink? On 20 July 2015 at 17:14, Tim Hoffman wrote:

...

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers, Hoff

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Todd Dickason

5:21 a.m.

Hi Guys, see below for current status from Nick Willis........... Thanks Tim, You are right we have been working on SDN/Openflow solutions for NZIX. In the last month we have finished a Proof of Concept of the SDN for NZIX based on Noviflow hardware that looks at the following use cases. * Enforce router hygiene * NZIX2 will block IGP, CDP, STP etc noise leaked by peers, by only allowing DIX Ethernet (Ethernet II) encapsulated frames and not LLC/SNAP frames * ARP, DHCP, PIM, ICMPv6 ND-RA etc broadcast and multicast messages will be blocked. We have an exception for ARP messages sourced from the exchange peering subnet and IPv6 ND (NB: IPv6 traffic is still not supported in this demo version) * Implement IETF BCP38 * Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange * Reflection attack mitigation * switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal * Prevent capacity stealing * traffic is allowed on the exchange only if it's sourced/destined from/to a prefix that has been registered on the NZIX2 portal. This means that if a peer configures a static default route to an ISP that has the full internet routing table, his traffic destined to international prefixes will be dropped The next steps is a demonstration this Proof of Concept version to interested parties in the technical community to get their feedback on the value of these features for network operators. The details of this demonstration are still being worked through. While aggregated traffic reporting would be part of this, we do not have a release date yet for an SDN/Openflow based exchange. I will investigate whether we can release aggregated traffic reporting on the current exchanges earlier. Regards Nick Willis From: mailto:nznog-bounces(a)list.waikato.ac.nz> on behalf of Tim Hoffman mailto:tim(a)hoffman.net.nz> Date: Tuesday, 21 July 2015 3:14 pm To: NZNOG Mailing-List mailto:nznog(a)list.waikato.ac.nz> Subject: [nznog] SDN APE, and IX stats from Citylink Greetings, There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX. Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list; 1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project? 2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be? I am sure many of us in the peering community will be eager to hear the answers to these questions.... Cheers, Hoff

Jonathan Brewer

5:31 a.m.

Thanks Dr. Nick! On 27 July 2015 at 12:21, Todd Dickason wrote:

...

Hi Guys, see below for current status from Nick Willis………..

Thanks Tim,

You are right we have been working on SDN/Openflow solutions for NZIX. In the last month we have finished a Proof of Concept of the SDN for NZIX based on Noviflow hardware that looks at the following use cases.

- Enforce router hygiene - NZIX2 will block IGP, CDP, STP etc noise leaked by peers, by only allowing DIX Ethernet (Ethernet II) encapsulated frames and not LLC/SNAP frames - ARP, DHCP, PIM, ICMPv6 ND-RA etc broadcast and multicast messages will be blocked. We have an exception for ARP messages sourced from the exchange peering subnet and IPv6 ND (NB: IPv6 traffic is still not supported in this demo version) - Implement IETF BCP38 - Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange - Reflection attack mitigation - switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal - Prevent capacity stealing - traffic is allowed on the exchange only if it's sourced/destined from/to a prefix that has been registered on the NZIX2 portal. This means that if a peer configures a static default route to an ISP that has the full internet routing table, his traffic destined to international prefixes will be dropped

The next steps is a demonstration this Proof of Concept version to interested parties in the technical community to get their feedback on the value of these features for network operators. The details of this demonstration are still being worked through.

While aggregated traffic reporting would be part of this, we do not have a release date yet for an SDN/Openflow based exchange. I will investigate whether we can release aggregated traffic reporting on the current exchanges earlier.

Regards

Nick Willis

From: on behalf of Tim Hoffman < tim(a)hoffman.net.nz> Date: Tuesday, 21 July 2015 3:14 pm To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers, Hoff

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Tim Hoffman

6:31 a.m.

Greetings, Thanks for the detailed update. It would be good if you can let us know when you can release aggregated traffic reporting on the exchange - standard for IXs in North America and Europe.

...

- Enforce router hygiene - NZIX2 will block IGP, CDP, STP etc noise leaked by peers, by only allowing DIX Ethernet (Ethernet II) encapsulated frames and not LLC/SNAP frames - ARP, DHCP, PIM, ICMPv6 ND-RA etc broadcast and multicast messages will be blocked. We have an exception for ARP messages sourced from the exchange peering subnet and IPv6 ND (NB: IPv6 traffic is still not supported in this demo version) - Implement IETF BCP38 - Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange

So you are going to require peers to register on your portal, rather than

using RADB which is the industry standard solution for exactly this problem? Why?

...

- - - Reflection attack mitigation - switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal

So you are effectively implementing uRPF strict mode? That's an

*interesting* decision. There are many situations where a transit provider may be used by an ASN for outbound traffic only - or for outbound traffic for all prefixes, and inbound for only certain prefixes - for either load balancing or fault mitigation. By doing this you break the ability of NZ providers to allow this. You are effectively enforcing a standard which is not used on the major transit networks in NZ. Also if a user in NZ obtains a new prefix, and their transit provider has not yet updated you with this new prefix, but another transit provider they are dual homed to has, and they start using this, you may cause blackholing of this traffic.

...

- - - Prevent capacity stealing - traffic is allowed on the exchange only if it's sourced/destined from/to a prefix that has been registered on the NZIX2 portal. This means that if a peer configures a static default route to an ISP that has the full internet routing table, his traffic destined to international prefixes will be dropped

As per my comments above on your last point.

Cheers, Tim

Dave Mill

6:40 a.m.

On Tue, Jul 28, 2015 at 11:31 AM, Tim Hoffman wrote:

...

...
- Reflection attack mitigation - switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal

So you are effectively implementing uRPF strict mode? That's an *interesting* decision. There are many situations where a transit provider may be used by an ASN for outbound traffic only - or for outbound traffic for all prefixes, and inbound for only certain prefixes - for either load balancing or fault mitigation. By doing this you break the ability of NZ providers to allow this. You are effectively enforcing a standard which is not used on the major transit networks in NZ.

What Tim describes above reflects what we do with our transit providers. So very interested in responses/discussions on this point in particular. Cheers Dave

Tim Hoffman

6:46 a.m.

It's also worth noting that of the considerable number of IXs that as13414 peers at worldwide, we've never seen someone enforce their own prefix database, or do the BCP38 enforcement *for* the provider. IXs use RADB, and push security from transit theft onto the ISP. To see a New Zealand IX, whose requirements are pushing no boundaries in terms of traffic or anything else try to re-invent the wheel in a manner that may have considerably negative impact on the New Zealand internet is concerning and strange at best. On Mon, Jul 27, 2015 at 4:40 PM, Dave Mill wrote:

...

On Tue, Jul 28, 2015 at 11:31 AM, Tim Hoffman wrote:

...
...
- Reflection attack mitigation - switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal

So you are effectively implementing uRPF strict mode? That's an *interesting* decision. There are many situations where a transit provider may be used by an ASN for outbound traffic only - or for outbound traffic for all prefixes, and inbound for only certain prefixes - for either load balancing or fault mitigation. By doing this you break the ability of NZ providers to allow this. You are effectively enforcing a standard which is not used on the major transit networks in NZ.

What Tim describes above reflects what we do with our transit providers. So very interested in responses/discussions on this point in particular.

Cheers Dave

Mike Jager

7 a.m.

On 28 Jul 2015, at 10:21, Todd Dickason wrote:

...

* Enforce router hygiene * NZIX2 will block IGP, CDP, STP etc noise leaked by peers, by only allowing DIX Ethernet (Ethernet II) encapsulated frames and not LLC/SNAP frames

Great. I'm not sure we needed an SDN to enforce this, but each to their own.

...

* ARP, DHCP, PIM, ICMPv6 ND-RA etc broadcast and multicast messages will be blocked. We have an exception for ARP messages sourced from the exchange peering subnet and IPv6 ND (NB: IPv6 traffic is still not supported in this demo version)

"IPv6 traffic is still not supported"? It's 2015. Why is this even a thing?

...

* Implement IETF BCP38 * Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange * Reflection attack mitigation * switch ports are tied to prefixes and mac addresses so the exchange SDN switch will not accept traffic sourced from a prefix which is not supposed to be coming from this particular port, as registered on the NZIX2 portal * Prevent capacity stealing * traffic is allowed on the exchange only if it's sourced/destined from/to a prefix that has been registered on the NZIX2 portal. This means that if a peer configures a static default route to an ISP that has the full internet routing table, his traffic destined to international prefixes will be dropped

The below is an extract from a message I sent to the IXAG list in April 2013:

...

Despite jumping up and down about the fact that there are plenty of networks on APE and/or WIX that are quite happy for their transit to be stolen, I must confess I'm a little bit on the fence as to whose problem this is to solve.

Certainly the exchange operator should protect the exchange itself. No ARP spoofing, one MAC per port, no proxy ARP, no non-IP packets, etc, etc. However, I tend to lean towards protection of member networks being up to each member.

This packet filtering based on advertised prefixes/prefixes in the portal thing is pretty new, and requires rather a different way of thinking compared to how other exchange points (and indeed "normal" switches) operate. We're already (in rev2!) at the point where we're disabling a lot of the network-network protection on bilateral sessions because we don't know the commercial relationships between member networks.

Recall recent discussion about trying to get Large International Content Providers into NZ. We want this to be easy as possible for them. These networks likely have defences that their operators deem sufficient to protect against badness. I wonder whether it could potentially discourage networks from participating on the exchange if it's deemed "too hard" compared to how they already operate at other exchanges.

Two years later, the only modification I'd make to the above text is to remove the ambiguity that responsibility for preventing abuse of member networks rests squarely with with the member. Anything else is insanity, for a variety of reasons that have been done to death in various fora. Cheers -Mike

Tim Hoffman

7:02 a.m.

And to Mike's point.

...

...
Recall recent discussion about trying to get Large International Content Providers into NZ. We want this to be easy as possible for them. These networks likely have defences that their operators deem sufficient to protect against badness. I wonder whether it could potentially discourage networks from participating on the exchange if it's deemed "too hard" compared to how they already operate at other exchanges.

Yes.

Russell Tester

7:12 a.m.

Maybe I'm missing something but surely being a SDN it should allow some of these features to be turned on or off on a per peer basis. Eg if I want the exchange to do BCP38 for me, I tick the box in the portal? On 28 July 2015 at 12:02, Tim Hoffman wrote:

...

And to Mike's point.

...
...
Recall recent discussion about trying to get Large International Content Providers into NZ. We want this to be easy as possible for them. These networks likely have defences that their operators deem sufficient to protect against badness. I wonder whether it could potentially discourage networks from participating on the exchange if it's deemed "too hard" compared to how they already operate at other exchanges.

Yes.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Lincoln Reid

9:47 a.m.

On Mon, 2015-07-27 at 22:21 +0000, Todd Dickason wrote:

...

You are right we have been working on SDN/Openflow solutions for NZIX. In the last month we have finished a Proof of Concept of the SDN for NZIX based on Noviflow hardware that looks at the following use cases.

Thanks for the update.

...

* Implement IETF BCP38 * Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange

To make sure I have this correct, are you talking about dropping frames that don't match the generated list of source IP ranges for a customer port? If so, this is pretty well a show stopper for us. We have downstream customers that don't have all their ducks in a row when they get new prefixes etc, and using an exchange that would blackhole their traffic isn't a risk that I would take. I'm all for BCP38 but it goes at the edge of the network, not in the exchange point.

...

* Prevent capacity stealing * traffic is allowed on the exchange only if it's sourced/destined from/to a prefix that has been registered on the NZIX2 portal. This means that if a peer configures a static default route to an ISP that has the full internet routing table, his traffic destined to international prefixes will be dropped

Have you considered the existing (mis)use case of Vodafone policy routing traffic from cable modem tails to ISP's on the WIX fabric? I'd love to get them to stop doing that and deliver their cable connections to us across one of the multitude of their own links into us, but they don't seem that interested. In the near past I also knew of multiple instances of backup transit and partial transit across the WIX and APE fabric, no idea if they are still in play or not. Regards, -- Lincoln Reid Head of Networks ACSData - AS18119 lincoln(a)acsdata.co.nz Phone: +64 4 939 2200 Fax: +64 4 939 2201

Mike Jager

10:07 a.m.

On 28 Jul 2015, at 14:47, Lincoln Reid wrote:

...

Have you considered the existing (mis)use case of Vodafone policy routing traffic from cable modem tails to ISP's on the WIX fabric? I'd love to get them to stop doing that and deliver their cable connections to us across one of the multitude of their own links into us, but they don't seem that interested.

In the near past I also knew of multiple instances of backup transit and partial transit across the WIX and APE fabric, no idea if they are still in play or not.

This is pretty much exactly what was discussed a couple years ago. IXP operators should not have visibility of commercial arrangements between members. The proposed IXP has to have a technical understanding of those arrangements (or risk dropping packets), or have an opt-out to turn all the "security" features off. And the first thing to be turned off when troubleshooting a problem will be the IXP meddlin^Wsecurity features. And they'll stay off. Cheers -Mike

Tim Hoffman

10:14 a.m.

...

This is pretty much exactly what was discussed a couple years ago. IXP operators should not have visibility of commercial arrangements between members. The proposed IXP has to have a technical understanding of those arrangements (or risk dropping packets), or have an opt-out to turn all the "security" features off.

And the first thing to be turned off when troubleshooting a problem will be the IXP meddlin^Wsecurity features. And they'll stay off.

Or participants will migrate to AKL-IX/Megaport.

Liam Farr

10:23 a.m.

After the extortionate APE price hike from $195 a month to $695 some of us did just that. Sent from my iPhone On 28/07/2015, at 3:14 pm, Tim Hoffman wrote: This is pretty much exactly what was discussed a couple years ago. IXP

...

operators should not have visibility of commercial arrangements between members. The proposed IXP has to have a technical understanding of those arrangements (or risk dropping packets), or have an opt-out to turn all the "security" features off.

And the first thing to be turned off when troubleshooting a problem will be the IXP meddlin^Wsecurity features. And they'll stay off.

Or participants will migrate to AKL-IX/Megaport. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Jesse Archer

10:27 a.m.

Ah yip. Ditched APE in favour of Akl-IX months ago. *Jesse Archer* *General Manager*Full Flavour *p. *07 577 0099 *ddi*. 07 281 1391 *s*. Skype "myfullflavour" *e*. jesse(a)fullflavour.nz *w*. fullflavour.nz http://www.fullflavourmedia.co.nz/ *a. *Basestation, 148 Durham Street, Tauranga *a*. PO Box 16306, Bethlehem 3176, New Zealand On Tue, Jul 28, 2015 at 3:23 PM, Liam Farr wrote:

...

After the extortionate APE price hike from $195 a month to $695 some of us did just that.

Sent from my iPhone

On 28/07/2015, at 3:14 pm, Tim Hoffman wrote:

This is pretty much exactly what was discussed a couple years ago. IXP

...
operators should not have visibility of commercial arrangements between members. The proposed IXP has to have a technical understanding of those arrangements (or risk dropping packets), or have an opt-out to turn all the "security" features off.

And the first thing to be turned off when troubleshooting a problem will be the IXP meddlin^Wsecurity features. And they'll stay off.

Or participants will migrate to AKL-IX/Megaport.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Andy Davidson

4 Aug 4 Aug

3:04 p.m.

...

On 27 Jul 2015, at 23:21, Todd Dickason wrote:

• Implement IETF BCP38 • Instead of relying on peers to implement BCP38, NZIX2 enforces it by only allowing traffic sourced from a prefix which has been registered on the NZIX2 portal to enter the exchange

This is super interesting stuff. We have a clear direction from our members that they do NOT want us to do this (actually, any filtering - and with good — non technical — reasons) in London and Leeds but I find innovation to protect the internet by preventing attacks sourced from networks too delinquent and unintelligent to filter their access customers very interesting. Why registering on a portal rather than looking at the prefixes offered to the exchange via a collector ?

...

On 28 Jul 2015, at 00:31, Tim Hoffman wrote:

So you are going to require peers to register on your portal, rather than using RADB which is the industry standard solution for exactly this problem? Why?

RADB used for prefix-lists that filter whether a BGP advertisement reaches RIB rather than at a packet (layer 3 forwarding) layer. It’s unpoliced so can not protect against malicious attack but does prevent from most accidents. You could incorporate RADB by using it to build prefix-lists on the collector and then building layer 2-3 forwarding ACLS on the switches based on the prefixes imported into the collector’s RIB. Very very very interesting indeed ! Andy Davidson (Director at LONAP and IXLeeds in the UK; and of the European Internet Exchange Association; and a council member at NapAfrica)

Mark Frater

11:35 a.m.

I see other IX’s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/ Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while. Regards Mark From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Hoffman Sent: Tuesday, 21 July 2015 3:15 p.m. To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink Greetings, There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX. Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list; 1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project? 2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be? I am sure many of us in the peering community will be eager to hear the answers to these questions.... Cheers, Hoff

Tim Hoffman

12:17 p.m.

Toulouse. Big internet hub that Sent from my iPhone

...

On Aug 5, 2015, at 2:35 PM, Mark Frater wrote:

I see other IX’s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/

Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while.

Regards

Mark

From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Hoffman Sent: Tuesday, 21 July 2015 3:15 p.m. To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers, Hoff

Bevan Slattery

12:57 p.m.

As an FYI Megaport has been offering SDN-IX and elastic interconnections in Australia since 2013 and expanded into Auckland last year... https://www.megaport.com/about/megaport_enabled_locations Cheers [b]

...

On 5 Aug 2015, at 2:35 pm, Mark Frater wrote:

I see other IX’s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/

Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while.

Regards

Mark

From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Hoffman Sent: Tuesday, 21 July 2015 3:15 p.m. To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers, Hoff _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Tim Hoffman

16 Aug 16 Aug

3:46 a.m.

Hi, New Zealand's internet infrastructure has always benefited from the open engagement of key operators of this infrastructure with the community. Citylink has (at least in the past) engaged reasonably openly with the community. It is my hope that this will continue. On that note (and in this spirit of engagement), it would be good to see a detailed response from Citylink to the feedback provided over the last few weeks by the technical community on their proposed implementation of their SDN based internet exchange platform, an aggregate graph of the IX's traffic, and other matters discussed in this thread. Cheers, Tim On Tue, Aug 4, 2015 at 7:57 PM, Bevan Slattery wrote:

...

As an FYI Megaport has been offering SDN-IX and elastic interconnections in Australia since 2013 and expanded into Auckland last year...

https://www.megaport.com/about/megaport_enabled_locations

Cheers

[b]

On 5 Aug 2015, at 2:35 pm, Mark Frater wrote:

I see other IX’s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/

Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while.

Regards

Mark

*From:* nznog-bounces(a)list.waikato.ac.nz [ mailto:nznog-bounces(a)list.waikato.ac.nz ] *On Behalf Of *Tim Hoffman *Sent:* Tuesday, 21 July 2015 3:15 p.m. *To:* NZNOG Mailing-List *Subject:* [nznog] SDN APE, and IX stats from Citylink

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers,

Hoff

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Todd Dickason

3 Sep 3 Sep

12:03 p.m.

Hi Guys, Just to clarify CityLink's position on the matters raised in this thread: CityLink's efforts toward developing an SDN-based internet exchange platform have been primarily research focussed to date. There has been a lot of knowledge gained during this process on the capabilities (and limitations) of SDN and the impact it could have on the future of the telecommunication industry in New Zealand. While some gains have been made, the project/development is still in its infancy and there is no plan to put SDN into production on any of the existing NZIX exchange points or other locations in CityLink’s network at the current time. Any possible introduction of SDN technology down the track into the NZIX would only follow (a) extensive engagement with the NZNOG community/stakeholders on the operational matters raised, and (b) a satisfactory "pre-production trial" for interested parties, in order to adequately test the SDN platform and seek feedback on its implementation. CityLink hasn't been focussing solely on SDN development, however. Over the last two years we've made considerable investments in new hardware at APE and WIX, increasing the capacity and stability of the NZIX switching fabric and the supporting infrastructure (route servers). We've also progressed the migration of the last remaining wholesale ISP customers out of the NZIX peering LANs, thereby enabling the compilation of aggregate traffic graphs for the exchanges which have been difficult to produce historically. On that note, CityLink is happy to advise that aggregate traffic graphs for APE and WIX are now available at http://www.nzix.net Hopefully this clarifies where we are at right now. Cheers Todd Network Ops Manager, TeamTalk Group From: mailto:nznog-bounces(a)list.waikato.ac.nz> on behalf of Tim Hoffman Date: Monday, 17 August 2015 8:46 am To: Bevan Slattery Cc: NZNOG Mailing-List Subject: Re: [nznog] SDN APE, and IX stats from Citylink Hi, New Zealand's internet infrastructure has always benefited from the open engagement of key operators of this infrastructure with the community. Citylink has (at least in the past) engaged reasonably openly with the community. It is my hope that this will continue. On that note (and in this spirit of engagement), it would be good to see a detailed response from Citylink to the feedback provided over the last few weeks by the technical community on their proposed implementation of their SDN based internet exchange platform, an aggregate graph of the IX's traffic, and other matters discussed in this thread. Cheers, Tim On Tue, Aug 4, 2015 at 7:57 PM, Bevan Slattery mailto:bevan(a)slattery.net.au> wrote: As an FYI Megaport has been offering SDN-IX and elastic interconnections in Australia since 2013 and expanded into Auckland last year... https://www.megaport.com/about/megaport_enabled_locations Cheers [b] On 5 Aug 2015, at 2:35 pm, Mark Frater mailto:mark.frater(a)compass.net.nz> wrote: I see other IX¹s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/ Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while. Regards Mark From:nznog-bounces(a)list.waikato.ac.nzmailto:nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Hoffman Sent: Tuesday, 21 July 2015 3:15 p.m. To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink Greetings, There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX. Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list; 1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project? 2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be? I am sure many of us in the peering community will be eager to hear the answers to these questions.... Cheers, Hoff _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Tim Hoffman

12:49 p.m.

Thanks Todd, glad to see Citylink (finally) engaging with the community on this matter. It is reassuring to understand that there is going to be satisfactory validation of any new technologies introduced, ensuring that you do not place NZs internet infrastructure at risk.. Hoff Sent from my iPhone

...

On Sep 3, 2015, at 10:03 PM, Todd Dickason wrote:

Hi Guys,

Just to clarify CityLink's position on the matters raised in this thread:

CityLink's efforts toward developing an SDN-based internet exchange platform have been primarily research focussed to date. There has been a lot of knowledge gained during this process on the capabilities (and limitations) of SDN and the impact it could have on the future of the telecommunication industry in New Zealand. While some gains have been made, the project/development is still in its infancy and there is no plan to put SDN into production on any of the existing NZIX exchange points or other locations in CityLink’s network at the current time. Any possible introduction of SDN technology down the track into the NZIX would only follow (a) extensive engagement with the NZNOG community/stakeholders on the operational matters raised, and (b) a satisfactory "pre-production trial" for interested parties, in order to adequately test the SDN platform and seek feedback on its implementation.

CityLink hasn't been focussing solely on SDN development, however. Over the last two years we've made considerable investments in new hardware at APE and WIX, increasing the capacity and stability of the NZIX switching fabric and the supporting infrastructure (route servers). We've also progressed the migration of the last remaining wholesale ISP customers out of the NZIX peering LANs, thereby enabling the compilation of aggregate traffic graphs for the exchanges which have been difficult to produce historically. On that note, CityLink is happy to advise that aggregate traffic graphs for APE and WIX are now available at http://www.nzix.net

Hopefully this clarifies where we are at right now.

Cheers Todd Network Ops Manager, TeamTalk Group

From: on behalf of Tim Hoffman Date: Monday, 17 August 2015 8:46 am To: Bevan Slattery Cc: NZNOG Mailing-List Subject: Re: [nznog] SDN APE, and IX stats from Citylink

Hi,

New Zealand's internet infrastructure has always benefited from the open engagement of key operators of this infrastructure with the community. Citylink has (at least in the past) engaged reasonably openly with the community. It is my hope that this will continue.

On that note (and in this spirit of engagement), it would be good to see a detailed response from Citylink to the feedback provided over the last few weeks by the technical community on their proposed implementation of their SDN based internet exchange platform, an aggregate graph of the IX's traffic, and other matters discussed in this thread.

Cheers, Tim

...
On Tue, Aug 4, 2015 at 7:57 PM, Bevan Slattery wrote: As an FYI Megaport has been offering SDN-IX and elastic interconnections in Australia since 2013 and expanded into Auckland last year...

https://www.megaport.com/about/megaport_enabled_locations

Cheers

[b]

On 5 Aug 2015, at 2:35 pm, Mark Frater wrote:

...
I see other IX¹s have started implementing SDN. See http://raynoreport.com/15/06/pica8-pushes-out-cisco-at-touix/

Toulouse IX are using Pica8 white boxes which others in NZ have been playing with for a while.

Regards

Mark

From:nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Hoffman Sent: Tuesday, 21 July 2015 3:15 p.m. To: NZNOG Mailing-List Subject: [nznog] SDN APE, and IX stats from Citylink

Greetings,

There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX.

Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list;

1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project?

2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be?

I am sure many of us in the peering community will be eager to hear the answers to these questions....

Cheers,

Hoff

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3398

Age (days ago)

3443

Last active (days ago)

List overview

Download

21 comments

12 participants

participants (12)

Andy Davidson
Bevan Slattery
Dave Mill
Jesse Archer
Jonathan Brewer
Liam Farr
Lincoln Reid
Mark Frater
Mike Jager
Russell Tester
Tim Hoffman
Todd Dickason