Attendees: Jeff Bartig, Andrea Blome, Sue Boff, Jeff Boote, Eric Boyd, Cort Buffington, Brian Cashman, Brian Court, Matt Davy, James Deaton, Dave Farmer, Dale Finkelson, Carla Hunt, Dave Jent, Michael Lambert, Tim Lance, David Lassner, Ken Lindahl, Caren Litvanyi, George Loftus, Paul Love, John Moore, Bill Owens, Dave Pokorney, Ana Preston, Dave Reese, Chris Robb, Linda Roos, Chet Ruszczyk, Paul Schopis, Steve Senger, Pankaj Shah, John Streck, Martin Swany, Steve Wallace, Tim Ward, Linda Winkler, David Wood
Discussion regarding Working Group affiliations (Paul Schopis) - See document
• David Lassner from the GNC attended the meeting to elicit feedback on the strategic plan implementation procedure as well as to discuss concerns about having a multi-disciplinary group (DCN because dealing with technical and policy issues) reporting to the NTAC. All agreed to move forward with the DCN Working Group.
• DCN WG discussion included the following different points of view:
o One view is that it was OK to go with DCN WG under NTAC as a one-off but questioned whether the NTAC is the right group or whether the DCN working group should just be an advisory to the AOAC.
o The NTAC is where the discussions occur - the same community of people. Rather than having discussions in the Working Group would like to have a recommendation moving forward when the Working Group can bring it to the NTAC.
o Given the frequency of NTAC calls and the frequency of group meetings this is where the DCN discussions would originate. The detailed level of conversations will not happen at the AOAC.
o The Working Group should report to or be under the direction of the AOAC or another structure under the AOAC.
o When a Working Group reports to NTAC, what role does that give you towards the outpour of that group? Analogy would basically be a Steering Committee - at the charge of the Internet2 staff. The practical level of appeal only provides a means of mechanism to get to the AOAC and should not only be through this group. The NTAC is there merely to provide a mechanism for the working group function.
o Chair of the working group should be a member of the NTAC.
o The GNC is just getting working groups on their radar. The groups all work in different ways and interconnect in different ways. Would be interested in hearing the perspective of the NTAC keeping in mind that the NTAC shouldn't have to oversee any group that they don't want to. If there are working groups in the technical area that the NTAC does not want to be involved with GNC can have them report directly to the AOAC.
o To date, any work the NTAC has been involved in has been at the request of Internet2 staff as support.
o Legacy working groups are in all areas - we should just flag them and report back to the David Lassner of the GNC. AOAC Legacy groups: Multicast and IPv6. David Lassner to update the list and send to the group.
o If you are willing to do the working groups, that would be great - trying to be sensitive to the fact and will try to find another way.
o Need to remember that the councils are advisory to the board and will come to any one of the working groups with questions needing answers.
Community feedback on operational issues (Dave Reese):
• Dave Reese expressed concern that some technical issues have been approved without as much vetting as the community may have preferred.
Slides:
o Agility is important
• Cannot be overly burdened by process
• But must be inclusive
o What is a representative 'voice'
o The entire community?
• A subset? A majority? What subset?
• The users of a service? (current, future?)
• Cross-working group interrelationships.
• We need to have a lightweight process that Internet2 can use to bring technical issues to this group. We don't really have a defined process of sharing information and bringing issues to the table. Need to raise issues and be able to obtain feedback quickly. Need to identify a mechanism for communicating issues to those unable to attend meetings, as well. If there is perception that there is not enough feedback, then what we are doing is not effective.
• Need to think about the lines of communication. Both Internet2 and the connectors have responsibility. We need to stop working on issues ad-hoc.
• Perhaps we can find a best practice model within the community or use as a straw model. Could have a very simple starting point such as a very succinct subject line, i.e., 'APPROVAL NEEDED', etc. We can do that very easily to obtain feedback on an issue as a first step.
• Everyone please document and forward any examples of how to accomplish this (that is, best practices) and send to Paul Schopis and Ana Preston.
Update from Internet2 / Head Room discussion (Chris Robb) - See document
• The below document was circulated that outlined what we consider to be the practice of maintaining headroom on the IP network.
Internet2 currently follows these guidelines:
1. On a weekly basis, monitor utilization of each backbone segment to identify trends where the predictable traffic exceeds 20% (typically 2Gbps). Identify any segment that has regular peeks above 20% for discussion in weekly staff meetings and consider traffic-engineering, migration of predictable flows to the Dynamic Circuit Network [DCN], and other load balancing activities. If possible, move loads to less-utilized links.
2. When the predictable traffic level reaches 25-30% on a given segment, immediately begin the process of augmenting the affected backbone segment with an additional 10Gbps of capacity [which typically can be accomplished within a week or so.)
• Headroom Discussion:
o Is there a period of time to monitor the threshold? It's not that clearly defined. Anecdotally if it goes away in 2-3 weeks it may fall off the radar screen. Getting an agreement from the community on what those thresholds should be would be great. Traffic levels are public information and the intent is to have a web page where folks can pull up this data. The threshold is unpredictable.
o We are more interested in protecting research traffic. We should view the connection for research purposes. Don't believe that research traffic is predictable. All traffic is routed the same way on the backbone. Should be looking at packet loss as well.
o Can we get the pieces of data verified? Absolutely - Chris Robb to share a sample report. This will be a very initial straw man for comments only. Adding other metrics to this is very good and will be a main part of this.
o We are interested in using this as a guideline for the GigaPoPs and on the campus. This is very important work.
40 Gig Testing Dan Magorian - See document
• Interop state test: Fujitsu had prototype interfaces but no 40G applications for testing. They contacted NASA since they have done a lot of Perf testing and has a history of going back to 10 and 1G.
• Used the existing Fujitsu DWDM system. Borrowed Juniper's T16 routers - 4 x 10 on top and OC768 at the bottom. The OC768 operates fine. There was a surprising Juniper PIC failure - hardware problem, but overall everything looked pretty well.
• Complexities are identified on the bottom left of the schema but not addressing any, i.e., how do you deal with flows bigger than 10G, GEANT cards, etc.
• In the process of writing this up.
• If purchased, how much if you bought it all? Assuming no separate router, you are looking at approximately 2M.
Chair final nominations and election (Michael Lambert)
• The group unanimously supported Paul Schopis' re-election as chair of the NTAC.