Hi All,

Below is a summary of the above policy as per the discussions we have had so far.

So far, we have the following arguments:

(a) Andrew Levin        (30.01.2007)
proposed that we should not assign prefixes < /48 due to concerns about the global routing table

(b) Frank Habitcht      (30.01.2007)
was in agreement that there was need for PI assignments < /48 especially in the case of IXP's since the prefix would not appear in the global routing table.

(c) Mark Elkins         (01.02.2007)
Suggested that each /48 assignment should be made from a unique /32 (which should be preserved to accommodate growth)


From the above points:

(b) above seems to have outweighed (a) above and as such we should allow for the assignment prefixes < /48 as per the draft.

as for (c) above, organisations which require >= /32 should become an LIR.

In conclusion, it seems that the draft policy should remain as it is.


Currently statistics:

* Yea (those in support of the policy)                  :       6
* Nay (those _not in support of the policy)             :       1

Finally, I wish to encourage more members of the community to give their views on this policy, or at least indicate whether they are in favour of it or not.

Abuja is only 5 weeks away!

-v

On Jan 30, 2007, at 11:22 AM, Andrew Alston wrote:

Hi Vincent,



I’m ok with all of this except for the following:



* The intial provider independent assignment size to an end-site should be a /48, or a shorter/longer prefix if the end-site can justify it.



I’m happy with /48s, I’m even happier with bigger blocks, but there should *NEVER* be a situation where the block is smaller than this in the global routing tables. If the blocks can ever be smaller than /48 in size it is going to create major BGP filtering headaches.



Can this wording be clarified?



Many Thanks



Andrew Alston

TENET – Chief Technology Officer

_______________________________________________
resource-policy mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/resource-policy

_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd

Reply via email to