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 blocks. >> >> 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 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 >> _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf