Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] New proposal - "Out-Of-Region Use of AFRINIC Internet Number Resources" (AFPUB-2014-GEN-002-DRAFT-01)

Noah Maina mainanoa at
Sat Jul 19 10:36:45 UTC 2014

Which is why I was arguing that LIRs shouldn't seat on the space allocated
but use it extensively. If customers want ips give it to them.

There is one thing announcing an aggregate to ones upstream! Then there is
another thing ensuring that a good percentage of that same aggregate has
been utilised well downstream....whose business is that? For the internet
to develop allocations have to be somewhat utilised IMHO and more acquired.

We have no problems assigning our customers ip addresses. They get amazed
by it because to us its more business and confidence from our customers. We
also encourage our customers to send us everything I mean everything
especially those with their own allocation and ASN.

As for Saun's experience that is outa this world. ..eish...that provider
sounds old school but thats wats up! !!

And for the old NAT, its here to stay. wanna kick out out....start
from its inception which is collage and academys where Fundamentals of
Routing are taught lol...NAT/PAT is like a 1st time ideology embibe onto
any aspiring network engineer...then there is the believe that NAT offers
some sort of security lol.


On 19 Jul 2014 09:12, "Andrew Alston" <Andrew.Alston at>

>  *There are quite a number of members who are yet to deploy any subnet of
> the resource allocated to them. There are reasons why this can happen; for
> example, the upstream provider of a member (which I am contact) attach a
> recurring fee to block advertisement. This to me was quite  surprising and
> we are still trying to avoid that cost either through convincing the
> current provider or moving on to another!*
> *Nevertheless, I don't think there is any member in that category that
> will successfully get additional allocation. On a lighter note, this could
> raise a question on usage and whether a policy is required to "ensure"
> usage ;)*
> That’s about the most bizarre thing I’ve read in quite a while… as a
> provider I want my members to advertise every block of space they possibly
> have to me – the more they advertise to me, the more traffic flows via me
> to them, the more transit I sell them.  I really don’t understand the logic
> behind some providers.
>  Let’s face facts, IF a provider has customers that have their own space
> and their own ASN, its in the providers interests to encourage as much
> advertisement as possible.  However, on the converse, it is in a providers
> interests to have customers on space assigned by them and not running BGP
> at all (in the latter case, it means the customer probably isn’t
> multi-homed, and for the customer to churn the customer will have to
> renumber, which can be a MAJOR headache, meaning the customer is far less
> likely to move on).
>  It’s an interested dialectic, it is in AfriNIC’s (and hence it could be
> argued the communities) interests to have as many people as possible with
> their own space and their own ASN’s.  However, it is in the interests of
> providers to encourage the uptake of space out of their own blocks assigned
> by AfriNIC and discourage this behaviour.  At the same time, what amazes me
> about Africa and the substantive use of NAT, it is NOT in a providers
> interests to have customers behind NAT, and I wonder if this isn’t
> something we could use to promote the uptake of IPv4 on the continent.  The
> simple reality is, a customer behind NAT can churn in an instant, the
> changes required on the customer side are minimal.  However, a customer on
> a providers space that is NOT running NAT and has the space all over the
> place has to renumber which could be a downtime and OPEX intensive
> activity.  (I’ve actually seen research that shows that non-NAT customers
> are FAR less likely to churn, it reduces the churn rate by double digit
> percentage points).
>  Thanks
>  Andrew
> ------------------------------
> DISCLAIMER: This email contains proprietary information some or all of
> which may be legally privileged. It is for the intended recipient only. If
> an addressing or transmission error has misdirected this email, please
> notify the author by replying to this email. If you are not the intended
> recipient, you must not use, disclose, copy, print, or rely on this email.
> We cannot accept liability for any statements made which are clearly the
> sender's own and not expressly made on behalf of this company or one of its
> agents.
> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list