[rpd] proposed policy: reservation of resources for IXPs

Thu Oct 30 22:29:58 UTC 2014

We'll disagree. OIX has over 200 dues paying members and I'm confident that my statement is in context.

But I digress, this is about numbers and I pointed at a bonafide standard that refers to a number requirement that many IXP members and operators agreed on in an open and transparent forum (which you don't appear to participate in) and with overwhelming consensus.

You can receive it however you like.

Best,

-M<

On Oct 30, 2014, at 18:24, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

While I think that most of what OpenIX seeks to do is generally good, I think it is hubris for them to refer to themselves as “the IXP community”.

There are many perfectly legitimate IXPs being run very well which are not subscribing to the OpenIX model and there are some
areas where OpenIX is supporting a specific agenda that is not necessarily aligned with the broader interests of the entire IXP
community.

Owen

On Oct 30, 2014, at 11:47 AM, Hannigan, Martin <marty at akamai.com<mailto:marty at akamai.com>> wrote:

Yes, the IXP community agrees that dual stacking is required;

http://www.open-ix.org/standards/ixp-technical-requirements/

Best,

Marty

On Oct 30, 2014, at 14:45, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

It is very unusual to find myself on the opposite side of this question, Walu. As you know, I am a very strong proponent of IPv6 and will be very happy the day we start turning off IPv4 peering on the global internet.

However, I don’t think the policy makes any such assumption.

I think the policy assumes that IXP infrastructure must be dual-stacked and that in order to be dual-stacked, one needs IPv4 addresses.
There is no need to reserve IPv6 addresses because there is no shortage.

I do not believe that this policy encourages an IPv4 “comfort zone”. I believe it sets aside space so that infrastructure can be developed to support increased peering density on both protocols throughout the region.

Owen

On Oct 29, 2014, at 8:23 AM, Walubengo J <jwalu at yahoo.com<mailto:jwalu at yahoo.com>> wrote:

jst some questions for Mich & Co.

1) The policy presumes that IXP infrastructure in Africa is best on v4, hence and therefore lets reserve the v4 for this. But Is this true? What's wrong with IXP infrastructure on v6? And if there is nothing wrong, then do we really need this policy?
2) If we adopt this policy, are we implicitly encouraging v4 "comfort zone" in Africa when the rest of the world moves on and tackles any challenges v6 may provide in the context of IXP infrastructure?

just thinking loudly.

walu.
--------------------------------------------
On Wed, 10/29/14, Frank Habicht <geier at geier.ne.tz<mailto:geier at geier.ne.tz>> wrote:

Subject: [rpd] proposed policy: reservation of resources for IXPs
To: "rpd" <rpd at afrinic.net<mailto:rpd at afrinic.net>>
Cc: "Nishal Goburdhan" <nishal at ispa.org.za<mailto:nishal at ispa.org.za>>
Date: Wednesday, October 29, 2014, 5:01 PM

Hello all,

please find this proposed policy, which we (3 co-authors)
have submitted to
the pdpwg last week:

Resource Reservation for Internet Exchange Points

Author(s):
a) Frank Habicht, Tanzania Internet Exchange
b) Michuki Mwangi, Internet Society/KIXP
c) Nishal Goburdhan, Packet Clearing House/JINX

1) Summary of the Problem being addressed by this proposal

This policy reserves IPv4 and 2-byte ASNs resources for
public Internet
Exchange Points (IXPs) in the African region, ensuring that
there would be
discrete IPv4 resources to allow the establishment and
growth of future IXPs.

2) Summary of How this Proposal Addresses the Problem

This policy requests AfriNIC to reserve, and publish IPv4
resources, and
2-byte ASNs for use by IXPs only.

3) Proposal

3.1 Introduction

It is widely considered that Internet Exchange Points (IXPs)
are one of the
critical elements needed for Internet economies to develop.
Africa is still
in the process of developing these, and is, at the same
time, faced with
the imminent exhaustion of its IPv4 resources. Not having
IPv4 addresses to
grow, or start new, IXPs would create unnecessary and
unneeded routing
complexity for Internet connected networks, looking to peer
at IXPs to
further their network scope. AfriNIC already has an existing
policy to make
allocations to IXPs [1], but that policy does not
specifically reserve IPV4
space to ensure that there will be such, for future IXPs to
grow and
develop. Additionally, this policy reserves a set of 2-byte
ASNs for use by
IXPs for use at IXP BGP Route Servers.

