> Mark Andrews escribió: > >> Well, longest prefix match is kind of useful in some scenarios i think. > >> > >> Imagine a site that is multihomed to two ISPs and has two PA address block > s. > >> > >> Now, longest prefix match ensures that when a node of the multihomed > >> site wants to contact any other customer of its own isps, it does > >> perform the correct source address selection and that is likely to be > >> critical for the communication to work, especially if the isps are doing > >> ingress filtering (i am assuming that the intra site routing of the > >> multihomed site will preffer the route through the ISP that owns the > >> prefix contained in the destiantion address) > >> > >> Even though this is one case and the problem is more general, i tend to > >> think that this is an importnat case and things would break more if this > >> rule didn't exist > >> > >> Regards, marcelo > >> > > > > Section 6 Rule 9 is DESTINATION address selection. > so, are you suggesting to keep rule 8 of source address selection > (longest prefix match) and remove rule 9 of destiantion address > selection (longest prefix match)? > > btw, an analysis of some multihomed scenarios and the impact of longest > prefix match can be found at > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06.txt. > > From the draft, it is possible to see that it helps, but not that much > and it is probably worth having better support. But i am not sure we > should simply remvoe it with an errata. IMHO, we should actually solve > this problem and provide a solution for multiprefixed sites I'm all for solving the real problem. Longest match isn't the solution. It only helps if you have a PA address and one of the destinations has the same ISP. For all other cases it introduces a bias that has no science about it. In otherwords it introduces bias in 99.99999% of cases. It helps in 0.00001% of cases (and this is a generous estimate). Mark > regards, marcelo > > It > > provides absolutely no help when attempting to distingish > > a multi-homed destination that is not with your current > > ISP. It also won't help once your current ISP has more > > than one prefix. It doesn't help with PI clients connected > > to your current ISP. > > > > It biases what should be a random selection. > > > > There is no science that says a /30 match is better than a > > /28 or a /8 match. > > > > If one really wants to have directly connected clients of > > your ISP match then get a appropriate feed of prefixes and > > use it to build appropriate tables. We have the technology > > to distribute sets of prefixes. > > > > Just don't attempt to have longest match do the just because > > it can't do it except for PA address and even then only > > when your ISP has a single prefix. For any other senario > > it is biased garbage. > > > > > >> Mark Andrews escribió: > >> > >>> This rule should not exist for IPv4 or IPv6. Longest match > >>> does not make a good sorting critera for destination address > >>> selection. In fact it has the opposite effect by concentrating > >>> traffic on particular address rather than spreading load. > >>> > >>> I received a request today asking us to break up DNS RRsets > >>> as a workaround to the rule. Can we please get a errata > >>> entry for RFC 3484 stating that this rule needs to be ignored. > >>> > >>> Mark > >>> > >>> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> IETF mailing list > >> IETF@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf > >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf