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

[AfriNIC-rpd] AFPUB-2006-GEN-001 and Anycast

McTim dogwallah at
Wed Apr 11 08:59:52 UTC 2012


I have written a policy proposal to cover the cases of GRX and
non-critical Anycast.

Expect the Secretariat to post it to the list any time now.

I looked (briefly) for the critical infra anycast policy, but could
not locate it...Does anyone have a link?

I had thought we had such a policy, but if I can't find it.... perhaps
we don't.  It reminds me of "If a tree falls" philosophical question;
In our case it would be "If a policy is not on the website does it




On 4/11/12, Owen DeLong <owen at> wrote:
> Reading through the document you liked, your claim appears facially in
> conflict with the following provision:
>> IP Backbone Providers should exchange routing information and traffic
>> between all other Inter-Service Provider IP Backbone nodes. An IP Backbone
>> Provider should be responsible for distributing all Inter-Service Provider
>> BGP-4 information to all its peers. An IP Backbone Provider should
>> advertise its customer networks to peering partners after a Service
>> Provider has fulfilled the security requirements laid down in PRD IR.77
>> [19]. When operating an IPX network, the above requirements are mandatory.
> (6.5.1 IP Routing, Page 16.
> Further, the document is inconsistent with itself in a number of locations.
> Thanks for providing it, though. It explains a number of the reasons that
> cellular still continues to provide such a poor internet user experience.
> Owen
> On Apr 10, 2012, at 11:34 PM, Graham Beneke wrote:
>> On 07/04/2012 10:34, Alan Barrett wrote:
>>> What's wrong with the obvious approach? Like this:
>>> 1. get a /18 block.
>>> 2. carve out a /24 from inside the /18.
>>> 3. announce the /18 to everybody.
>>> 4. announce the /24 to only some peers.
>>> Not so obvious:
>>> 5. optionally, tag the /24 with a special community to encourage your
>>> peers not to propagate the announcement further. Perhaps no-export
>>> would be a reasonable choice.
>> There is a specific requirement that the prefix does not appear in the
>> routing table of certain peers and is un-routable from their perspective.
>> Thus it can not appear as part of an aggregate either.
>> You can read the details in this GSMA document:
>> While I understand that their could be other ways to achieve the
>> objectives, a global body has already standardised this across many of our
>> members. Is it not wise to build policies that adequately provide for
>> these requirements?
>> --
>> Graham Beneke
>> _______________________________________________
>> rpd mailing list
>> rpd at
> _______________________________________________
> rpd mailing list
> rpd at


"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

More information about the RPD mailing list