[arin-ppml] Why should we do Proposal 121
charles at office.tcsn.net
Thu Dec 9 14:33:36 EST 2010
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>
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
More information about the ARIN-PPML