[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-addr-select-ps-02
-----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. 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.
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?
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-----