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

[rpd] proposed policy: reservation of resources for IXPs

Owen DeLong owen at delong.com
Thu Oct 30 22:55:26 UTC 2014 

> On Oct 30, 2014, at 3:29 PM, Hannigan, Martin <marty at akamai.com> wrote:
> 
> 
> We'll disagree. OIX has over 200 dues paying members and I'm confident that my statement is in context.  

Of the thousands of organizations that I would consider constituents of the IXP community, I’d say that’s a pretty small sample.

> 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.  

I didn’t disagree with your conclusion. I disagreed with the characterization of the organization producing the conclusion.

Had you said “Open-IX agrees that…” or “The Open-IX community agrees that…” I would not have taken issue.

Indeed, I think it is likely that the IXP community even beyond the small subset that is represented by Open-IX would agree
with said conclusion, but I have not surveyed them and neither have you, so we do not know.

Owen

> 
> 
> 
> 
> 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/ <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 <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 <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 <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 <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 <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 <https://lists.afrinic.net/mailman/listinfo.cgi/rpd>
>> 

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

More information about the RPD mailing list