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=EF=BF=BD:
Well, longest prefix match is kind of useful in some scenarios i thi=
nk.
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=
=20
site wants to contact any other customer of its own isps, it does=20
perform the correct source address selection and that is likely to b=
e=20
critical for the communication to work, especially if the isps are d=
oing=20
ingress filtering (i am assuming that the intra site routing of the =
multihomed site will preffer the route through the ISP that owns the=
=20
prefix contained in the destiantion address)
Even though this is one case and the problem is more general, i tend=
to=20
think that this is an importnat case and things would break more if =
this=20
rule didn't exist
Regards, marcelo
=20
Section 6 Rule 9 is DESTINATION address selection.
so, are you suggesting to keep rule 8 of source address selection=20
(longest prefix match) and remove rule 9 of destiantion address=20
selection (longest prefix match)?
btw, an analysis of some multihomed scenarios and the impact of longes=
t=20
prefix match can be found at=20
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06=
=2Etxt.
From the draft, it is possible to see that it helps, but not that muc=
h=20
and it is probably worth having better support. But i am not sure we=20
should simply remvoe it with an errata. IMHO, we should actually solve=
=20
this problem and provide a solution for multiprefixed sites
=20
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.
It's wrong on a global perspective. It's wrong on a intra-site
perspective. For PA you want to get into bands that a are
multi-bit wide. e.g. /20-/47, /48-/63, /64-/128.
longest match does nothing to help selecting between ISP's that are
not in common with you.
longest match does nothing to help intra ISP.
longest match does nothing to help intra-site.
longest match does nothing to help on the link.
It has negative impacts in all the above situations as address
which should be treated as equal no longer are.
longest match does a crude approximation of the band selection
above and also has negative consequences when is doesn't
discriminate between the bands.
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
=20
Mark
=20
=20
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.
=20
=20
Mark Andrews escribi=EF=BF=BD:
=20
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
=20
=20
=20
--------------------------------------------------------------------=
----
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf