Re: RFC 3484 Section 6 Rule 9

[Mark Andrews <[e-mail]>]

> 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: [phone]                 INTERNET: [e-mail]
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf