> 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. 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 > > > > -- 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