Mark,
Firstly let me say +1 to the view that this is absolutely not
suitable for handing as an erratum; I'm quite sure it was a
consensus decision of the WG.
Secondly, I am a bit surprised that it's written to apply to
IPv4 - that does seem inappropriate. My comments below are
applicable 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, it
also helps if one of the prefixes is the local ULA; since we don't
want to code address semantics when we can avoid it, it is the best
way 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-based
and 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 on
the 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 list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf