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

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

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


Gents,

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
exist"?

:-)

Regards,

McTim



On 4/11/12, Owen DeLong <owen at delong.com> 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:
>> http://www.gsma.com/documents/ir-34-5-0-inter-service-provider-ip-backbone-guidelines/20211/
>>
>> 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 afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>


-- 
Cheers,

McTim
"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