August 1996 - Test - lists.nanog.org

Re: Customer AS
by Sean Donelan 19 Aug '96

19 Aug '96

>PS There is a proof by existance that reliable operation w/o > customer multihoming is possible. It is called POTS. That's funny. Anyone who needs reliable telephone service quickly learns how to multi-home between telephone providers, inbound and outbound. AT&T periodically puts out a press release saying their network is so reliable, no one needs to buy service from anyone else. But people still do. If you want reasons to buy service from someone other than AT&T, just ask your Sprint or MCI salesperson. Anyone who needs reliable electrical service, quickly learns how to multi-home between electrical providers. The street mains, a UPS, and generator. Some people even get a redundant connection to another street mains. Yes, it is complicated to multi-home between providers of anything (telphone, electricity, Internet, bagels). A redundant connection to the same provider might help in a few limited circumstances. But generally, when a provider fails on one connection, the probility their other connections are working drop dramatically. When the electricity fails, using a different connection to the same electical provider usually doesn't work either. That's why people buy UPS's instead of second power supplies. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

need for method of reducing ipV4 table size
by Forrest W. Christian 19 Aug '96

19 Aug '96

I've been slowly working on a method of reducing ipV4 table sizes in the core routers. I don't want to go into details of exactly how this will work right now (It's irrelevant to the question I'm going to ask) but it would reduce the number of routes in the global routing table to under 2000. I'm to the point that I need to clean up my notes, put it into RFC-format and submit it as a draft, but before I go through all that work, I generally was wondering if those of you who actually run the "core" networks see a need for something to significantly reduce the table size. The method I'm working on has the following "features". 1) Transparent to "end nodes" - no renumbering, no software changes 2) Software changes are confined to the "defaultless" routers. 3) Software changes are easy to implement - Someone who knows the router OS code well should be able to implement in a week or so, or a month at the most. 4) Low CPU impact - shouldn't impact the "core" router CPUs at all. "Customer Border" routers will have a minor impact - no more than IP filtering or some similar feature. 5) IPv4-specific. I'd go into more detail, but I don't want to waste everyone's bandwidth.

1 0

Re: Customer AS
by Sean Doran 19 Aug '96

19 Aug '96

Curtis Villamizar <curtis(a)ans.net> writes: > A /24 in the so called "provider independent" space will be blocked by > Sprint. That is what I mean be "unroutable". Um, forgive me for being obtuse, but what's the so-called "provider independent" space, and where is the document that outlines its boundaries? Also, as noted before, the bulk of the long prefixes blocked by inbound filtering have been obvious mistakes, such as subnets in the presence of an aggregate, people forgetting to aggregate at all, and so forth. In each case the addresses were from what appears to be PA space, in that the blocks in question were allocated to providers, rather than end users, and were non-portable. The addresses may well have been "backbone-independent", however, as far as I understand things, that is not the same thing as "provider-independent". Other than that, I completely agree with you. Sean.

4 5

Re: Customer AS
by Sean Doran 19 Aug '96

19 Aug '96

"Alex.Bligh" <amb(a)xara.net> writes: > So I have no problem with either ANS or Sprint's filters, just > don't think *all* non-IRR entered more specifics are mistakes. I don't think Curtis was suggesting that all non-IRR registered more specifics are mistakes, but rather the IRR is what he bases his filters on, because most such more specifics appear to be mistakes. This is what I'd consider a 90+% engineering guess, and seems reasonable to me. On the other hand, I wouldn't suggest that all prefixes longer than 19 bits are mistakes or are unstable, but I have observed that most appear to be, and so the engineering decision on this side was to filter them out. The problem here is that the minority of situations when a long prefix or an unregistered more specific route is needed for a short time, you're stuck with: > We don't put advisories or more specifics in the > IRR for several reasons, not least of which because this is a temporary > arrangement, and sorting out changing guardianship of the RIPE > objects etc. etc. with the old provider who is often slow to > cooperate is simply not worth the hassle. or conversely, the length of time it takes to change inbound prefix-length filters and have BGP peerings with external peers updated or reset to take the changes into effect. Both types of delay are crying out for automation, to reduce the delays, and add further flexibility into filtering policies. That, of course, means that someone has to develop the automation. I think you will find that ANS and Sprint (like many others) are both hiring... :-) Sean.

2 1

Re: Customer AS
by Sean Doran 19 Aug '96

19 Aug '96

-----BEGIN PGP SIGNED MESSAGE----- Curtis Villamizar <curtis(a)ans.net> writes: > I don't agree that with the apparent claim made by you > and sometimes others at SprintLink that they are the > only thing being done. If I come across from time to time as saying that mine has been the only viable approach, or the only approach actually being taken, then you should blame that on lapses into rhetoric. I'm glad we both agree that we are both doing things to try to curtail boundless growth of global routing tables, even if our approaches are often very different. Also, as I said at NANOG, I like many of the directions you've headed in, and when they can be followed by us, I expect that us Sprint people will reconsider some of our stronger positions wrt the practicality of databases. You also stole my follow-up paragraph with your last paragraph, too. :-) However, just to reiterate, the utility of other approaches is heavily reliant upon the availability of a sizeable set of tools which can be used by people in the trenches. Unfortunately, since those tools tend to be developed only either by or with lots of input from people in the trenches, and those people are busy building new backbones (you are not the only one :-) ), sometimes the goal seems alot farther away than I'd like in order to justify manual work to simulate non-existant automation. >you might want to look at the policies and see if you can >provide some types of exceptions Naturally. Again, I probably come across as a bit more extreme than I really am. The goal is not to unnecessarily make life difficult for customers of ours or even of yours, but rather to provide some backpressure against particularly bad practices that would make the scaling problems we are seeing now even worse. Finally, you'll note that elsewhere I've been pushing for a more tractable feedback system that involves unleashing market forces upon most of the processes which have been argued about in CIDRD, here and elsewhere. I think that this is probably a good direction to head in, and I would welcome your participation in PIARA land. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhjK00SWYarrFs6xAQHWaQP+PO+Woebb0lrphzFm+uxmY79+gWpAQJ+U r7BwpM9lh4h0DyMoAzj+Y1JqFmvmTEFQ/fjeJTC/bAJzb5zqw/FYCyc3h5gaBuFq AvKuFL1I2HVnFMNPn91lW9tLLUcEFfqQIs1JOApiUv84pEiimcSbqxnuHa5vu4k9 SSReSPmuQEg= =LJIW -----END PGP SIGNATURE-----

1 0

RE: [NIC-960710.6343] INVOICE (hardcopy) (01-jul-1996 - 07-jul-1996)
by Hank Nussbacher 19 Aug '96

19 Aug '96

On Fri, 12 Jul 1996 10:40:38 -0400 (EDT) invoice(a)internic.net wrote: > > >PAYOR: DATE: 12-jul-1996 >Yonghwa Song >DAEYU BLDG. 25-15, Youido-dong >Youngdeungpo-ku, >Seoul, 150-010 >KR > >PAYEE: >InterNIC Registration Services >P.O. Box 1656 >Herndon, VA 22070 >US > >Federal ID # 52-1146119 >VOICE: +1 (703) 742-4777 >FAX: +1 (703) 742-4811 >E-MAIL: invoice(a)internic.net I do not understand why Internic has emailed this invoice to me. I suspect your database is hosed or some other major problem. I have nothing to do with this domain and I trust that domains we have registered are not being billed elsewhere. Nanogers, Have you seen similiar cases of this nature? > > >**************************************************************************** > > INVOICE FOR DOMAIN REGISTRATION & RENEWAL > >******************* Please DO NOT REMOVE Version Number ******************** > >Invoice Version Number: 1.0 > >**************** Please see attached detailed instructions ***************** > >Invoice Information >1a. Invoice Number.....................: 960712.3683 >1b. Invoice Date.......................: 12-jul-1996 >1c. Invoice Due Date...................: 21-aug-1996 > >Domain Information >2a. Registered Domain Name.............: DAEYU.COM >2b. Associated Tracking Number.........: 960704.102 >2c. Period Covered.....................: 05-jul-1996 - 05-jul-1998 >2d. Initial Registration Fee...........: $100.00 USD >2e. (A)ccept (R)eject Charge...........: > >Summary Information >3a. Total Charges......................: $100.00 USD >3b. Total Amount Accepted..............: > >Payment Method >4. (CH)eck (CR)edit card, or (AC)count: > >Credit Card >5a. (V)isa, (M)astercard, or (A)MEX....: >5b. Credit Card Number.................: >5c. Name on Credit Card................: >5d. Expiration Date....................: >5e. Authorized Signature and Date......: > >Account Payment Information >6. Account Number (5-Digit)...........: > >--------------------------------- cut here --------------------------------- ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il WWW: http://www.ibm.net.il/~hank ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

