Submission by Joe Abley 21/11/99

Promoting Routing Stability in New Zealand

Contents,

1 Background

1.1 Routing in the Global Network
1.2 Routing Complexity in NZ
1.3 Other People's Finger Trouble
1.4 Publishing Routing Policy
1.5 Route Arbiter Database (RADB)

2 Proposal

2.1 Objective
2.2 Options
2.2.1 Do Nothing
2.2.2 Build and Run a New Zealand Routing Registry
2.2.3 Facilitate use of the RADB by NZ
2.3 Recommendation

1. Background

1.1 Routing in the Global Network

The entire Internet is composed of a large number of discrete independently managed networks that are joined together. These individual networks are known as autonomous systems. Any of these autonomous systems is able to send information to any other autonomous system, regardless of the fact that they have largely no control (and, to some extent, no knowledge) of the details of the infrastructure beyond the edge of their network.

An autonomous system allows network traffic on the Internet to be carried into it by "advertising" connectivity to the other networks to which it is attached. For example, suppose ISP A operates a network where the devices are numbered with a certain range of IP addresses. ISP A tells the adjacent net- works that they can reach these particular networks through their link to ISP A { ISP A is said to "advertise a route" for those addresses.

Some autonomous systems only connect to one other autonomous system (eg. a corporate network has a leased line to their ISP). For these networks, there is only one way in which traffic from outside their network can be carried in, and so the process of advertising routes is rather trivial.

However, some systems have significantly more complex connectivity than this. This is usually the case when the systems concerned are ISPs, rather than end-users.

Routes are "advertised" between autonomous systems using an Internet standard protocol called BGP¹. As part of this protocol, every autonomous system is allocated a globally unique number, or ASN². There have been over 10,000 ASNs allocated to date.

1.2 Routing Complexity in NZ

To take a real example from the network right now, consider a customer of CLEAR Net looking at a web page that is hosted at IHUG. There are several ways the packets between CLEAR and IHUG can be carried:

• directly between CLEAR and IHUG;
• CLEAR to NetGate in Auckland, and from there to IHUG;
• CLEAR to Telstra NZ in Auckland, and from there to IHUG;
• CLEAR to Telstra NZ via APE, and from there to IHUG;
• CLEAR to NetGate in Hamilton, and from there to IHUG;
• CLEAR to Telstra NZ in Hamilton, and from there to IHUG;
• CLEAR to NetLink via WIX, from there to Telstra NZ, and from there to IHUG;
• CLEAR to Concentric Networks in Los Angeles, to Pacific Bell, and from there to IHUG;
• and so on...

It might seem obvious which path is the most efficient, but it also needs to be considered that all of those routes will differ substantially in terms of network performance (eg. latency, packet loss, jitter). You will also notice that the link that CLEAR has direct visibility of is only a small part of the path to the destination, in many cases.

As neutral peering points in Auckland and Wellington gain in popularity, the number of possible paths between any two points in the New Zealand Internet grows. As this complexity grows, the challenge to ensure good performance for customers becomes harder and harder.

1.3 Other People's Finger Trouble

A common enough event on the network is for an engineer on one network to mis-type something into a router, and for an ISP to begin to announce bogus routes out into the world. When ISP A accidentally advertises networks that are used by ISP B, the chances are that at least some network traffic that would normally go towards ISP B will instead go to ISP A, and when it arrives it will more than likely be discarded. This effectively makes ISP B disappear to at least some part of the network, is generally considered a Bad Thing, and happens all the time.

To minimise the network-wide instability that would otherwise result, ISPs filter the advertisements received from adjacent networks, so that any errors the next-door ISP makes are contained. Filtering would be a mild administrative burden if it only had to be set up once, but in reality the network is in a constant state of flux { customers move from ISP to ISP, taking their network numbers with them; new ISPs rise up; old ISPs disappear or merge.

The upshot of all this is that filtering route advertisements from your neighbours is necessary to prevent your customers bearing the impact of some other ISP's mistake, and that those filters are dynamic and will need regular maintenance to keep them up-to-date.

1.4 Publishing Routing Policy

An approach that has proved instrumental in managing this kind of complexity in other parts of the world is to publish routing policy in a public database. This policy describes, in a standard way, how an ISP is connected to other ISPs, and what routes a neighbour might expect to be advertised.

1.5 Route Arbiter Database (RADB)

Merit Network runs the original route policy database under the auspices of its Route Arbiter projects (see http://www.merit.edu/radb/ for details). Originally funded by the US NSF, and subsequently by a number of large ISPs in North America and Australia, the RADB is now a user-pays service.

An ISP who submits records to the RADB specifies some level of access control to prevent unauthorised parties making changes to their data. This is done by the use of a "maintainer object", which is a special record containing authorisation information. Other records that need protection are attached to a specific maintainer object, and inherit the authentication and authorisation scheme associated with it.

Normally an ISP would register only one maintainer object in the RADB, but there is nothing to stop them registering more than one. Merit charge US$200 per maintainer object, per year.

The RADB is just one part of a distributed database called the Internet Routing Registry (IRR). Through a system of real-time distribution of records, the component databases in the IRR are replicated such that any one contains all records in the IRR.

Merit do not currently make a charge for carrying records from other databases in the IRR.

2 Proposal

2.1 Objective

To promote stable and well-engineered domestic Internet infrastructure, to the benefit of all New Zealand Internet users, by assisting ISPs in publishing their routing policy.

Not all ISPs need to publish their routing policy. Those that do:

• use BGP to advertise routes to adjacent networks;
• have been allocated a globally unique ASN³ by a regional registry or some other authoritative body;
• are connected to more than one adjacent autonomous system.

It is not expected that ISOCNZ would need to make a judgement as to whether an ISP was a good candidate for receiving assistance; the fact that an ISP has been allocated a globally unique ASN is sufficient.

2.2 Options

2.2.1 Do Nothing

Some ISPs have difficulty in paying the Merit fees, because of the amount involved, or the internal difficulty in settling a one-off payment to an overseas company; a hands-on approach will likely result in fewer ISPs publishing their policy than would otherwise be possible.

2.2.2 Build and Run a New Zealand Routing Registry

The software required to run an IRR is freely available (and developed by Merit). Merit is happy to incorporate remote IRR databases into their own (using their real-time mirroring software) at no charge.

However, there are two points to consider:

• This is an area of active standardisation efforts. The RADB has recently migrated from one database schema to another⁴ in response to IETF working group activity, and any NZ database would need to follow similar developments in the future
.
• An IRR does not have particularly onerous uptime requirements, but there is a definite requirement for high data integrity and stability of the platform as a whole, since routing stability depends on it. Any NZ database would need to be run on a professional (and, politically speaking, neutral) basis.

2.2.3 Facilitate use of the RADB by NZ ISPs

An ISP who decided to publish route policy in the RADB, but for whom the Merit fees were a problem, might approach ISOCNZ for assistance. ISOCNZ would register a maintainer object in the RADB in their own name, but with authentication and authorisation fields specified by the NZ ISP.

Merit would bill ISOCNZ for the maintainer object, which would be used by the ISP.

Maintainer objects are submitted by e-mail using a simple text form. The number of NZ ISPs who might make use of this facility is small (less than 30) and an automated or otherwise elaborate system of processing is not required.

2.3 Recommendation

My recommendation is for ISOCNZ to register maintainer objects on behalf of NZ ISPs who request assistance, as described in section 2.2.3. In the future, it may become desirable to run a local routing registry, but at present this is a much more complicated proposition than simply facilitating use of the Merit-run database.

¹ the Border Gateway Protocol, version 4, RFC1771
² autonomous system number; allocated by RIPE, ARIN and APNIC on behalf of ICANN in accordance with RFC1930
³ autonomous system number
⁴ from RIPE-181 to RPSL, the IETF standards-track Route Policy Specification Language,
as described in RFC2622