[ppml] Just say *NO* to PI space -- or howto make it less destructive

[Howard, W. Lee]

Can't stand HTML email. 

Matt Petach wrote: 
>>Dampening works, for the value of "works" which equals "suppressing
new 
>>(better?) information about the path to a network," which is often
equal
>>to "misrouting data because a new path was not calculated."  If,
>>following
>>this proposed policy, aggressive dampening becomes commonly required
by 
>>operators to maintain their networks, it might have a bearing on
support
>>for this policy.
>Concern was raised about end networks changing routing state too
quickly
>for modern CPUs to handle; the way we handle that today is to dampen 
>successive transitions once they reach a certain threshold level.  I
see no
>reason why the current mechanism in use today in the IPv4 world should
>not work just as well on the IPv6 network.
	
The upper bound of number of prefixes is higher.  
There's a difference between a flap and a topology change.
	
>>If it takes six months of testing to be confident in a new core
router,
>>and you replace 5% of your routers every week, and you ignore all
other 
>>maintenance, you could replace your core in a year.  Another year for
>>distribution and edge.  Any other kinds of devices take another year,
>>for testing and rollout.   That's assuming you employ as many
engineers 
>>as needed, and ignore other work.
>	The point I was making is that if we limit IP allocation
policies
>	based on hardware upgrade cycles, we shackle ourselves to 
>	the ISP that decides that they should be able to run just fine 
>	with their IGS or AGS+, and therefore no additional prefixes
>	can be allocated because they're unwilling _or_ unable to
>	upgrade.

Are there ISPs whose upgrade cycle has prohibited them from 
replacing their AGS+en?  My example suggested 2-3 years from the 
date a box is released before the entire network can be upgraded
to it.  One consideration for policy is whether we can see a 
problem far enough out to prevent it.  The implied question here
is, "If IPv6 adoption following 2005-1 is fast, will we be able 
to either change the policy or deploy fast enough routers before
breaking things?"  Your answer may vary, but it seems to me to
be a reasonable question.
	
>	If we start putting limits on what can be assigned due to 
>	concerns about what some providers may be unwilling to 
>	upgrade in their core, are we also going to entertain 
>	proposals to limit IPv4 allocations so that those selfsame 
>	providers won't have to upgrade their IPv4 routers either?
>	
>	Let's be realistic.  We don't have any limits on how much 
>	IPv4 deaggregation we'll support, 

We don't?  We can accept 2^24 prefixes?

> we just trust the routers
> to scale up to support the growth--why are we attempting
> to treat IPv6 differently?  Do we not expect IPv6 to take 
> over for IPv4 in the forseeable future? 
	
It is mathematically possible, though the probability is debatable,
that the number of IPv6 prefixes will grow faster than router
capacity.  Is there a point where the routers released 2-3 years
ago can't handle today's routes?
	

>>> Provider independence is here already, period.  It's too late to try
>>> to put 
>>> the horse back in the barn
>> ?
> I mean 'In the IPv4 internet of today, multihoming is a fact of 
> life, and is expected by businesses.  If IPv6 is ever intended 
> to be more than an academic mastubatory exercise, the
> policies associated with IPv6 allocations will need to support
> a similar or better level of provider independence for businesses 
> as the existing IPv4 allocation policies.'

I know I'm old-fashioned, but I like to see professional language
in a professional setting.  But thank you for clarifying that point.

	
> To that end, yes, I support 2005-1.  
> IPv6 without provider independent allocations is broken,
> and will never be widely adopted.  2005-1 is one possible
> suggestion on how to fix it.  I support 2005-1 as a well
> thought out means to fix an otherwise broken protocol. 

OK, now I understand your position.  Thank you.  	


>> I've never
>> tried rocket science, but I know of some nuclear physicists who find 
>> consensus-building to be challenging.

> That's nice.  If we don't come to consensus and move
> forward, this rocket is never going to lift off.  And if IPv6
> doesn't take off, then we'll see some *real* challenges 
> when IPv4 space starts getting scarce, and the black
> market for v4 space starts to solidify.

There isn't even consensus on that.  Intelligent people have
different expectations of this protocol; some think the 
rocket will explode.  
	
> I'm supporting 2005-1 because I'd prefer to see those
> prefixes handled on the IPv6 internet.  It sounds like
> you'd prefer to say 'no' to IPv6 PI space, and instead
> have your routing slots consumed by IPv4 prefixes 
> instead, and that's certainly your choice.  

I'm not sure why prefixes in IPv6 are better than in 
IPv4, but it doesn't much matter to me: I only have a
default route.

I don't have a strong opinion on 2005-1.  But I like
threads that support or oppose a specific policy proposal,
and it seemed like this one was becoming a global rant
of "PI Good!" versus "PI Bad!"

I'm happy now, thanks.

> Matt

Lee