2 1

Re: Customer AS
by Sean Doran 19 Aug '96

19 Aug '96

-----BEGIN PGP SIGNED MESSAGE----- randy(a)psg.com (Randy Bush) writes: > What their policy actually does is > convince wise folk not to buy from Sprint. Well, I don't want to argue with you as a marketing person with respect to brand names and the like, but hopefully I can separate your technical arguments from what might honestly be mistaken as an attempt at market positioning. Since March of 1995, Sprint has had contractual language with respect to our PA address delegations that make them explicitly non-portable, and not to be used in any other provider's network. In order to enforce that contract, we have installed inbound prefix filters to ignore all subnets of our PA CIDR blocks that are announced by our peers at exchange points. We have made no exceptions or holes in those inbound filters, except in the few cases where a network with addresses from Sprint CIDR space was willing to renumber and cease using the old non-portable numbers within a fixed number of days after homing itself to another provider. This is simply because rather than paying lip-service to non-portable PA addresses, we have worked out a contractual framework for delegation of these addresses, technical support for non-portability and also for aggregation. That is, there should be no subnets our non-portable PA CIDR blocks seen outside Sprintlink. This means some 4500 prefixes are hidden from global routing tables, with nearly zero entropy, because we do not make it easy for subnets to be migrated out of SL and remain workable. You have correctly noted that this effectively means that dual-homing to a Sprintlink peer (such as MCI) will not buy you fallback in the case of failure of your Sprintlink connectivity. This is a side-effect people generally are aware of, and generally can work around anyway. The simple solutions are, in order, -- make sure you have redundant connectivity to SL so that you do not lose connectivity to Sprintlink (admittedly we have not done a very good job making this option attractive price-wise, unlike a pair of our competitors, however we are working on that, and hopefully this option will be attractive _notwithstanding_ our non-portability policy) -- work out mutual back-up transit with another dual-homed SL customer Customers X and Y are using PA space. Each announces their subnets to SL and the 2nd backbone. Each takes, at minimum, announcements for the other customer from _both_ backbones. Note that this likely will require the equivalent of de-aggregation on the SL side in some cases (each sub AS does aggregation, and announces only the aggregates). This essentially amounts to what Yakov Rekhter describes as a "route pull". This is important for the next bullet. Customer X's connection to SL fails. Customer Y no longer hears SL's the announcement of X's subnets but they continue to hear them from the 2nd provider Customer Y therefore announces the subnets to SL on X's behalf. Note that this will require us to adjust inbound filters on the customer aggregation router in most cases, and is also what Yakov Rekhter describes as a "route push". SL hears announcement for X from Y, and hands X's traffic to Y. Problem solved. I would note that at least one SL customer, namely CAIS, actively sells this solution as a product. Moreover, they do a good job, and this is clearly a win for Sprint, Sprintlink's and CAIS's joint customers, and the manageability of our efforts to avoid increasing the size of global routing tables. -- offer yourself up as a PIARA-style volunteer I imagine that if there was a specific fee for a/ converting PA space into effectively PI space, b/ adjusting inbound filters at our edges, and c/ adjusting outbound filters at our edges, and this were negotiated initially as a special customer arrangement, Sprintlink's engineering and operations folks would have little problem with this, other than scaling it upwards to handling lots of this type of arrangement. I would imagine that since there are real amounts of effort across multiple groups internally, not to mention concerns wrt scalability of implementing this, the price should be fairly steep. However, if there is really a strong perceived value for this, I would be very keen on seeing a market develop. Finally, I would note that a trend towards large amounts of PA->PI conversion would certainly bloat our competitor's routing tables and those of some downstream customers, which has real costs. I would expect (and even hope) that this would lead either to the sort of filtering we do now, or to some route-charging scheme, in reasonably short order. Sprint is in a relatively good position here, since we already do protective filtering, and would be receiving a revenue stream directly associated with the increase in the amount of routing information we'd be carrying. Therefore, priced right, and assuming that we don't run into impassable technical limitations, any upgrading to new technology that would be required would have been paid for by the people forcing that requirement. I would suggest that, far from indicating brain-damage at Sprint, our addressing and aggregating policies are rather clever. You would have suggested that too, but you seem to be far more keen on using terms like "brain damaged" and "...other providers have discovered..." (a piece of technology that was done for me) and "wise folk [should not] buy from Sprint". Perhaps some folk will buy from people who sell out their engineering and operations background for quick bucks, but I think that many others will realize that Sprint is not out to make it hard for Sprint's customers to remain in business (and spending more money on Sprint services as their revenues increase), and in fact is working very hard on preventing our customers from seeing a huge explosion in routing table size that would be very costly to them. You might even consider being somewhat more charitable towards a competitor which has, unilaterally, undertaken a sometimes heavily criticized path leading to an economy wherein topology-based addressing is considered the best approach, not only from a technical perspective, but from a business perspective too. This approach, even though it has not been perfect, has, I suspect, made it possible for you to go into business with only a few million dollars of capital expenses rather than a few million dollars per router. Heck, you've even said as much yourself, in a previous incarnation. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhY5tkSWYarrFs6xAQFS6gP/QXwPBUi6yp7xxitG9Pca3OFBiyDos7IY 4A2vBKQHW85dveEp9a1Qd0YSITWfaSImr5qhryENCDwTPMVIkWDIKM12wz+7Bxhs aX8kYTNMr44o1p5P2alRWMxHydoZtWfMJLMPLxAFD5U30j+yUPyJArCz5uvolZTK r+Vhnd65h2M= =6hUy -----END PGP SIGNATURE-----

6 5

putting this issue to rest
by Paul A Vixie 19 Aug '96

19 Aug '96

Executive summary: This is a getconninfo()/gethostbyaddr() issue rather than a res_send() one. See the SONAR and SRV drafts to understand the current (published) thinking. Detailed view: >> Nope. Not only is DNS not a good directory system (see my comments on >> ".COM is full" on the ietf list last year), it's not a good routing system >> either. That it can be abused to either purpose is not significant, since >> 99% of the people and companies who will be on the Internet aren't here yet. > Paul, do you know of anyone who has done work on code to pick the best > choice (ie, closest, fastest) from a list a multiple A records? Or on > a name server that hands out "the best" A record. >From RFC 1034: | 3.6. Resource Records | | A domain name identifies a node. Each node has a set of resource | information, which may be empty. The set of resource information | associated with a particular name is composed of separate resource | records (RRs). The order of RRs in a set is not significant, and need | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | not be preserved by name servers, resolvers, or other parts of the DNS. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means even if a DNS server had complete knowledge of the network topology (so that it could order things appropriately for each client), and there was no caching going on (so that the person asking the question was always an end host, never a forwarding or recursive server), there is absolutely no guarantee that the host receiving such an "ordered set" would use it in the order given. >From RFC 1035: | 7.4. Using the cache | | In general, we expect a resolver to cache all data which it receives in | responses since it may be useful in answering future client requests. | However, there are several types of data which should not be cached: | | - When several RRs of the same type are available for a | particular owner name, the resolver should either cache them | all or none at all. When a response is truncated, and a | resolver doesn't know whether it has a complete set, it should | not cache a possibly partial set of RRs. This means the expected trick of sending only one A RR when several exist (since a set of 1 always has a stable order) won't work either, unless we set the TTL to zero on all responses containing A RRs for that name, which would defeat caching (which would be really, really horrible). Thus, I coauthored <draft-gulbrandsen-dns-rr-srvcs-03.txt>, now making its final approach toward specification (as a proposed standard RFC) and toward implementation (BIND 4.9.5, now in private alpha testing, supports it). SRV is not a complete solution but it's a step in the right direction. Matthew Dillon remarked here a while back that HTTP redirects are another way of approaching this problem. If we don't care about other protocols (and the traffic statistics say we don't need to, at least right now), that's fine. Keith Moore authored <draft-moore-sonar-01.txt> to help a host determine which of several addresses was "best"; SONAR and SRV together would be a powerful combination, and we can only pray that Microsoft and Netscape and Cisco each adopt both. Perhaps someone within the sound of my voice will decide to start a free implementation as a proof of concept. Shameless plug: This message has been brought to you by the Internet Software Consortium, without whose funding I would have to be doing honest work right this second. If you think the ISC is doing good work, plz consider sending in a donation to Carl Malamud, ISC's director. ISC's current grant runs out on December 31. ISC is a registered 501(c)3 and donations are tax deductible. The WWW page is <URL:http://www.isc.org/isc/> if you want to know what we've been up to.

1 0

Re: Customer AS
by Sean Donelan 19 Aug '96

19 Aug '96

>Of course, we'll be burning much more address space than we 'need' to, >but we'll be adding 0 routing entries, even though we are multiply >multi-homed. However, as I'm only a registry person and I "don't run >real routers", it is possible I am missing something obvious that will >result in this not working. If so, please let me know before I turn >APNIC into slag... What's the scarce resource we're trying to conserve this week? There is a provider in St. Louis which is trying to do something similar. Since people are buying it, the theory must sound good. In practice it makes things worse because you turn DNS into the router table. As DNS round-robins through the different provider addresses, you'll get addresses with the source and destination address pair from the same (or shortest path) provider to addresses pairs which need to transit another (or longest path) provider irregardless of the actual state of the network. Depending on the transit agreements between the providers to "heal" discontinuities doesn't work well. What's even worse, you have to depend on the quality of programmers. Since many programs only try the first IP address in the DNS response, you'll get more failures as the DNS round-robins through a down provider's address block. Unless you start make dynamic changes of your DNS records based on your routing state, blech. Maybe I missed something, and Paul Vixie intends to integrate BGP-5 and Bind-5.1.0. Under the heading, history repeats itself, sortlist isn't much of a solution either. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

RE: [NIC-960710.6343] INVOICE (hardcopy) (01-jul-1996 - 07-jul-1996)
by salo＠msc.edu 18 Aug '96

18 Aug '96

> Date: Sun, 18 Aug 1996 18:17:29 -0700 (PDT) > From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > To: Bill Woodcock <woody(a)zocalo.net> > Cc: billing(a)internic.net, hank(a)ibm.net.il, invoice(a)internic.net, > yhsong(a)daeyu.com, nanog(a)merit.edu > Subject: RE: [NIC-960710.6343] INVOICE (hardcopy) (01-jul-1996 - 07-jul-1996) > [...] > ... I'll be the first to encourage > replacing Network Solutions once the contract comes up. Oh? With what? An even lower bidder? With as much experience as the current contractor had when they underbid a DEC System 20? Be careful what you wish for... -tjs

1 0