- Test - lists.nanog.org

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 19 Aug '96

19 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

Re: Customer AS
by Sean Doran 17 Aug '96

17 Aug '96

-----BEGIN PGP SIGNED MESSAGE----- Curtis Villamizar <curtis(a)ans.net> writes: > The answer is clearly to number into an aggregate if you are dual > homed. Sprint will take the aggregate and at least have one path to > your prefix, very likely two if your two providers exchange your more > specific route between each other. We will route long prefixes across customer connections. Therefore, if a customer is dual-homed to another provider and has a long prefix from that other provider, we will listen to that long prefix across the customer connection. When it goes away, we will hear the aggregate, and route towards that. This, as Curtis says, is a clear win. I would note, though, that there is the risk that the other provider has contractual language wrt the non-portability of that provider's addresses that might make this not work. That, as Paul says, might be catch-22. However, I am sure that this would not be an insoluble problem, since, as I said in an earlier note, a price for an exception might be found through negotiation, even though an "official" PIARA experiment has not been started. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhZA+kSWYarrFs6xAQGQHAQAkon2lq0lovouN6IwxMouN1vx2IqXtN2i ZK6N5QF584IcHjyJVVnU5PIrTKytapCDj9hE9Jqd1VuKzepakIuvRM0v4JYbBHXv id8ZqbjFoQTY12etRI7ztXeVTAXNBy01LMKq1NES+S2/CvOhgaAe+rpNCJVuOGfi d0mgbdfALe8= =fUBJ -----END PGP SIGNATURE-----

1 0

Re: Customer AS
by Sean Doran 17 Aug '96

17 Aug '96

Curtis Villamizar <curtis(a)ans.net> writes: > I think the percentage of dual homed /24s is small compared to the > number of prefixes that have not been aggregated with no good reason > at all. Yes. Moreover, most of the dual-homed /24s are also firmly in the second camp. Sean.

1 0

Re: Customer AS
by Per Gregers Bilse 17 Aug '96

17 Aug '96

What would happen if the customer used private address space and NAT & ALGs to hook this into the two providers' CIDR space? At worst, address space consumption would be doubled (if the customer really needs a full /24 internally), but when we're talking about a couple of /24s versus routing yet another prefix, I think that's preferable. Has anybody noticed that the net global routing table has bumped 40k a couple of times recently? Would the registries have problems with this approach? Another issue is that the I-must-be-multihomed-to-different-providers mantra frequently isn't anything else than a funny idea in somebody's head. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse(a)EU.net

2 1

Re: Customer AS
by Paul Ferguson 17 Aug '96

17 Aug '96

At 07:44 AM 8/17/96 -0400, Curtis Villamizar wrote: >From a purely pragmatic standpoint, what good is having a dual homed >prefix if Sprint and other major providers drops your prefix and you >can't get to places? Better to number into one of the provider's >aggregates. The more specific will go to everyone willing to take it >and anyone not willing to take the more specific can still get there. > Well, that was my point, in a roundabout way. :-) This is a Catch-22. - paul

2 1

MAE-West FDDI ring split.
by rmg＠ranma.com 17 Aug '96

17 Aug '96

Uhhh, do all of you know that MFS is splitting the shared FDDI ring tonite (Fri nite / Sat early AM) due to congestion? rob. ---------- From: owner-mae-west[SMTP:owner-mae-west@nsipo.arc.nasa.gov] Sent: Thursday, August 15, 1996 5:12 PM To: mae-west Subject: MAE WEST outage notification There will be a short outage at MAE WEST Saturday morning, approximately between 12:00am and 12:15am. The outage should last no longer than five minutes. During this time, we will be splitting the shared FDDI ring at MFS into two segments, each on a separate Gigaswitch port. This should alleviate congestion on the shared FDDI which has been causing packet loss recently. Peering to and from some of the stations on the shared FDDI and switched Ethernet ports will be affected while the cables are being moved. Steve

2 1