[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6 multihoming and route filters



On Wed, Jul 05, 2006 at 08:55:19PM +0200, Iljitsch van Beijnum wrote:
> On 5-jul-2006, at 18:47, bmanning@vacation.karoshi.com wrote:
> 
> >actually, i think that Christian is dead-on.  the IETF should not  
> >presume to know or dictate "best practices" for routing - esp. when  
> >they have no idea what may be my drivers.  the best/only thing they  
> >should do is describe -HOW- it is done and -WHAT- are the  
> >boundaries for the choices ...
> 
> This argument would be considerably more persuasive if there was some  
> other group picking up the slack. The RIRs explicitly reject any  
> responsibility for routing, although by creating address policies  
> they impose important limits on what can be done here. Groups like  
> NANOG, APRICOT and RIPE (as opposed to the RIPE NCC) are in the  
> business of spreading best practices, but not in the business of  
> creating them.

	ah, but there are other groups picking up the slack...
	e.g. your ISP and their peers.
 
> And since the IETF is (hopefully) the place where internet routing is  
> best understood an the IETF has historically always had an  
> operational component (hence the existence of this very working  
> group), I think the IETF can't shy away from at the very least  
> discouraging harmful practices, and preferably also pointing out  
> tradeoffs that exist between different choices and recommend best  
> practices if such can be identified.

	er, not clear that the IETF is the place where internet
	routing is best understood... except from a theory standpoint.
	there is a distinct difference between a specification (IETF),
	an implementation (ZEBRA), and operation (your ISP)...  IMHO
	it is none of the IETF's business to tell me or your ISP how
	it can and can not run its business.  That said, I have no
	problem with the IETF telling implementors that there is a 
	possibility of creating a potentially unmanageable number of 
	potential routing entries.  Such advice might also mention the
	fallicy of a "global routing table" and suggest that operators
	may need the tools to manage the number of route entries based
	on the current limits of their particular implementations.
	The SPEC's (IMHO) should not be hostage to current implementation
	limitations. and the SPEC designers should not attempt to dictate
	or police how i operate my network... Their influence should 
	extend as far as the implementors.   
> 
> >Making value judgements in standards is nearly never a good idea.
> What is a standard other than a big fat value judgement?

	your view of standards is apparently different than mine.

	i guess that in the end, if the IETF codifies this, we are 
	back to classfull routing and hardcoding address boundaries...
	which turns back years of attempts to  remove arbitrary bounds
	checking that was implemented in IPv4 in the early days ... 

	those who refuse to learn from history are doomed to repeat it.

--bill