> 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. 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).
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
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/ietf
> >>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
IETF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
