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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf