Routing Policy and the Routing Arbiter Service

Remember that NSFNET has been using a Policy Routing DataBase (PRDB) since 1989, both to prevent routing loops when EGP was used between the backbone and the regionals, and to ensure that each regional announced correct routing information. (Incorrect information could be announced simply due to configuration errors in the regional networks.)

When it was introduced, BGP made loop detection easy by virtue of its path attribute. If an AS appears in the path twice, the route is a loop and can therefore be ignored. The need to ensure correct route announcements from each of the regionals remained, as did the need for a PRDB.

With the establishment of new NAPs and the introduction of new providers in the ISP market, the community grew concerned about the explosion of peering sessions at the NAPs. A full mesh of neighbor peering sessions is required by the BGP protocol, which is configured on a neighbor-by-neighbor basis. Consequent bandwidth consumption also would affect the NAP switches—and, worse, router CPU utilization would become an issue because all routers at the NAP had to independently enforce routing policy.

To alleviate these problems, the NSF solicited for a Routing Arbiter Service. Its role included peering with all routers at the NAP, and applying policy to incoming and outgoing routes in accordance with information in the distributed Internet Routing Registry (IRR).

The IRR represented a collaboration of the information in the NSFNET PRDB and the registries of the RIPE NCC in Europe, MCI, ANS, and CA*net. The format of the database was in accordance with RFC 1786, which was based on RIPE-181, the pioneering work of the European Routing Registry. A significant, tireless, and highly commendable effort on Merit's part converted the entire PRDB to RIPE-181 format.

It is important to understand that the Route Server does not pass data traffic. When re-announcing BGP routing updates that comply with the policy, the Route Server leaves the BGP next-hop attribute untouched, allowing data traffic to flow directly between the peering routers. The Route Server itself is, therefore, not really a significant packet-forwarding device. In fact, SPARCstation 20s were used to perform the functionality at each NAP.

By applying a centralized intelligence to route-exchange at each of the NAPs, it was also possible to collect statistics related to route-exchange that previously had been maintained by the NSFNET. Statistics included route-flaps, the number of networks announced, and the number of routed ASs.

Unfortunately, this centralized approach also posed a problem for the Route Server model. Even though two SPARCstations were deployed for redundancy reasons, certain NSPs (particularly the large ones) were reluctant to put their critical peering capability into someone else's hands—no matter how historically competent that person might be. That remained a factor, even if they could reduce the number of peering sessions from 50 or more to two, one for each Route Server. Ultimately, the Routing Arbiter service at the NAP was relegated to the roles of database collation and statistics collection.

Not surprisingly, NSF selected a partnership that included Merit Inc. to provide the Routing Arbiter Service.

Was this article helpful?

0 0

Post a comment