[arin-ppml] 4.4 Micro Allocations and IXP requirements

[Martin Hannigan]

On Fri, Jan 10, 2014 at 4:01 PM, David Farmer <farmer at umn.edu> wrote:

> On 1/10/14, 13:45 , Martin Hannigan wrote:
>
>>
>> At the end of the day, you're still technically a PNI.  Bill Woodycock
>> had it right when he said it's easy to get a third party. I think it's a
>> reasonable requirement, without the extra capital requirements.
>>
>
> I think you are miss-paraphrasing Bill.  I think Bill was making the point
> once a couple networks peer with each other at an exchange frequently
> others follow quickly behind.  But it sometimes takes the first two too
> break the ice, before you will get the other networks to follow.  In some
> cases it maybe a road block to get the first three participants to peer to
> qualify for a IXP block.


I don't think I'm taking his comment out of character at all, but that's
fine.


> I think I agree with you that a third participant is probably a lower
> barrier in most cases, than a route server.  But, I think two participants
> and a route server shows a clear intent to be an exchange and is
> differentiable from a PNI.  The intent wasn't meant as a requirement for a
> route server, but an option, not all exchange points have the same
> circumstances.  We are looking for what the minimum is to justify an
> exchange point.
>

I'd rather see the third participant be a committed party. Traffic is more
valuable measurement. Putting two networks and a route server on a switch
is still the equivalent of a PNI. You can still have two privately
interconnected parties declaring their intent to form an IXP and attract a
third if they aren't completely inept.


> 1. If the community prefers just three participants, I'd ok with that.
>

Yes.



>
> 2. If the community wants to allow a route server to be one of the three
> participants, I'd ok with that too.
>

Debatable.



>
> 3. But, I agree with you that simply two participants by themselves is
> insufficiently differentiable from PNI.
>

I would argue the same including the route server since it is not required
to operate the exchange. Happy to discuss.



> And, someone else made the point that this wouldn't extend the free pool
> for any amount of time.  That is true, but that's not the intent of this.
>  The intent is to ensure that the CI reservations that should be available
> will beyond the free pool are actually only use for their intended purpose.
>  And that there are


Exactly.



> not loopholes left open for abuse of these special reservation.  To date I
> believe the other requirements were sufficient to discourage abuse.
>  However, that may not be true when all we have are these special
> reservation.



+1



Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140112/cb83f52a/attachment.htm>