From mike at linx.net Thu Oct 5 09:14:13 2006 From: mike at linx.net (Mike Hughes) Date: Thu, 05 Oct 2006 08:14:13 +0100 Subject: [eix-wg] RIPE53 WG meeting - Note to Presenters Message-ID: <9E4DA2D29BF98334661C6969@Rangitoto.ripemtg.ripe.net> Hi folks, Most of you probably know the drill these days, but just to make sure... Please upload your presentation using the Upload Facility - This gets your slideware automagically transferred by the wonders of technology onto the laptop in the meeting room, and it means we don't have to clown around massaging laptop-projector relationships during the working group meeting itself. One final change since the agenda was issued, and that is Netnod are now presenting after NaMEX withdrew from the agenda. Cheers, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ From mike at linx.net Thu Oct 12 18:14:58 2006 From: mike at linx.net (Mike Hughes) Date: Thu, 12 Oct 2006 17:14:58 +0100 Subject: [eix-wg] RIPE 53 EIX-WG Draft Minutes Message-ID: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> Herewith the draft minutes for the EIX Working Group held at RIPE 53 for your perusal and approval. Thanks to Catherine for a comprehensive set of minutes, especially wrt Q&A sessions. Mike -------------------------------------------------------------------------- Minutes ======= EIX Working Group Minutes - RIPE 53 Version 1.0 WG Chairs: Meeting chaired by Mike Hughes Scribe: Catherine Carr (RIPE NCC) Amsterdam, Thursday 5th October 2006, 11:00 - 12:45 -------------------------------------------------------- A. Administrative Matters - Working Group Chairs Fearghas McKay was unavailable, so the meeting was chaired by Mike Hughes. Catherine Carr (RIPE NCC) was nominated to scribe, and the jabber was monitored by Robert Kisteleki (RIPE NCC). The session was webcast in audio only. -------------------------------------------------------- B. Agenda Bashing - Working Group Chairs NAMEX withdrew their presentation for the IXP News Slot (agenda item Y). It was replaced with an update from NEDNOD. The NRO Numbers Council Election results were announced by Niall O'Reilly. 126 votes were cast. 1 was spoiled, so 125 valid votes. 3 voting slips were blank. 49 votes were in favour of Sabine Jaume 73 votes were in favour of Dave Wilson -------------------------------------------------------- C. Presentaion: IEEE >10G HSSG Report - Greg Hankins (Force10 Networks) http://www.ripe.net/ripe/meetings/ripe-53/presentations/ieee_10g.pdf Mike Hughes commented that it was good news that people are now getting to work in this area, because it is something that a lot of people in this group need. Right now it is mostly people talking about the physical and optical layers. There are a lot of challenges ahead. Outreach and media are really important in order to end up with something usable. Attendees were encouraged to get involved. This would probably be easier through a vendor so that the requirements can be collated. However, if attendees do not have a vendor that they feel comfortable working with, they can always post their own opinions. User input is welcomed and appreciated. -------------------------------------------------------- D. Call for Input to the IXP Switch Wishlist v3.1 - Mike Hughes (LINX) Mike Hughes informed the group that there have been a few different types of switch (for example higher density switches) since the IXP Switch Wishlist came out. A new iteration of the document is required. The group were asked to review what is on the list at the moment and submit any ideas to Mike. Some ideas have already been documented, such as cable management and slot orientation. New drafts of the document will be posted to the working group mailing list, and it will hopefully be adopted at RIPE 54. -------------------------------------------------------- E. Presentation: sFlow Implementation at AMS-IX - Elisa Jasinska (AMS-IX) http://www.ripe.net/ripe/meetings/ripe-53/presentations/sflow.pdf Simon Leinden (Switch) asked if the entire system is open source. Elisa Jasinska (AMS-IX) answered that just the perl module is open source at the moment, but she is planning on making the rest open source too. The demon around it is so integrated into the AMSIX environment to get the information about the members, so it cannot really be released like that. She will work on a way to split that into a separate module so that users can make their own database interfaces and so on. There was a question about whether AMS-IS had any issues with non liniarity of the graphs due to sampling errors. Elisa answered that you can not really correct that because it is statistics. The lower the IPv6 rate is the less samples there are, so the bigger the error in the end. Nick Hilliard (INet) asked if the software is compatible with data protection legislation in terms of sniffing IP addresses. Elisa explained that it is not decoding over layer 2. The datagram is providing the whole packet and it depends on how big the whole packet is. The maximum is 256 bytes depending on the packet header. The software does not decode all of that. It only looks at layer 2 and is not doing any analysis on layer 3 (such as ports, IP addresses, etc). It would be possible to integrate that, but there are no plans to do so. Nick went on to ask if there was a facility for members to opt out. Some exchange points do not want to divulge information about their peering agreements, and sometimes don't even want to have their names mentioned on websites. Elisa assured the group that there would be no mention of the members on the public website. Every member would see their graph in their own statistics. If they want to do something more with the information, such as adding it on their own public website, then that is their choice. There was a question yesterday in the IPv6 working group where someone wanted to know who was doing IPv6 traffic. AMS-IX do not know yet because the software doesn't tell them. But even if they did know, it is not information that they would give out. She also confirmed that no members who have asked to opt out. Avi Freedman (Akamai) asked if AMS-IX had a list of outstanding requests for Foundry for additional tags to go into sFlow. Elisa confirmed that they did not, because they have no problems with what is being provided. Avi went on to ask if enough tagging of source and dist interfaces had been seen and whether MAC pairs were being used. Elisa advised Foundry are supplying the packet header, and AMS-IX has the layer 2 information and MAC address. AMS-IX have a policy of one MAC address behind each member port, so that they can tell which member is which. Kurtis Lindqvist (NETNOD) referred to data protection law, and advised that if the data is logged then it must be kept because you may be asked to hand it out. Elisa answered that data which is decoded (such as mac addresses) is kept, as well as the graphs so that the members can see their information. The rest of the sFlow datagram is not decoded by the software so there is nothing to keep. Marco Sommani (CNR) asked for whether the perl module analyses the whole packet. Elisa answered no. There are perl modules which are analysing the whole stack of packet headers, but they are not being used. AMS-IX have implemented their own solution to analyse up to layer 2. -------------------------------------------------------- X. Euro-IX Report - Serge Radovcic (Euro-IX Secretariat) http://www.ripe.net/ripe/meetings/ripe-53/presentations/euroix.pdf Dave Wilson (HEAnet) observed that HEAnet's traffic dips every year in the summer and picks up in autumn as if it had never left off. You can draw a line as if the dip wasn't there. Serge replied that it was still a big jump in traffic after the summer. Blake Willis (Neo Telecoms) added that in France they are seeing a large amount of the bigger carriers changing their policies on the exchange simply because there are so many free exchanges. Many people are getting AS Numbers now. They can't deal with requests from all of the smaller carriers. -------------------------------------------------------- Y. IXP News/Reports - AMS-IX Presentation not available. - NDIX Presentation not available. An attendee asked which vendor was being used for releasing CWDM on NDIX's 10Gb rings. Remco from NDIX confirmed they are using the same fibre for a couple of routes for both access and core infrastructure. Some of the access infrastructure is still on GbE. - DE-CIX Presentation not available. Max Tulyev (NetAssist LLC) was interested in multicast exchange, and asked if there was any at DE-CIX. Wolfgang Tremmel informed him that they are offering free multicast ports with 100Mb port speed. You just have to pay for the cabling to the switch. - VIX http://www.ripe.net/ripe/meetings/ripe-53/presentations/vix.pdf - LINX http://www.ripe.net/ripe/meetings/ripe-53/presentations/ixp_switch.pdf Gert Doering (Spacenet) asked if multicast will go into the same VLAN as unicast when it is moved onto the main Foundries. Mike Hughes answered that it will be in a separate VLAN. Some members have said they don't even want it on tagged ports because they don't want a multicast accident blowing all their unicast traffic up. - MIX http://www.ripe.net/ripe/meetings/ripe-53/presentations/mix.pdf - NIX.CZ http://www.ripe.net/ripe/meetings/ripe-53/presentations/eix-jc-czn.pdf - NETNOD Presentation not uploaded. -------------------------------------------------------- AOB: Mike Hughes will request a schedule change in the meeting plan at the WG chairs meeting. He will try to get the two hour block on Wednesday afternoon, because the 90 minute sessions regularly fill up these days. -------------------------------------------------------- END -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ From rudolf at frml.net Fri Oct 13 10:12:26 2006 From: rudolf at frml.net (Rudolf van der Berg) Date: Fri, 13 Oct 2006 10:12:26 +0200 (CEST) Subject: [eix-wg] RIPE 53 EIX-WG Draft Minutes In-Reply-To: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> References: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> Message-ID: <31378.145.69.196.101.1160727146.squirrel@www.dnd.utwente.nl> Hi All, Wasn't present at the meeting, but happen to know a bit about the subject of data-retention. Standard disclaimers apply: This is my personal opinion, not my employers etc. (SNIP) > > Kurtis Lindqvist (NETNOD) referred to data protection law, and advised > that > if the data is logged then it must be kept because you may be asked to > hand > it out. Elisa answered that data which is decoded (such as mac addresses) > is kept, as well as the graphs so that the members can see their > information. The rest of the sFlow datagram is not decoded by the software > so there is nothing to keep. In principle the EU regulation the retention of data only applies to data that is on the list. sFlow data and headerdata of IP-packets is not on the list, so there is no necessity to retain it even if you log it. On top of this, the Privacy directives do apply, so data that is not on the list must be deleted when not used anymore for business purposes. Now the dataretention directive is the bottom limit and countries are allowed to do more, so always check with your local implementation of the Data Retention directive. Greetings, Rudolf From clive at demon.net Fri Oct 13 10:16:26 2006 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Oct 2006 09:16:26 +0100 Subject: [eix-wg] RIPE 53 EIX-WG Draft Minutes In-Reply-To: <31378.145.69.196.101.1160727146.squirrel@www.dnd.utwente.nl> References: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> <31378.145.69.196.101.1160727146.squirrel@www.dnd.utwente.nl> Message-ID: <20061013081626.GA56399@finch-staff-1.thus.net> Rudolf van der Berg said: >> Kurtis Lindqvist (NETNOD) referred to data protection law, and advised >> that >> if the data is logged then it must be kept because you may be asked to >> hand >> it out. Elisa answered that data which is decoded (such as mac addresses) >> is kept, as well as the graphs so that the members can see their >> information. The rest of the sFlow datagram is not decoded by the software >> so there is nothing to keep. > > In principle the EU regulation the retention of data only applies to data > that is on the list. sFlow data and headerdata of IP-packets is not on the > list, so there is no necessity to retain it even if you log it. On top of > this, the Privacy directives do apply, so data that is not on the list > must be deleted when not used anymore for business purposes. Now the > dataretention directive is the bottom limit and countries are allowed to > do more, so always check with your local implementation of the Data > Retention directive. Note that all of this only applies to data that identifies or relates to living individuals. A customer IP address, even if dynamic IP is used, could fall under this category because in principle it relates to one person. Data at a greater granularity (e.g. flows between ISPs) is not covered. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From nick at inex.ie Fri Oct 13 17:22:28 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 13 Oct 2006 16:22:28 +0100 Subject: [eix-wg] RIPE 53 EIX-WG Draft Minutes In-Reply-To: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> References: <563B99F719C91F568F364D55@Rangitoto.dhcp.nanog.merit.net> Message-ID: <452FAF34.2050104@inex.ie> > D. Call for Input to the IXP Switch Wishlist v3.1 - Mike Hughes (LINX) > > Mike Hughes informed the group that there have been a few different types > of switch (for example higher density switches) since the IXP Switch > Wishlist came out. A new iteration of the document is required. The group > were asked to review what is on the list at the moment and submit any ideas > to Mike. one thing which would be nice is the ability to make switch ports stop babbling out periodic traffic of all forms, regardless of whether the switch port is a tagged or untagged port. Most noisy protocols can be turned off on a per port basis, but not all. Right now, we have an issue with Cisco VTP which likes to send VTP packets on all trunking ports if you use VTP on your switch. You can turn this behaviour off in VTPv3 which is available in CatOS 8.1 and will be included in the SXG image train for C6500/7600's. Nick