- Test - lists.nanog.org

Merit Routing Registry
by epg＠merit.edu 18 Apr '94

18 Apr '94

Merit is happy to announce the Merit Routing Registry. Whereas Merit designed and manages the PRDB (Policy Routing Data Base) for the NSFNET service, RIPE pioneered a policy routing registry for the European community. The RIPE Routing Registry is based on the document, RIPE-81. With RIPE's collaboration, Merit installed RIPE-81 software and then extended the policy descriptions in order to realize more complex policies. The Merit Routing Registry will be a companion registry to the RIPE Routing Registry and is intended to serve the community that is not served by RIPE. This is a new service and we consider ourselves still in the beta phase. Registrations may be basic policy descriptions defined in RIPE-81 or complex routing policy descriptions defined in the Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu. The Extended Policy Syntax document may be found on rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for using the MeritRR can be found on rrdb.merit.edu:pub/meritrr. Merit and RIPE anticipate that the combined registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to allow the two registries to appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. For more information, please respond to rradmin(a)rrdb.merit.edu. Elise Gerich, Merit Network, Inc. Daniel Karrenberg, RIPE NCC

1 0

Re: 20402 routing entries
by Martin Lee Schoffstall 18 Apr '94

18 Apr '94

You've been selling the CIDR drugs, your responsibility was to have come up with one. I think the community needs to have a solution, i can't come up with a unilateral one, and it will take a LONG time to sell a multilateral one. But we've been working on them for some number of months. Hint, think about buying back network numbers. General principal of the US Constitution is that if you take something you give some relief. (I'm not saying this is uniuque to the US btw). Marty > Ref: Your note of Fri, 15 Apr 1994 16:39:45 -0400 > > > Marty, > > >We will have to incent (carrot) people to do the right thing... > > Would you be so kind as to share with the rest of us what > that "right thing" is. > > >you have no plan... > > Would you be so kind as to tell us whether you have a plan ? > > Comrades Yakov&Peter >

4 4

20402 routing entries
by yakov＠watson.ibm.com 18 Apr '94

18 Apr '94

