Re: RFC 3484 Section 6 Rule 9

> 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
> >> IETF@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf
> >>     
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org