MCI and SprintLink are partitioned (fwd)
Hans-Werner Braun
hwb at upeksa.sdsc.edu
Wed Oct 4 17:56:24 UTC 1995
>> >> . 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
More information about the NANOG
mailing list