- Test - lists.nanog.org

Re: Routing wars pending?
by jnc＠ginger.lcs.mit.edu 16 Nov '95

16 Nov '95

From: Alan Hannan <alan(a)gi.net> What are the correlations and contrasts between our current backbone routing problems (wrt space and # of routes) and the FCC decision several years ago to make 1-800 numbers portable. Well, the 800 number problem was a little easier, since phone numbers are variable length, and the 800 number database maps the numbers into another phone number, which may be a 13-digit carrier-id+phone-number combo... They say get stuffed, and get a congress person to propose a bill that all IP numbers are portable. This bill passes. It could happen. Any thoughts? Exactly which court do they go to to get this enforced on non-US parts of the Internet? Noel

1 0

Re: Routing wars pending?
by Vadim Antonov 16 Nov '95

16 Nov '95

>A FQDN is NOT useable as an EID. The host is not the endpoint. Ok. FQDN + port number. The endpoint does not have to be *named*, btw. It is quite enough to disallow TCP sessions to survice change of source or destination TLA (which is more than enough to cover the change of service providers) or to keep track of address changes the same way the post service does (i.e. forward and ask the addressee to notify the sender). >Consider process migration. Any commercial OS out there which does process migration? Most OS people became quite convinced that process migration does not pay for itself. Process migration is a lame excuse for building a whole new level of indirection and doing a hell lot of changes everywhere. And, magic cookie EID is *not necessary* for process migration (you may want to read rationale for TRAP). It can (and should) be done w/o it. No matter how you jump, the migration requires dynamical rebinding of EID->TLA, and the complexity of the task does not depend on the nature of EID. So why bother with extra level of indirection? It does not simplify anything, and like any extra layer anywhere only makes for a lot of headache (why do i think of ATM?). And then, there's a document describing how to do process migration w/o magic cookie EIDs, and so far nobody found a fundamental fault (or inherent inefficiency) in it. As i discussed that with Noel the aforementioned "architect's sense" came up :) The statement that migration is impossible w/o magic cookie EIDs amounts to the denial of the existance of the postal service. It does the two-level addressing (the EID is the identity of the addressee, the TLA is the postal address). When you move your magazines keep coming to you, right? Even if the "host" (i.e. home) didn't move with you. --vadim PS Computer science is the formalized branch of general bureaucratology.

1 0

Re: Routing wars pending?
by Vadim Antonov 16 Nov '95

16 Nov '95

Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. They are portable. Another is IPv4 addresses which aren't. How about fixing the real problem -- i.e. making renumbering easy and removing all hardwired addresses from the software? (And, yes, fixing DNS). The magic-cookie EID scheme is nothing more than more complexity to work around the broken implementations. That extra level of indirection is patently useless otherwise. Even funnier, implementation of magic cookie EIDs requires changes in exactly the same pieces of software which need to be changed to repair existing two-level scheme. Note that fixing DNS (and you *have* to do that anyway if you want to use intermediate EIDs) is a lot easier than replacing routers, and does not introduce compatibility problems at the transport level. Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs as yet. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. --vadim In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >Which is why we need *two* namespaces: one for the routing to do what >mathematics forces it to, and one for the humans to be able to dork with. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike

2 1

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 15 Nov '95

15 Nov '95

> In theory, this would be covered by moving AS279 from the AS macro > for MCI to the AS macro for UUnet. > > In current practice, because AS macros are not widely in use (and > aren't in our machine generated aut-num right now), this will have > to be coordinated among providers (like you send us a note saying > your entire AS has moved). > > The idea is that this doesn't happen all that often. If it does, > the AS macro is a decent way of handling it. So, this also goes for new ASes? And you're saying that everyone that peers with you should start using AS macros in addition to aut-nums to both add new ASes and re-arrange policy for old ones. How many AS macros are there now, in the radb, ans, and ripe RR's? [i left out mci because i know how many there are, especially since it is a split db ;-] Are the AS-macros only referenced recursively after parsing the aut-num, or are they to be applied to policy independantly? How is policy to be determined for AS5757, should someone start announcing it tommorrow? In other words, say this appeared in the RADB tonight: route: 206.197.210.0/24 descr: A route that can't get everywhere origin: AS5757 mnt-by: MAINT-AS5757 changed: kobi(a)kobi.edu 951114 source: RADB And someone, pick a provider, started announcing this to you tommorrow. Say Sprint. Would it be accepted? And why? _k > > > Elliot, > > > > > > Ignore the advisory. If AS2 is the origin, we will route traffic > > > for that particular prefix/masklen using the most common policy > > > already in place for routes in AS2. > > > > > > If the common policy is for us to send traffic destined for AS2 > > > via our peer AS1, we will continue to do so for the new prefix/masklen. > > > > > > Steve > > > > > > > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > > > routes registered in the IRR will be based solely on origin AS. > > > > > The origin AS will be expanded to the set of route objects registered > > > > > for that origin AS; the resulting list of prefixes will be used in > > > > > generating router configurations, as today.

4 5

Re: Routing wars pending?
by Sean Doran 15 Nov '95

15 Nov '95

>Any thoughts? Yup, when that happens, the USA ends up being the big loser in the game of global Internet connectivity. Sean.

1 0

YAWF
by bmanning＠ISI.EDU 15 Nov '95

15 Nov '95

Hi, Yet Another Web Form.... :) http://info.ra.net/div7/ra/naps.html now has a pointer for semi-automated requests for IP addresses at various exchange points. This form covers the following exchanges (active or proposed) AADS NSF NAP (AADS) PACBELL NSF NAP (PB) MAE-West (MAE-WEST) MAE-LA (MAE-LA) MAE-Dallas (MAE-DFW) MAE-HOUSTON (MAE-HOU) MAE-CHICAGO (MAE-CHI) Tucson NAP (TTN) NW Internet X (NIX) South Africa (ZAEP) Singapore (STIX) Paris (MAE-PAR) Thanks for your time... -- --bill

1 0

Re: links on the blink
by William Allen Simpson 15 Nov '95

15 Nov '95

> From: "Mike O'Dell" <mo(a)uunet.uu.net> > by the time we get anything that new installed, it had better be able > to go a lot faster than OC12 or we'll be right back in the same pot > on the day we put it in service. > I disagree with this position. The fibers installed to do OC-12 will certainly do OC-48 when it becomes available. And the next x4 jump as well. > Native packets over SONET is indeed The Right Thing To Do. > As author of PPP over SONET/SDH, I get queries from time to time about when this will be available. There are at least 2 unannounced products in development. I expect they will begin delivering OC-12 next summer, and OC-48 the following year. > The more interesting question is what is the difference between > switching and routing, and what is the role of each as the networks > grow in size, capacity, and bitrate. (And no, I don't mean cells.) > I also expect that _routing_ at that rate is the hard part. Maybe being a link kind of guy, the link parts just look easier to me. I expect _switching_ at that rate to be even harder than routing if they are cells; the times are just too short. But the usual packet size isn't much more than 3-6 cells, so the scale isn't as much better as we would hope. We tried to make 1500 bytes ubiquitous with PPP, but too much host software still uses 512 bytes anytime it thinks the destination is "remote", even when there is 1500 bytes end-to-end. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Routing wars pending?
by Hank Nussbacher 15 Nov '95

15 Nov '95

I would like to bring up the matter of address ownership. Here is the story: ILAN acts as registry of last resort in Israel. It owns and assigns IP addresses in the 192.114-118.0.0 address range. These 5 blocks are owned by ILAN (AS378). Over the years, many IP addresses have been assigned - in the past to individual companies and more lately CIDR blocks to local ISPs. ILAN takes a �50 one time fee to register the IP address for the requestor. Company FOO which has a class C decides to leave their current ISP - D. They move to ISP - N - which has their own CIDR block and does the good thing - forces the company to renumber and then informs ILAN that the company has relinquished the old class C. This allows me to reclaim IP addresses and form blocks of /22 and /21 which previously could not be done. All good up to this point. ISP D says since they paid the �50 registration fee - they now own the class C forever. I tell them that that is not the case and that the address was registered in the name of the company and not in the name of the ISP. They reassign the class C to other customers - at the same time I have reassigned the reallocated class C to some one else. Their upstream service provider - U - says to D: "Please inform me to delete the networks below from your access-list per Ilan request. It is a policy of U to only delete networks per U's customer request and not anyone else. This issues needs to resolved by you and ILAN and once it has been resolved, please let me what networks to delete." Ok so far. I trust D and ILAN will resolve this peacefully. But what about cases where it cannot be resolved peacfully? The routing tables are gonna start growing. ILAN withdrew 190 routes on August 1st when it started announcing 192.114.0.0/16 and 192.115.0.0/16. Now, since D is announcing a more specific (/24) - it turns out that his route supercedes my larger aggregate. How to combat it? I would have to start reannouncing all my specifics so as to counter-override his /24. What were to happen if this ISP picked a chunk of unused IP address space in my blocks, and started advertising it as /24s? His upstream service provider - U - just accepts it and starts routing. We maintain the authoritative source for IP address ownership in whois.ripe.net. We found that the upstream service provider - U - went and added a route object in whois.ra.net for the /24s (there are 2 cases now) - basely solely on the word of ISP D. So now there is a contradiction between the two databases. Now if D were to start advertising many unallocated /24s, I would be in a big problem and have to restart announcing my specifics. What are people doing in this area today? Are we going to start seeing routing wars? Thanks, Hank Nussbacher Israel

2 1

Re: Routing wars pending?
by Akira Kato 15 Nov '95

15 Nov '95

At the moment, JPNIC -- the Japanese country NIC -- charges 20,000 yen (about $200) for one-time transaction fee to register the IP address for the requestor. JPNIC delegates address blocks to Japanese NSPs, and the address assignment from the delegated space by a NSP is charged 10,000 yen (about $100). This discount is intended to cover NSP's cost to talk with not-well-knowledged-clients and cost to submit their request form in emails. JPNIC does not monitor how much NSPs actually charges their clients. When a client changes its NSP, JPNIC does not currently charge the one-time registeration fee to the client unless the new address space is not larger than before. This is because these change requests are usually submitted in emails and JPNIC people do not have to talk the requester nor have to create a form from snail-mailed or faxed applications. -- Akira Kato, WIDE Project

1 0

unscribe
by Steve Dix 15 Nov '95

15 Nov '95

unsubscribe Steve Dix (sdix(a)nic.ddn.mil)

1 0