MCI and SprintLink are partitioned (fwd)

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