- Test - lists.nanog.org

recent internet packet size samples
by Joe Abley 03 Aug '00

03 Aug '00

I'm interested in seeing the distribution of packet sizes across a 1500-byte-constrained measurement point, with "real internet traffic" going past (for some reasonable interpretation of that phrase). Specifically, I'm looking for the number of IP datagrams of size M for all M encountered throughout a long, contiguous packet stream (say a few hours' worth around the residential surfing busy hour). I can do measurements myself, but I'd prefer not to reinvent the wheel. Could anybody point me at some recent data? Thanks, Joe

5 6

InterNIC changes
by Verd, Brad 03 Aug '00

03 Aug '00

Informational Message: Amendment 19 to Cooperative Agreement Between NSI and U.S. Government C. During the period lasting until nine months after the date of this amendment, the Department of Commerce will cooperate with NSI to assure the continued availability of the internic.net SLD name for purposes of email transmissions from registration templates to NSI. Prior to the end of such nine month period, NSI shall modify all of its registration templates and otherwise migrate from the use of the term "InterNIC," or Internet addresses that reflect the term "InterNIC," in connection with its provision of any product or service. Thereafter, the internic.net SLD name shall not be used for the provision of Registrar Services. Effective August 8, 2000 By directive of The Department of Commerce, Network Solutions is retiring most of "internic.net". The following servers will be the only "InterNIC" machines visible after the 8th. www.internic.net whois.internic.net rs.internic.net ftp.rs.internic.net -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

1 0

Qwest and US WEST (non) routing problems
by Bessant, Chuck 02 Aug '00

02 Aug '00

I have been working a ticket with Qwest regarding our upstream through them in Portland. I was informed by a Qwest engineer that, as a result of their merger with US West, they are under an FCC mandate not to traffic data directly through AS3908. This AS serves the NW and the Denver area according to this engineer. THE CAVEAT as related by the engineer is as follows: our advertisements should, technically, be propagated out to the Internet...however, all traffic would first hit Qwest's network, then go through the Cable & Wireless network, then back through Qwest to us...in other words, even if our routes *were* being propagated properly, we would probably have to do some kind of prepending or other preferencing to get traffic flowing in Qwest's direction and even then it would certainly not be an optimal path through the network. Has anyone experienced this problem with AS3908 & Qwest? Thanks. Chuck

3 2

RE: NYC cut?
by Martin, Christian 02 Aug '00

02 Aug '00

We have a bunch of DS3s and OC-3c's out of 60 hudson. All are OK. ./chris -----Original Message----- From: Adam Rothschild [mailto:asr@latency.net] Sent: Tuesday, August 01, 2000 10:57 PM To: nanog(a)merit.edu Subject: NYC cut? Hi, I'm hearing word of a potentially large copper (fibre too?) cut in New York City, somewhere in the vicinity of 60 Hudson Street and Bell Atlantic/Verizon's central office at 50 Varick Street. Anyone have any additional information regarding this? Thanks, -adam

1 0

Re: TLD operations change
by Simon Leinen 02 Aug '00

02 Aug '00

>>>>> "kk" == Kurt Kayser <kurt(a)noris.de> writes: >> Effective zone serial number 2000080101, g.root-servers.net >> (192.112.36.4) will no longer be authoritatively answering for com, >> net, org. In its place g.gtld-servers.net (198.41.3.101) will be >> added as an authoritative server for com, net, org. > Does this also mean, that there should be a new 'root-zone' that > lists the new gtld-servers explicitly, instead the 'old' > x.ROOT-SERVERS.NET ? No, as there is no change in the set of root name servers. The set of gTLD (.com/.net/.org) nameservers has changed (g.root-servers.net => g.gtld-servers.net) but the gTLD servers don't have to be preconfigured using a "hints" file---they are found using regular DNS queries to the root servers. -- Simon.

1 0

TLD operations change
by Verd, Brad 02 Aug '00

02 Aug '00

Informational message: Effective zone serial number 2000080101, g.root-servers.net (192.112.36.4) will no longer be authoritatively answering for com, net, org. In its place g.gtld-servers.net (198.41.3.101) will be added as an authoritative server for com, net, org. The new set of servers authoritative for these TLDs will be: A.ROOT-SERVERS.NET. 198.41.0.4 G.GTLD-SERVERS.NET. 198.41.3.101 E.GTLD-SERVERS.NET. 207.200.81.69 F.GTLD-SERVERS.NET. 198.17.208.67 F.ROOT-SERVERS.NET. 192.5.5.241 J.GTLD-SERVERS.NET. 198.41.0.21 K.GTLD-SERVERS.NET. 195.8.99.11 A.GTLD-SERVERS.NET. 198.41.3.38 M.GTLD-SERVERS.NET. 210.176.152.18 C.GTLD-SERVERS.NET. 205.188.185.18 I.GTLD-SERVERS.NET. 192.36.144.133 B.GTLD-SERVERS.NET. 203.181.106.5 G.root-servers.net will continue to answer for the gov, mil, arpa, in-addr.arpa and root zones. -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

3 2

NYC cut?
by Adam Rothschild 02 Aug '00

02 Aug '00

Hi, I'm hearing word of a potentially large copper (fibre too?) cut in New York City, somewhere in the vicinity of 60 Hudson Street and Bell Atlantic/Verizon's central office at 50 Varick Street. Anyone have any additional information regarding this? Thanks, -adam

1 0

Re: Re[2]: TLD operations change
by Sean Donelan 02 Aug '00

02 Aug '00

On Tue, 01 August 2000, Joe McGuckin wrote: > I'm simply opposed to NSI embedding themselves further into the > infrastructure of the internet, making it that much harder to pry > them loose once their contracts run out... The end date on NSI's contracts/cooperative agreements have passed, several times :-) The nifty thing about having NSI as the business owner of all the GTLD servers now is if NSI ever goes bankrupt we loose *all* the GTLD servers in one swoop to the bankruptcy trustee. At least with the "volunteer" servers spread throughout different organizations, if NASA went bankrupt, we wouldn't also lose all the other servers at the same time. If I compare NSI's balance sheets to some of the "volunteers" I've got to wonder which ones are really the more stable organizations.

