Re: MCI and SprintLink are partitioned (fwd)

[hwb () upeksa sdsc edu (Hans-Werner Braun)]

> > > >  . 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