NTAC
3/4/08
In attendance: Jeff Bartig, Brian Court, Matt Davy, Leo Donnelly, Ken Lindahl, Caren Litvanyi, Bill Owens, Dave Pokorney, Chris Robb, Joe St Sauver, Steve Wallace, Linda Winkler, David Wood
Ken Lindahl chaired the meeting as Paul Schopis was attending an All Councils meeting.
Agenda
1. Next NTAC Call
2. Internet2 update
3. AOAC update
4. DCN Update
5. Peering Working Group
6. ARIN Issues Update
7. naval observatory update
8. RHCPP
1. Next NTAC Call
Ken, on behalf of Paul Schopis, asked if the April call should be postponed to the SMM and whether there were any issues needing attention at the face-to-face meeting? There were no responses to the questions.
2. Internet2 update
Chris Robb provided the Internet2 update:
-PNWGP connected to connected to the Ciena in SLC.
-MCNC brought up on CPS.
-There is going to be an upgrade to the Junipers at nine nodes of the backbone.
-Five connectors have contacted the NOC regarding the IPv6 transition to the CPS VRF The NOC has also contacted six connectors.
3. AOAC update
The AOAC met as part of the strategic planning session of all Advisory Councils held in Dallas Texas on March 3 & 4. The AOAC reviewed the draft strategic plan and the AOAC charter. The group felt the draft plan needed some refinement and all present agreed it is a work in progress and a living document. The Strategic Planning Committee spent a good deal of time clarifying intent of the original document as well as listening to feedback and suggestions. There was conversation around the AOAC mission and the AOAC reiterated the intention of using the NTAC to work through some of the technical issues anticipated to be dealt with in the next year. Additionally, there was some conversation about how historically the community has been more involved in the design and proof of concept of technologies used on the network. This has waned in recent years due to the demise of the ITEC program as well as the politics of recent years in a competitive environment.
The Strategic Planning committee will have a report on progress and some recommendations for the community at the spring member meeting,
4. DCN Update
Chris Robb provided a report.
-additional organizations connecting to the DCN
-moving the service to a sustainable service
5. Peering Working Group
-activities focused on peering with CPS VRF for IPv6
6. ARIN Issues Update
Dale will not be on the call as he's at a GENI design meeting, but sent this:
There is a meeting of ARIN in Denver April 6-9. There is discussion going on about the IPv4 Transfer Policy (2008-2) that people should give some attention to, there is still conversation about Legacy Outreach and Reclamation. The Transfer policy seems to be about putting process around how number space will be moved around once its gone. The problematic effects of this most likely are around the effects on the routing table. The other seems to be around how to get us all to participate, carrots being preferred to sticks for the most part. By the next meeting I should have time to look at these more.
7. naval observatory update
no report
8. RHCPP
Steve Wallace requested comments from the NTAC on the following probable requirements:
-anticipate the need to measure the RHCPP use of the network
-want to preserve ability to track RHCPP traffic in the backbone
-need to be prepared to do RHCPP peering
-would accept prefixes and creating new VRF to accept only RHCPP traffic
Discussion ensued including discussion of fish problems both at national and connector levels. Bill Owens offered to write a first draft of an NTAC response to the RHCPP VRF proposal presented by Steve.
Bill's email follows:
I volunteered to write the first draft of an NTAC response to the RHCP VRF proposal that Steve presented on today's call. Please comment, in particular if I've missed something that either makes this easier or harder than I've described. Also, please think about whether the last paragraph, with the alternative peering arrangement, should be included at this point or held in reserve as a response (the question being whether NTAC should be suggesting policy or only commenting on technical issues).
I dropped a discussion of whether the peering connection would carry any traffic at all (it won't, if all the RHCP's connectors have Internet2 connectivity, or Internet2 plus NLR, which I think is currently the case). That seemed too esoteric, and is a situation that could change over time.
Bill.
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
The NTAC has reviewed an initial proposal, presented by Steve Wallace, to solve the problem of allowing Rural Health Care Partcicipant (RHCP) connectivity between Internet2 and NLR without those two networks having a full reciprocal peering agreement in place. A primary driver for the proposal was the perceived need to exchange only RHCP traffic between the two backbones; that is, to allow all RHCP sites to communicate, but to prevent Internet2 members from reaching NLR RHCP sites and vice versa.
The proposal involves the creation of a new virtual routing and forwarding (VRF) instance on the Internet2 backbone; essentially, a new virtual IP network. Connections to this VRF would be limited to RHCP sites and the peering with NLR. Internet2 already has experience with VRF management for the Commercial Peering Service, though this configuration would add still more complexity to the Internet2 backbone configuration.
However, this configuration would have significant impact on Internet2 connectors. Some connectors already use VRF for internal purposes; most do not. All would be required to create a new VRF instance, which would connect to each RHCP site as well as Internet2. Each RHCP site would likely be required to configure two BGP peering sessions with the connector; one for general connectivity (R&E, or R&E and commercial traffic) and the other for RHCP-only connectivity. In the event that a campus participant was providing a connection to an RHCP through the campus network, they, too would need to build a VRF through their network.
If a connector did not wish to add the complexity of a VRF implementation, or was prevented from doing so by equipment capabilities or operational limitations, the only other choice would be a separate network for RHCP traffic built on additional Layer 2 or 1 facilities. This configuration would result in sub-optimal connectivity between the RHCP and the connector's other participants, and still require a complex edge configuration at the connection to Internet2. Either solution is likely to increase the costs incurred by the regional in providing the RHCP connectivity.
If the policy for peering between Internet2 and NLR were adjusted slightly, this situation could be avoided. Specifically, if non-RHCP Internet2 participants were allowed to reach NLR RHCP sites, and vice versa, it would suffice to limit the advertisements at the peering connection to just each backbone's RHCP participants, something that can be accomplished very simply.
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT