Date: Thu, 28 Mar 2024 12:28:10 +0000 (UTC) Message-ID: <1892685736.6317.1711628890580@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6316_1901442709.1711628890580" ------=_Part_6316_1901442709.1711628890580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
NTAC Peering Working Group
1/21/08
In attendance; Jeff Bartig, David Farmer, Ron Hutchins, Caren Litv=
an, Ana Preston, Chris Robb, Linda Roos, Paul Schopis, Joe St Sauver, Bob S=
tovall, Ryan Vaughn, Steve Wallace, Linda Winkler
Agenda
1. Quarterly technical update
2. International peering
1. Quarterly update
Previously, Matt Davy was the principle contact within the NOC for CPS-rel=
ated issues and those responsibilities have been transferred to Caren Litva=
nyi.
Caren talked about the current peers and showed the NOC page that contai= ns the utilization graphs. The NOC continues to work on the statistic= s to describe the traffic.
There group mentioned previous NTAC netflow data discussions. Stev= e Wallace will frame a question to the NTAC on sharing netflow data.
Caren encouraged the group to bring ideas regarding entities with which = to peer. She will pursue the ideas for peers. It may or may not= be possible to peer with the networks that people mention as peers have re= quirements such as volume requirements, etc.
Caren mentioned that Internet2 has an entry in peeringdb and that is the= mechanism for other networks to find Internet2. There is an internal= mailing list for peering (peering@internet2.edu). Caren, Steve Walla= ce, Rob Vietzke read the mail sent to that list.
It was explained that, when connecting to exchange points, we have only = one vlan, rather than one for v4 and one for v6. With this single con= nection and single vlan, there is no clean way to take v6 and connect to VR= F. All solutions for enhancing v6 via CPS were expensive, difficult o= r nearly impossible so it was decided that we would put v6 routes into comm= ercial VRF. It is not necessary to be v4 CPS customer in order to pee= r with v6. However, all connectors that want to retain v6 transit rou= tes will have to do v6 CPS. Internet2 won't list the connector as a C= PS customer on webpages if the connector only buys v6. It was also me= ntioned that, if a connector has a vlan for CPS v4 service, that vlan can a= lso be used for v6 although it is possible to have a separate vlan for v6.<= /p>
It was mentioned that there are issues around addressing and that it may= be time to consider getting provider independent addresses. Internet= 2 had proposed using this opportunity to encourage all to obtain provider i= ndependent addresses and had approached the NTAC with that plan. The NTAC i= ndicated that they disagreed with the plan. Most want to move to prov= ider independent addresses eventually but not right away.
NTAC has latest plan of record on the v6 migration (also included in the= se notes---see below). The document currently doesn't contain deadlin= es. The group suggested that timeframe be proposed to NTAC for a resp= onse.
Discussion ensued regarding queuing. Dave Farmer will frame a ques= tion to the NTAC regarding queuing.
As a final comment regarding CPS, it was emphasized that, if CPS is succ= essful, Internet2 can react quickly to increase the capacity of the network= .
Plan to Migrate Commercial IPv6 Peers from R&E VRF to CPS VRF
January 8, 2008
Background
One of the goals of the CPS project is to improve commercial IPv6 co=
nnectivity for our R&E connectors and members. In addition to pee=
ring with other network providers via IPv4, our presence at these public pe=
ering locations has enabled expanded and upgraded IPv6 connectivity. =
It was our intent to connect the commercial IPv6 peers to the traditional R=
&E network service (original instance of AS11537, with which all connec=
tors peer), however, due to a limitation in the Juniper VRF implement=
ation , we're recommending a different approach. Rather than have the=
R&E network peer with commercial IPv6 networks, we're recommending tha=
t the CPS peer with them. The CPS network would then contain all unic=
ast commercial traffic, both IPv6 and IPv4. The traditional R&E s=
ervice would contain non-commercial IPv6 and IPv4, as well as all IP multic=
ast traffic. Connectors may choose to BGP peer with the CPS for eithe=
r or both IPv6 and IPv4 commercial connectivity.
The net effect of connecting commercial IPv6 peers to the CPS network is= that for Internet2 Connectors to realize the improved IPv6 connectivity, t= hey will be required to establish a second BGP session with the Internet2 r= outer. This second session may be used for both CPS as well as the im= proved IPv6 connectivity, or either independently. All IP multicast c= onnectivity (both v6 and v4) will continue to be provide via the R&E ne= twork.
During discussions with the NTAC and the IU NOC, two additional issues w=
ere raised:
The desire for continued universal access to IPv6 performance measurement =
servers and the opportunity to aid in the migration from Abilene-allocated =
IPv6 prefixes to provider-independent prefixes for all Internet2 Conn=
ectors.
I've discussed the IPv6 server access issue with Chris Small and the NOC= . We identified three potential technical solutions: connecting each = server to a sub-interface that's associated with a blended VRF, connecting = each server to both VRFs (either by distinct physical interfaces or using v= LAN tags) and running a BGP demon, or connecting each server to both VRFs a= nd use policy routing to cause packets to return over the same interface th= ey entered.
We're also suggesting that we take this opportunity of coordinating a ch= ange with all IPv6 connectors to aid their migration from Abilene-allocated= IPv6 space to something the connectors can own and control, however this i= s not being considered a prerequisite to moving the connector to the CPS VR= F for commercial IPv6 connectivity. In other words, a connector whose= only IPv6 connectivity is through Internet2 (IP network and/or CPS) can us= e an IPv6 address allocation from the Internet2 block. Connectors tha= t are multiply homed have several choices: 1) use their own address s= pace from ARIN, 2) use a block from their other provider (Internet2 will NO= T announce that block via CPS) or 3) use blocks from each provider. E= ach approach has advantages and disadvantages; the Internet2 NOC can provid= e advice.
In addition to connectivity to peers of Internet2, the Internet2 network= also provides IPv6 transit. Internet2 purchases a small amount= of IPv6 transit for this purpose. During the migration of commercial= IPv6 routes to the CPS VRF, we'll also be moving the transit offering to C= PS VRF. This will allow Internet2 to take advantage of its multiple p= eering locations to secure more resilient IPv6 transit service.
Desired End-State
We're proposing the following end-state:
=E2=80=A2 The CPS VRF would exclusively present commerci=
al IPv6 (including IPv6 transit) and IPv4 unicast routes to Internet2 Conne=
ctors.
=E2=80=A2 The R&E VRF would exclusively presen=
t non-commercial IPv6 and IPv4 unicast routes as well as all multicast rout=
es to Internet2 Connectors
=E2=80=A2 Each Internet2 IPv6-enabled connector would ha=
ve at least an IPv6 peering with the CPS (for purposes of documentation, a =
IPv6-only CPS connector would not be advertised as a customer of CPS).
=E2=80=A2 A connector whose only IPv6 connectivity is th=
rough Internet2 (IP network and/or CPS) can use an IPv6 address allocation =
from the Internet2 block. Connectors that are multiply homed have sev=
eral choices: 1) use their own address space from ARIN, 2) use a bloc=
k from their other provider (Internet2 will NOT announce that block via CPS=
) or 3) use blocks from each provider. Each approach has advantages a=
nd disadvantages; the Internet2 NOC can provide advice.
=E2=80=A2 Internet2's IPv6-accessable performance measur=
ement servers would be accessible from both VRFs.
Tasks
1. Chris Small - determine method for providing universa=
l connectivity to IPv6 measurement servers. Suggest that this task pr=
oceed independently.
2. Caren Litvanyi enable IPv6 routing on the CPS VRF.
3. NOC (in coordination with Caren and Steve) communicat=
e with each IPv6 connector the needs to a) establish an IPv6 peering sessio=
n to the CPS, and b) if needed, to migrate to their own v6 prefix
4. Caren Litvanyi, after all #3 completed, start the mig=
ration of commercial IPv6 peers to CPS.