[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-addr-select-ps-02



On 2008-01-28 21:27, Fred Baker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian, I'm very perlexed by how you come to that conclusion. Maybe you
> can fill me in.
> 
> The text of rule 9 is:
> 
>    Rule 9:  Use longest matching prefix.
>    When DA and DB belong to the same address family (both are IPv6 or
>    both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
>    CommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
>    CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
>    then prefer DB.
> 
> In the Internet, regardless of whether the prefixes are PA or PI, there
> is little if any reason to believe that any two customers chosen at
> random have the same provider. 

Of course - but there are circumstances where "at random" doesn't apply.
One case is  that inside an enterprise network that operates more
than one prefix, topology is likely to follow addressing. Another
example: in a geographical area with one dominant provider,
local-to-local traffic isn't quite random. Similarly, thinking longer
term, if any kind of municipal IXP starts handing out prefixes,
local-to-local traffic isn't quite random. For non-local traffic,
the rule *is* effectively a random choice. So as a rule quite far
down in the list, this seems more likely to do good than harm. That's
all I'm saying.

> I have appended four traceroutes for your
> (anecdotal) consideration in support of the point - I am served by Cox,
> but you use google mail (which apparently has multiple ISPs), Florian is
> reached through interscholz.net, ops.ietf.org is reached through NTT,
> and ietf.org is reached through AT&T. I would encourage you to spend an
> hour picking random domain names out of your mail spool and traceroute
> to them. If your view of the world is at all similar to mine, you will
> find your path going through your network, your provider, their
> provider, and their network, and potentially multiple networks in
> between the two providers.

That is certainly true.

> 
> If the two communicating networks have different upstream providers,
> what on God's Green Earth leads you to believe that they would have a
> common PA prefix? If they don't have a common prefix, exactly how does
> rule 9 help?

In no way, of course.

    Brian
> 
> 
> 
> 
> On Jan 27, 2008, at 12:39 PM, Brian E Carpenter wrote:
> 
>> On 2008-01-28 00:26, Florian Weimer wrote:
>>> I've also noticed that the draft fails to mention that Rule 9, when
>>> applied by most of the client population on the Internet, results in
>>> worse performance than no destination address sorting at all.
>>>
>>> Rule 9 might offer a significant advantage in private deployments which
>>> use non-IANA address allocation.  In other cases, routing is typically
>>> not hierarchical at all, so that the length of the matching address
>>> prefix is meaningless.
>>
>> Not true if the sites concerned are both using PA space and
>> happen to have the same ISP. We still have hopes that PA space will
>> be predominant in IPv6, despite the PI heresy.
>>
>> Can you describe cases in which this rule is actively harmful?
>>
>>    Brian
> 
> 
> 
> [Fred-Bakers-Computer-3:~] fred% traceroute mail.google.com
> traceroute: Warning: mail.google.com has multiple addresses; using
> 209.85.199.18
> traceroute to googlemail.l.google.com (209.85.199.18), 64 hops max, 40
> byte packets
>  1  10.32.244.217 (10.32.244.217)  1.570 ms  1.153 ms  1.104 ms
>  2  wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1)  87.274 ms  49.568
> ms  48.215 ms
>  3  68.6.13.101 (68.6.13.101)  57.624 ms  47.359 ms  38.188 ms
>  4  68.6.13.45 (68.6.13.45)  33.014 ms  32.715 ms  32.097 ms
>  5  paltbbrj02-ae0.0.r2.pt.cox.net (68.1.0.235)  51.490 ms  52.489 ms 
> 41.434 ms
>  6  209.85.130.2 (209.85.130.2)  125.613 ms  122.277 ms 209.85.130.6
> (209.85.130.6)  129.134 ms
>  7  66.249.95.135 (66.249.95.135)  110.462 ms  124.537 ms  116.237 ms
>  8  209.85.250.144 (209.85.250.144)  128.569 ms  130.422 ms  134.411 ms
>  9  64.233.174.131 (64.233.174.131)  145.547 ms 64.233.174.129
> (64.233.174.129)  132.366 ms  118.576 ms
> 10  * 209.85.248.254 (209.85.248.254)  125.765 ms  138.378 ms
> 11  rv-in-f18.google.com (209.85.199.18)  118.186 ms  109.112 ms *
> [Fred-Bakers-Computer-3:~] fred% traceroute
> [Fred-Bakers-Computer-3:~] fred% nslookup 209.85.130.2
> Server:         68.105.28.13
> Address:        68.105.28.13#53
> 
> Non-authoritative answer:
> *** Can't find 2.130.85.209.in-addr.arpa.: No answer
> 
> Authoritative answers can be found from:
> 
> [Fred-Bakers-Computer-3:~] fred% traceroute deneb.enyo.de
> traceroute to deneb.enyo.de (212.9.189.171), 64 hops max, 40 byte packets
>  1  10.32.244.217 (10.32.244.217)  1.528 ms  1.131 ms  1.126 ms
>  2  wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1)  12.350 ms  10.628
> ms  10.509 ms
>  3  68.6.13.101 (68.6.13.101)  14.043 ms  13.115 ms  12.642 ms
>  4  68.6.13.45 (68.6.13.45)  18.518 ms  17.599 ms  16.974 ms
>  5  paltbbrj02-ae0.0.r2.pt.cox.net (68.1.0.235)  33.845 ms  31.246 ms 
> 31.796 ms
>  6  so-1-2-2.mpr2.sjc2.us.above.net (64.125.29.126)  31.804 ms  32.963
> ms  29.991 ms
>  7  so-1-0-0.mpr1.lga5.us.above.net (64.125.26.142)  106.799 ms  104.833
> ms  106.786 ms
>  8  so-0-0-0.mpr1.lga5.us.above.net (64.125.27.237)  107.908 ms  109.646
> ms  107.201 ms
>  9  so-1-0-0.mpr1.ams1.nl.above.net (64.125.27.186)  192.188 ms  190.569
> ms  192.356 ms
> 10  pos-9-1.mpr2.fra1.de.above.net (64.125.23.253)  206.446 ms  201.130
> ms  201.177 ms
> 11  ge-9-7.er2b.fra1.de.above.net (64.125.23.210)  200.881 ms
> ge-9-4.er2b.fra1.de.above.net (64.125.23.206)  199.369 ms
> ge-9-7.er2b.fra1.de.above.net (64.125.23.210)  202.015 ms
> 12  c12gsr-5-02.intx.fra.interscholz.net (62.93.193.62)  201.813 ms 
> 208.735 ms  198.146 ms
> 13  c12gsr-3-02.z10a.stg.interscholz.net (85.236.200.229)  205.121 ms 
> 207.205 ms  204.092 ms
> 14  ge-knd-lfnet.z10.stg.interscholz.net (85.236.201.130)  204.035 ms 
> 201.747 ms  209.954 ms
> 15  dsl-gw.ispeg.de (212.9.161.26)  202.581 ms  201.286 ms  200.045 ms
> 16  dsl.enyo.de (213.178.172.64)  227.865 ms  237.674 ms  228.145 ms
> 17  * *^C
> [Fred-Bakers-Computer-3:~] fred% traceroute ops.ietf.org
> traceroute to ops.ietf.org (147.28.0.62), 64 hops max, 40 byte packets
>  1  10.32.244.217 (10.32.244.217)  1.320 ms  1.063 ms  1.030 ms
>  2  wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1)  15.270 ms  14.536
> ms  12.443 ms
>  3  68.6.13.117 (68.6.13.117)  17.136 ms  13.310 ms  13.317 ms
>  4  68.6.13.49 (68.6.13.49)  17.679 ms  22.767 ms  19.230 ms
>  5  paltbbrj01-so000.0.r2.pt.cox.net (68.1.0.199)  43.538 ms  41.442 ms 
> 43.887 ms
>  6  ae-1.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.33)  48.245 ms 
> 42.201 ms  47.455 ms
>  7  p64-0-0-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.22)  72.543 ms 
> 66.362 ms  81.955 ms
>  8  p16-0-0-0.r05.sttlwa01.us.bb.gin.ntt.net (129.250.3.11)  66.021 ms 
> 72.685 ms  65.238 ms
>  9  p1-0.psg.sttlwa01.us.bb.gin.ntt.net (129.250.11.42)  69.071 ms 
> 64.404 ms  64.297 ms
> 10  * *^C
> [Fred-Bakers-Computer-3:~] fred% traceroute ietf.org
> traceroute: Warning: ietf.org has multiple addresses; using 209.173.53.180
> traceroute to ietf.org (209.173.53.180), 64 hops max, 40 byte packets
>  1  10.32.244.217 (10.32.244.217)  1.581 ms  1.118 ms  1.095 ms
>  2  wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1)  18.068 ms  12.854
> ms  14.602 ms
>  3  68.6.13.101 (68.6.13.101)  12.794 ms  11.780 ms  14.710 ms
>  4  68.6.13.45 (68.6.13.45)  20.709 ms  28.882 ms  27.386 ms
>  5  fed1dsrj02-so010.0.rd.sd.cox.net (68.6.8.13)  18.876 ms  17.096 ms 
> 22.599 ms
>  6  tbr1.la2ca.ip.att.net (12.122.104.38)  79.486 ms  79.698 ms  79.613 ms
>  7  tbr2.la2ca.ip.att.net (12.122.9.146)  80.148 ms  80.635 ms  84.841 ms
>  8  tbr2.sl9mo.ip.att.net (12.122.10.13)  82.377 ms  82.078 ms  96.295 ms
>  9  tbr1.sl9mo.ip.att.net (12.122.9.141)  91.041 ms  81.589 ms  78.615 ms
> 10  tbr1.wswdc.ip.att.net (12.122.10.29)  80.846 ms  76.828 ms  78.812 ms
> 11  12.123.8.193 (12.123.8.193)  91.766 ms  77.840 ms  77.159 ms
> 12  12.118.28.10 (12.118.28.10)  79.630 ms  82.614 ms  79.309 ms
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFHnZH+bjEdbHIsm0MRAozqAKCCXuLKmV+8JiXtUCpxnKOITCxnVgCfYtud
> i89+S4Fxu8roS5m85TwYw7o=
> =7HEA
> -----END PGP SIGNATURE-----
>