[rpd] Re: Factors affecting in-region utilization - way forward?

[Seun Ojedeji]

sent from Google nexus 4
kindly excuse brevity and typos.
On 19 Jul 2014 13:48, "Mukom Akong T." <mukom.tamon at gmail.com> wrote:
>
> *** speaking as mysefl i.e. no hats ***
>
>
> On Sat, Jul 19, 2014 at 3:31 PM, Seun Ojedeji <seun.ojedeji at gmail.com>
wrote:
>>.
>
>>>
>>> As for Saun's experience that is outa this world. ..eish...that
provider sounds old school but thats wats up! !!
>>
>> You can say that again, it may shock you to know that the provide is a
major ISP in the continent!
>
>
>
> Use the power of community to name and shame. I'm sure your institution
is not the only one at the receiving end of such policy,  when multiple
client  institutions collectively demanded the proper thing am sure they'll
take notice.  If the university is part of the BWC in Nigeria, that is a
good platform.
>
This practice was done by MTN and I am sure they are not alone in such
practices. The other thing to note however is that ISP tend to have quite
varying policy on this issue because I am also contact for another
institution that get serviced by the same MTN and are not paying such an
amount. Using that has a proof to them has not yet convinced them in
anyway.
As to Kofi; the institution I refer does not fall in the category of <30mb.

>
> I've also seen a REN try to stop its member university from having and
advertising their own space. Fortunately, I did tell them that wasn't the
purpose of a REN and backed up by some universities which had their own
space and the REN seems to have backed off from that position.
>
And I hope they yielded to your advice; the best REN should do is to help
institutions through the process of applying.

Cheers!
>
>>>
>>> Cheers.
>>>
>>> Noah
>>>
>>> On 19 Jul 2014 09:12, "Andrew Alston" <Andrew.Alston at liquidtelecom.com>
wrote:
>>>>
>>>> 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 afrinic.net
>>>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>>>
>>
>>
>>
>> --
>> ------------------------------------------------------------------------
>>>
>>> Seun Ojedeji,
>>> Federal University Oye-Ekiti
>>> web:      http://www.fuoye.edu.ng
>>> Mobile: +2348035233535
>>> alt email: seun.ojedeji at fuoye.edu.ng
>>>
>>>> The key to understanding is humility - my view !
>>
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>
>
>
> --
>
> Mukom Akong T.
>
> http://about.me/perfexcellence |  twitter: @perfexcellent
>
------------------------------------------------------------------------------------------------------------------------------------------
> “When you work, you are the FLUTE through whose lungs the whispering of
the hours turns to MUSIC" - Kahlil Gibran
>
-------------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140720/6cb2472e/attachment.html>