Ref: Your note of Fri, 15 Apr 1994 10:52:00 -0400 Henry, >This assumes alot, including customers that don't switch providers >and inject more specific routes (this is happening already). No, I assumed that most (but NOT all) of the customers who switch providers would renumber. I can further weaken this assumption by allowing aggregation above the immediate provider level (you can do this with CIDR). >You're also assuming that we have a mechanism for aggregating >routes for folks who choose not to (or can't, for some reason). That is not so far-fetched assumption. Proxy aggregation is likely to happen, whether some folks like it or not. >CIDR only buys us a *little* time.. Remember there is "CIDR movie", but there is also "CIDR book". You need to consider both... Yakov.

8 16

a modest proposal
by Walt Haas 18 Apr '94

18 Apr '94

The idea below seemed to make sense last night after a couple of margaritas at the Rio Grande Cafe, let's see if anybody else thinks it will fly. If this isn't the right place to discuss it let me know, I will forward it appropriately. -- Walt ======= PROPOSAL FOR A NEW NAME/ADDRESS PARADIGM FOR THE INTERNET April 16, 1994 Walter O. Haas University of Utah Salt Lake City, UT 84112 <haas(a)ski.utah.edu> 1. Internet names are the property of the user, not the network service provider. An Internet name has much the same legal status as a registered trademark, and is suited to appear in advertising and other literature completely independently of the Internet service provider currently employed by the user. Internet names will be issued by a central authority directly to the user. Optionally, a network service provider may handle the necessary paperwork for a user to obtain a name, but this does not give the said provider any right or interest in the name issued and the provider must not attempt to mislead the user to the effect that it has such a right. 2. Internet addresses consist of a <provider-part> and a <customer-part>. The <provider-part> belongs to the Internet service provider, and is used by Internet routers to switch traffic to agreed points of that service provider's network. The <customer-part> belongs to the customer. A complete Internet address is of the form <provider-part>.<customer-part>. If the customer decides to obtain services from a different provider, the customer shall adopt addresses using the <provider-part> of the desired provider. It shall be possible for a customer host to be multi-homed to two addresses with different <provider-parts>, either temporarily or permanently. The <provider-part> consists of two areas: a <provider-id> which identifies the organization providing service, followed by a <provider-specified> part which tells that provider's network how to route to the customer network. Thus a complete Internet address can be specified as <provider-id>.<provider-specified>.<customer-part> Providers are assigned a <provider-id> by a global authority, but may choose their <provider-specified> part according to their internal criteria, which may include (but are not limited to) technology, geography, business plan, and perceived customer desires. All providers are required to forward traffic to any of the globally-defined <provider-id> values, but are not required to process any portion of the Internet address beyond that (except their own). There shall however be a defined upper limit on the size of the <provider-specified> and <customer-part>. 3. Each user host shall be configured with its Internet name. Upon booting, the host shall send a Name-to-Address Request (NARQ) packet to a defined broadcast address. The NARQ packet will contain the host's name. A server will respond with a Name-to-Address Reply (NARP) packet containing the Internet address of that host. 4. If the customer decides to change Internet service providers, it will need to assign a new <provider-part> corresponding to the new Internet address of the new service provider to each host. This will be done by giving the new <provider-part> to the customer's nameserver, which will then send appropriate NARP packets to the relevant network hosts which will then each have two Internet addresses. This operation obviously needs appropriate security. When the customer's network has acquired the new set of addresses and the old service provider is no longer in use, then the customer's nameserver can send an appropriate Name-to-Address Invalid (NANA) packet to each host to invalidate that address from its configuration. This operation also needs to be secure. -------

2 1

CIDR testing
by yakov＠watson.ibm.com 18 Apr '94

18 Apr '94

Ref: Your note of Fri, 15 Apr 1994 20:26:47 +0200 Havard, >What this means is that I think it's fairly safe to say that there >will be no connectivity problems when you pull the specific routes. I guess we can declare the as of April 15, 1994 the Internet "guts" have been adequately CIDRized :-) Yakov.

3 2

Re: 20402 routing entries
by Jeff.Ogden＠um.cc.umich.edu 17 Apr '94

17 Apr '94

About three years ago we renumbered all of the state Universities in Michigan (except Michigan State U). It was a lot of work and I wouldn't want to do it very often, but the whole business went much better than I expected. The key is good planning. Another key is getting people to use domain names rather than IP addresses whenever possible. We had signs up saying "Names good, numbers bad!". -Jeff Ogden Merit/MichNet

1 0

Re: 20402 routing entries
by Jessica Yu 16 Apr '94

16 Apr '94

Date: Fri, 15 Apr 1994 16:02:57 -0400 From: "Martin Lee Schoffstall" <schoff(a)us.psi.com> And is only downside is that anyone not doing BGP4 he won't be able to talk to at all. If an AS does not do BGP4 but defaults to a CIDR capable AS, he can still reach it. Only the ASs which does neigher BGP4 nor default will have problem. Maybe you could help him a little bit and tell him who that might be. About 1000 more specific routes have been withdrawn from the Internet during the past two weeks. Have not heard any complain yet. If you know anyone who does neigher CIDR nor default and therefore will have reachability problem when specific routes withdrawn,please let us know. --Jessica

1 0

Re: 20402 routing entries (renumbering)
by t.c.streater＠dante.org.uk 16 Apr '94

16 Apr '94

Renumbering workstations in principle *is* a no-brainer. But there are always wrinkles. And if those workstations are running a particle accelerator (as when a year or so ago I coordinated some renumbering at SLAC), you better have a damn good reason for doing it. A $20M facility running 7*24 expects good reasons for you to possibly screw it up, and their operational philosophy is to assume you will. I was able to renumber two largish groups of machines (200 or so in each), with quite a bit of coordination needed, and because of the various overlapping schedules it took a while before I could even start. Then, for each group I had to assemble numerous experts (Macs, Amigas, PCs, Next, RS/6000, Sun, Ultrix, VAX, Cisco). Luckily we had a good database of workstations so that I could tell the platform experts which machines were going to be involved. In some cases changes had to be backed out a couple of times because of something the platform experts forgot (or didn't know about). Now, can you imagine the conversation I might have had if still working there and SLAC agrees to exchange its class B (with about 1k out of 64k addresses assigned) for some number of class C: Me: SLAC has to renumber! Users: Again? OK Tim - but why? And what's in it for us? Me: (explanation of routing overload deleted) Users: So you are saying that of the 20k or so addresses in routers, SLAC renumbering saves just one entry? Me: Err, yes. Users: Don't ring us, we'll ring you! As Marty says, there is (unfortunately) no carrot - and users resent the stick. You apply the stick too often and you are out the door, either as an external provider or internal expert. Users barely (in some instances) know what an IP address is. They expect the network to be like the phone or power outlets; you just plug in where you happen to be. If we expect renumbering and provider-based addressing to be feasible, it seems to me that w/s vendors need to provide powerful tools to enable *transparent* *on-the-fly* renumbering - else it won't happen. And even if they do (and where's the carrot for *them*?), it will be quite a while before such tools are ubiquitous enough to make the process always easy. Should we be working with vendors in this area? Now will you all *go* *home* - it's the weekend, damnit! Tim Streater, DANTE. t.c.streater(a)dante.org.uk +44 223 302992

6 6

Re: 20402 routing entries
by Vadim Antonov 16 Apr '94

16 Apr '94

>>you have no plan... >Would you be so kind as to tell us whether you have a plan ? "Mister Fiks, do you have a plan?" "Do I have a plan? Do I have a plan? I have two sacks of plan!" :-) --vadim

1 0

egregious waste of bandwidth...
by Robert E. Seastrom 16 Apr '94

16 Apr '94

Hmmm, the regional-techs and bgpd lists are looking a lot like com-priv these days... ---Rob

1 0