1 0

Re: TLD operations change
by Sean Donelan 02 Aug '00

02 Aug '00

>> Effective zone serial number 2000080101, g.root-servers.net (192.112.36.4) >> will no longer be authoritatively answering for com, net, org. In its place >> g.gtld-servers.net (198.41.3.101) will be added as an authoritative server >> for com, net, org. > > So much for O/S and hardware genetic diversity. Apparently my comment was a bit too cryptic. I was referring to the NSI program of NSI buying a set of identical hardware and acting as the sole operator of the machines serving as the GTLD zone servers. Although the NSI Registry web site confusingly indicates the root zone servers are supporting the .com, .net and .org rather than the GTLD servers. "The Registry DNS Programs Office is the business owner of the DNS (Domain Name System) root name servers supporting the .com, .net, and .org domains." I agree its a good idea to seperate the operation of the root name servers and the .com, .net and .org zone zervers. I disagree with the method NSI used to do this. A much safer method, somewhat similar to how pension funds choose fund managers, would have been to hire independent operators with different management styles instead of NSI acting as the sole operator of all the GTLD zone servers. Each independent operator would make their own choice of hardware, software, and procedures to meet the functional requirements. Ideally they would choose a variety of different methods. Just like you don't want all of your pension fund managers investing in the most risky stocks, you don't want all your operators choosing the most bleeding edge systems. On the other hand, you don't want only conservative operators because they will be using machines so far behind the power curve you won't make it until next week. It would avoid a problem, such as a bug in a single version of IBM equipment or a bad procedure call by one of the operators being replicated by all the operators at the same time. If NSI doesn't like "volunteers" (although it should be noted that several of the current root zone "volunteers" are in fact older, more established organizations than NSI and some provide a lot more protection than NSI provides for its own facilities) NSI could have funded (grants, contracts, even a cooperative agreement) several independent operators instead of trying to act as the operator itself. Of course, then NSI might have to worry about one of the folks it signed a cooperative agreement trying to claim it owned the zone files NSI hired it to act as an operator for :-) I'm normally opposed to "outsourcing" but in this case outsourcing makes a lot of sense. NSI being the business owner of *ALL* the machines serving the GTLD zone files doesn't make a lot of sense. My basic objection is using a set of identically configured hardware and software managed by a single operation for a "distributed" system.

2 1

two AS announce the same adress space
by Mikael Abrahamsson 01 Aug '00

01 Aug '00

What will break if two different ASes announce the exact same adress space? It's the old multihoming issue, small company wants to multihome, does not want to get an AS of its own, and wants to use one address space via both providers. This adress space is from PI space so ISP1 already announces the exact net (no aggregation) and would like ISP2 to also announce this, perhaps via a private peering using "private AS" but I would like to avoid that. I know the RFC says this should not be done (or at least I'm told so), but I would like to know if someone does this anyway and if they do, what problems arise? -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 1