[arin-ppml] Why should we do Proposal 121

[Charles O'Hern]

While I do support Proposal 121, I do have a concern/questions about Owen's first point.

On 12/8/10 5:04 PM, Owen DeLong wrote:
> I've been asked by a fellow AC member to spend some more effort documenting
> reasons we should enact proposal 121.
> 
> 1.	Current IPv6 policy is being interpreted to the detriment of ISPs that
> 	have subordinate ISPs. Subordinate ISPs should be able to get PA
> 	space from their upstreams equivalent to what they would be able
> 	to get directly from ARIN. Currently, ARIN is not allowing for the
> 	possibility that an ISP would reallocate /32s (or larger) to their
> 	subordinate ISPs.

I think it is important to be careful here about two things.
1) While removing any obstacles or discouragement from subordinate ISPs receiving PA space is a good thing, we should take care that we don't end up discouraging the same ISPs from
obtaining PI space instead.  I do not believe the current wording does this, but I think it is important to keep the point in mind for future edits.

2) After the SWIP topics of this last year on the PPML list, I have this impression that record keeping across the ARIN region is a bit inconsistent and lacks automation.  I hate
to bring up what seems to be a dead-horse topic, but should SWIP policy be modified in regards to any difference between subordinate ISPs and large end users?  Should there be a
policy about SWIP auditing?  Does a multi-homed subordinate ISP, which qualifies for a /32 of PI from ARIN, qualify to get a /32 PA from each of its providers?  Given the size of
v6 are we even concerned if they do so?  And what would that do to global routing table growth?

and a personal ignorance question:  Does a subordinate ISP with X aggregate allocations advertised through Y direct upstream ISPs end up adding X x Y routes to the global tables?

> <snip'd the rest>


-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net