Mark, Firstly let me say +1 to the view that this is absolutely notsuitable for handing as an erratum; I'm quite sure it was aconsensus decision of the WG. Secondly, I am a bit surprised that it's written to apply toIPv4 - that does seem inappropriate. My comments below areapplicable to IPv6. On 2008-06-03 02:24, Mark Andrews wrote:>> 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. Which is, I think, why it's the second-to-last rule. However, italso helps if one of the prefixes is the local ULA; since we don'twant to code address semantics when we can avoid it, it is the bestway to ensure that ULA addresses are preferred for internal traffic. > 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). In IPv4 that may be so. In the IPv6 model, which is still PA-basedand multiprefix, it's far from true. BTW, the text also says: "Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses." Regardless, IMHO, the way to deal with this is via WG debate onthe draft Marcelo mentions. Brian > > 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 listIETF@xxxxxxxxxxxxx://www.ietf.org/mailman/listinfo/ietf