3.2 Distinction between IXP peering and management networks

We distinguish between two kinds of IP address resources
needed and used at
IXPs. An IXP peering LAN is the contiguous network address
block that the
IXP would use to assign unique IP addresses to each peering
member, for
each peering participant to exchange network traffic across
the shared
peering infrastructure. Best practice has the IXP peering
LAN *not* being
visible in a view of the global routing table, among other
things to reduce
the attack vectors for ISP border routers via the IXP.

From a network identification, monitoring and analysis
perspective, it is
thus desirable, that the "peering LAN" space be provided
from a contiguous
block. The IXP management LAN is the management network that
the IXP uses
to provision services at the IXP, like monitoring,
statistics, mail, ticket
systems, provisioning of transit to DNS Roots, etc.

Management networks, are meant to be reachable globally, for
instance to
publish data and allow remote access for common good network
infrastructure
(such as root and TLD DNS servers) and research projects.

3.3 BGP Route Servers use

Typically IXPs use BGP route servers to help manage peering
sessions
between different participants. The route servers implement
IXP routing
policy in the form of BGP communities, typically in the form
of A:B, where
A,B represent A=IXP BGP route server and B=participant ASN.
Current BGP
implementations utilise 6 bytes for the extended community
attribute
[RFC5668]. Therefore, an IXP with a 4-byte ASN in use at its
route server
would not be able to successfully implement the A:B BGP
community mapping,
if an IXP participant has a 4-byte ASN. This situation is
likely to be
experienced by more IXPs, as additional 4-byte ASNs are
allocated through
the current AfriNIC process.

If, IXP route server communities include the IXP ASN and the
peer's ASN
(expected to be 4-byte), and a total of only 6 bytes are
available, it
follows that IXP route servers ASN could not be longer than
a 2-byte ASN.

3.4 Proposal

To ensure that there are sufficient resources for IXPs to
develop, this
policy proposes that AfriNIC reserve IPv4 addresses for IXP
peering LANs
out of an address block marked particularly, and
exclusively, for IXP
peering LAN use. Assignments for IXP peering LANs must be
from one
dedicated block, published as such by AfriNIC. Assignments
for IXP
management addresses should NOT be provided from the same
block as the IXP
peering LANs.

It is proposed that a /16 block be reserved for future
requirements for IXP
peering LANs in the AfriNIC service region, and that AfriNIC
publish this
block as such.

It is further proposed to reserve the equivalent of an
additional /16 block
for IXP management prefixes, separate from the peering LANs.
It is proposed
that AfriNIC reserves a block of 2-byte ASNs for use in BGP
route servers
at IXPs in the AfriNIC service region.

The number of ASNs to be reserved should be the larger of
114, or half of
the remaining 2-byte ASNs within AfriNIC's block at the date
of
ratification of this policy.

AfriNIC will allocate these resources on a first come first
served basis.

3.5 Evaluation criteria

This policy does not suggest new evaluation criteria for
what determines a
valid IXP.

4.0 References

[1] AfriNIC Policy for End User Assignments -
AFPUB-2006-GEN-001
http://afrinic.net/en/library/policies/127-afpub-2006-gen-001
Sections 5)
and 6)

Note: proposal also available at
http://www.afrinic.net/en/community/policy-development/policy-proposals/1231-resource-reservation-for-internet-exchange-points

Regards,
Frank
_______________________________________________
rpd mailing list
rpd at afrinic.net<mailto:rpd at afrinic.net>
https://lists.afrinic.net/mailman/listinfo.cgi/rpd

_______________________________________________
rpd mailing list
rpd at afrinic.net<mailto:rpd at afrinic.net>
https://lists.afrinic.net/mailman/listinfo.cgi/rpd

_______________________________________________
rpd mailing list
rpd at afrinic.net<mailto:rpd at afrinic.net>
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
_______________________________________________
rpd mailing list
rpd at afrinic.net<mailto:rpd at afrinic.net>
https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141030/e25d63d2/attachment.html>