North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MCI and SprintLink are partitioned (fwd)
>> >> . are all three (four?) NAPs really being used >> > Yes. for some value of "used". >> That answer is close to meaningless. Please give me your metric. > > Since they are neutral exchanges, w/o policy, I can only > speak for for my project. I can't speak for any of the > other sites that are attached. The RA has active peering > sessions at all the NAPS. We do not have active peering > sessions with some of the NSP's which are receiving NSF > funding through the old regionals. > > What is your definition of used? Operational traffic with real users crossing the NAP. I don't care (in this context) whether the RA has active peering sessions. That's network management, not use. >> >> . Is there any evidence that the NAPs are really backing each other >> >> up? >> > Not sure this is possible. Perhaps the better question is, >> > are providers using the NAPs to back each other up. >> >> Let me rephrase. How is the NSF programmatic goal being met of creating >> three NAPs for redundancy purposes to avoid compartmentalization of >> the U.S. R&E portion of the Internet, and how is that being verified? > > That question can't be answered by the NAP operators, since > they don't monitor traffic. You have to ask the NSP's. I was/am asking NANOG. Was it your understanding that I sent a personal message to you? >> >> . do we have some regular examples from *any* site A initiating a >> >> connection from A to B, A to C, and A to D, where the three are >> >> verifiably (via traceroute, I guess) would traverse different NAPs >> >> (and hopefully only one each)? >> > Yes. >> >> So, where are they? Say, can you give me two examples for such an >> A-B/C/D scenario? One from SDSC, one from NSF. Your answers are a bit >> too flippant to me. Sorry. > > Anywhere to WELL.COM (via the PB NAP) %upeksa[70]/usr/people/hwb 10:50: tr WELL.COM traceroute to WELL.COM (206.15.64.10), 30 hops max, 40 byte packets 1 tigerfish.sdsc.edu (132.249.22.11) 8 ms 8 ms 7 ms 2 mobydick.cerf.net (198.17.46.153) 3 ms 3 ms 4 ms 3 agis.sprint.ep.net (192.157.69.19) 69 ms 69 ms 69 ms 4 trenton-T3.agis.net (204.130.243.49) 72 ms 72 ms 73 ms 5 santaclara.agis.net (204.130.243.34) 83 ms 82 ms 81 ms 6 * * * 7 well.com (206.15.64.10) 90 ms * 87 ms %upeksa[71]/usr/people/hwb 10:51: > Anywhere to NAP.NET (via the AADS NAP) %upeksa[71]/usr/people/hwb 10:51: tr nap.net traceroute to nap.net (204.95.160.2), 30 hops max, 40 byte packets 1 tigerfish.sdsc.edu (132.249.22.11) 7 ms 7 ms 7 ms 2 mobydick.cerf.net (198.17.46.153) 10 ms 4 ms 8 ms 3 longboard.cerf.net (198.17.46.152) 4 ms 5 ms 10 ms 4 la-sd-ds3.cerf.net (134.24.115.200) 7 ms 7 ms 9 ms 5 ucop-sf-ds3-smds.cerf.net (134.24.9.112) 25 ms 27 ms 29 ms 6 sl-ana-3-S2/6-T1.sprintlink.net (144.228.73.81) 35 ms 36 ms 35 ms 7 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 89 ms 91 ms 90 ms 8 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 91 ms 94 ms 92 ms 9 sl-stk-5-F0/0.sprintlink.net (144.228.40.5) 97 ms 89 ms 91 ms 10 144.228.10.53 (144.228.10.53) 89 ms 89 ms 89 ms 11 sl-chi-5-F0/0.sprintlink.net (144.228.50.5) 89 ms 92 ms 93 ms 12 sl-inetconn-1-S0-T1.sprintlink.net (144.228.55.114) 100 ms 101 ms 100 ms 13 beta.inc.net (204.95.160.2) 96 ms 100 ms 101 ms %upeksa[72]/usr/people/hwb 10:51: > Anywhere to CERF.NET (via the Sprint NAP) %upeksa[72]/usr/people/hwb 10:52: tr stanford.edu traceroute to stanford.edu (36.56.0.151), 30 hops max, 40 byte packets 1 tigerfish.sdsc.edu (132.249.22.11) 7 ms 8 ms 9 ms 2 mobydick.cerf.net (198.17.46.153) 56 ms 4 ms 4 ms 3 longboard.cerf.net (198.17.46.152) 6 ms 3 ms 3 ms 4 la-sd-ds3.cerf.net (134.24.115.200) 7 ms 8 ms 8 ms 5 ucop-sf-ds3-smds.cerf.net (134.24.9.112) 26 ms 30 ms 29 ms 6 border3-hssi1-0.SanFrancisco.mci.net (149.20.64.9) 37 ms 29 ms 33 ms 7 borderx1-fddi0-0.SanFrancisco.mci.net (204.70.2.164) 28 ms 29 ms 27 ms 8 barrnet.SanFrancisco.mci.net (204.70.158.102) 35 ms 29 ms 33 ms 9 su-tk.wr.bbnplanet.net (192.31.48.1) 31 ms 32 ms 30 ms 10 sunet-gateway.stanford.edu (198.31.10.1) 30 ms 29 ms 32 ms 11 Argus.Stanford.EDU (36.56.0.151) 32 ms 31 ms 33 ms %upeksa[73]/usr/people/hwb 10:52: %upeksa[73]/usr/people/hwb 10:52: tr nsipo.nasa.gov traceroute to nsipo.nasa.gov (128.102.32.20), 30 hops max, 40 byte packets 1 tigerfish.sdsc.edu (132.249.22.11) 7 ms 7 ms 7 ms 2 mobydick.cerf.net (198.17.46.153) 4 ms 3 ms 3 ms 3 sl-pen-2-F4/0.sprintlink.net (192.157.69.9) 75 ms 235 ms 71 ms 4 sl-chi-3-H2/0-T3.sprintlink.net (144.228.10.38) 95 ms 95 ms 95 ms 5 sl-chi-6-F0/0.sprintlink.net (144.228.50.6) 95 ms 95 ms 95 ms 6 144.228.10.54 (144.228.10.54) 134 ms 134 ms 134 ms 7 icm-fix-w-H2/0-T3.icp.net (144.228.10.22) 137 ms 140 ms 137 ms 8 arc-nas-gw.arc.nasa.gov (192.203.230.3) 138 ms 139 ms 136 ms 9 nsipo.arc.nasa.gov (128.102.32.20) 138 ms 137 ms 137 ms %upeksa[74]/usr/people/hwb 10:53: > Of course your query presumes symetric routing, which is > the exception rather than the rule these days. > > >> >> . Are there routing stability reports accessible online from the RA >> >> (or whoever else feels responsible for this) that graph fluctuations >> >> at the NAPs, including correlation among them? What are the quality >> >> metrics for routing stability? >> > Being defined. >> >> To be publicly discussed, finished, and available by ...? > > Check the RPS schedule w/in IETF. > >> >> . Do all the NAPs provide online statistics? >> > No. >> >> Why not? Will that change? My understanding is that the NAP service >> providers have contractual obligations for some statistics. I know there >> is disagreement about what stats are appropriate, but is not there a >> contractual requirement for at least some baseline? > > I don't think so. > >> >> . Are the NAP and RA regular reports to NSF publicly (hopefully via >> >> the Web) available? >> > http://info.ra.net/papers have the annual report/plan papers >> >> Are there any more reporting requirements (quarterly? Monthly?). >> Waiting a year per report in such a changing environment strikes me as >> a bit long. > > There are quarterly reports, which are not yet online. > It's a good suggestion and I'll investigate. > >> If I wanted a comprehensive snapshot of the current state of the >> NAP-union, where/how would I get it. > > Not enough info. > You can dump the in-addr zones to discover who has been assigned > an IP address > You can see who has signed an MPLA, if they exist. > You can check the CERFnet MAP > You can check out http://info.ra.net/div7/ra/ep.html > > All of these have different viewpoints on the "NAP-union" > and none have what I think you want. Where can I find mapping information from the in-addr zones to attributes like service providers, or even simple things like countries (that uses a consistent data base)? >--bill
|