September 2006 - Test - lists.nanog.org

RE: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Jim McBurnett 11 Sep '06

11 Sep '06

Owen, I totally agree-- In the last 2 years I have worked with ARIN and received several assignments for end users and NONE of them were difficult for the assignment. I think the worst I saw was getting an outdated ORG ID record changed! The time from request to assignment in one case was less than 2 weeks, and the worst was 6 weeks. That one required ORG ID changes, contact changes, ASN assignment, and was interlaced with both me and the customer contact being out of town on different weeks. If you read carefully and just call the helpdesk they are there to help. NOT hinder. Sure the ORG ID change was difficult and I would have had it no other way! That protects all of us! Remember all those hijacked IP blocks? Where is William L?(sorry I can't remember your last name) Later, Jim

1 0

Re: [routing-wg]BGP Update Report
by Vince Fuller 11 Sep '06

11 Sep '06

>> The comment still applies. Imagine that this system were implemented >> globally on all international/intercontinental air routes. It would still >> be nice to avoid having each of those airplanes cause a globally-visible >> routing update whenever it crosses some geographical boundary. > > The problem is physics: The speed of light is about 300.000km/s in air > and about 200.000km/s in fibre, which means a VPN solution causes an > _additional_ >70ms delay for some additional 7000km VPN distance. If one assumes a well-engineered VPN solution that interconnects the ground stations to "peering" points to the rest of the Internet, then there should be no increase in delay for traffic outbound from the plane toward the Internet - traffic path will still be plane -> ground station -> nearest exit point to Internet. The amount of delay increase for return traffic is hard to quantify; it will depend on how well the Conxion service network/VPN is connected to its upstream providers, how well-connected those providers are to interconnect points to the rest of the Internet, whether shortest-exit routing (or some other "optimized exit routing") is implemented between the various providers, etc. Many of these issues will apply to the current, dynamically-route-every- prefix model, too. In some cases, the VPN will make little or no different in delay; in some cases, it may increase one-way delay a bit. On the upside, worries about more-specific filtering and route-dampening will go away. > No, VPN and NAT and PA and shim are not the solution for todays > mobile communications demands. From the view point of the developer > of such an intercontinental communications system todays internet > technology looks outdated, the BGP re-anouncement is just a hack. > Indeed, RFC1661 is dated July 1994. > > This is just another example for the obvious demand of a true dynamic > routing system beeing capable to handle large numbers of prefixes and > dynamic changes in the routing table. Other demand results from mobile > networks, IPv6 PI etc. > > The demand _is_ there, simply saying "don't use PI, do keep 200 customers > rules (IPv6), don't accept small prefixes, don't permit dynamic changes, > do wait for our perfect shim solution which takes short additional 10 years > to develop, do purely theoretical discussions on geoadressing" as the > "restrictive approach" is not the solution. > > Either the Internet community will find good answers to these demands, > or the markets will find solutions without the Internet community ... > > Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ... If one assumes no changes to ipv6 semantics, it is hard to envision such a solution being possible. "PI routing" degenerates into flat routing and building "a true dynamic routing system beeing capable to handle large numbers of prefixes and dynamic changes in the routing table" is difficult to impossible if one assumes a) a single number space that accomodates both routing information and endpoint-identification (which is a fundamental design assumption in ipv6 as currently specified) and b) continued super-linear growth in the number of unique subnets that are identified using that numbering space. There are smart people who have been looking at how to fix this for more than a decade (some would say that research along these lines dates back to the 1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG presentation on this topic, with pointers to earlier work); virtually all of the designs that have been offered require routing locator/endpoint-id separation. Unfortunately, those who put together the current ipv6 did not choose to follow the locator/endpoint-id separation path. For a variety of reasons, trying to retro-fit the split into ipv6 with something like shim6 is difficult and it running into a lot of resistance. --Vince

1 0

Re: [routing-wg]BGP Update Report
by Marshall Eubanks 11 Sep '06

11 Sep '06

Hello; On Sep 11, 2006, at 6:32 AM, Oliver Bartels wrote: > Hi Gert, > On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: >> Ummm, well, this is a damn fast plane if it will reach another >> continent >> 1843 times per day (or even "per week")... - which should be the only >> time the BGP announcement moves. >> >> Sounds more like "the BGP-follows-plane system has some stability >> problems". > > Nack. > > Probably they are using low or medium earth orbit satellites, which > _are_ damn fast in orbit. Otherwise the round trip time would be > unacceptably high. > I believe that all Connexion support is / was from geostationary satellites. > As the whole thing is 3D, some of them might have contact to > ground stations on this or the other side of the great lake, > depending on their 3D position, even thru the plane travels > on a well defined track (probably a 3D circle, too) in just one > direction only. > > Ceterum censeo: Nevertheless this moving-clients application shows > some demand for a true-location-independend IP-addresses > announcement feature (provider independend "roaming") in IPv6, > as in v4 (even thru this isn't the "standard" way, but Connexion is > anything but standard). Shim etc. is not sufficient ... > That seems like a reasonable conclusion. > Kind Regards > Oliver Regards Marshall > > > > Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany > oliver(a)bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > > >

1 0

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
by Mark Kent 11 Sep '06

11 Sep '06

Joe McGuckin typed: >> 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedings that generated that order? Let's say you're eating lunch one day, minding your own business, and a sheriff comes up with an official looking document and says "You need to hand your car over to Fred..." because, unknown to you, Fred and Barney just finished court proceedings where the judge ruled that Barney had to give Fred "his" car, even though that car was owned by you and just loaned to Barney. Not a great analogy, because of the whole pink slip thing, but you get the point. -mark

9 9

BGP Update Report
by cidr-report＠potaroo.net 11 Sep '06

11 Sep '06

BGP Update Report Interval: 25-Aug-06 -to- 07-Sep-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4134 37938 2.8% 61.8 -- CHINANET-BACKBONE No.31,Jin-rong Street 2 - AS17974 18693 1.4% 36.9 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 3 - AS8685 13836 1.0% 406.9 -- DORUKNET DorukNet Istanbul / Turkey 4 - AS6197 11668 0.9% 11.3 -- BATI-ATL - BellSouth Network Solutions, Inc 5 - AS9121 11449 0.8% 97.0 -- TTNET TTnet Autonomous System 6 - AS15464 11391 0.8% 474.6 -- IHLASNET IHLASNET Autonomous System 7 - AS8386 10412 0.8% 433.8 -- KOCNET KOCNET-AS 8 - AS17557 10189 0.8% 28.4 -- PKTELECOM-AS-AP Pakistan Telecom 9 - AS15611 10017 0.7% 88.6 -- Iranian Research Organisation 10 - AS855 9974 0.7% 17.7 -- CANET-ASN-4 - Aliant Telecom 11 - AS34104 9297 0.7% 464.9 -- TELETEK-AS TELETEK TELEKOMINIKASYON HIZMETLERI A.S 12 - AS12497 8715 0.6% 174.3 -- SANET-GE SANET NETWORK (AS) 13 - AS7011 8589 0.6% 12.8 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 14 - AS33783 8176 0.6% 76.4 -- EEPAD 15 - AS4621 8164 0.6% 60.9 -- UNSPECIFIED UNINET-TH 16 - AS4787 8063 0.6% 30.2 -- ASN-CBN ASN CBNnet 17 - AS9394 8062 0.6% 17.6 -- CRNET CHINA RAILWAY Internet(CRNET) 18 - AS9021 7775 0.6% 555.4 -- ISNET ISBANKASI Autonomous System 19 - AS6198 7755 0.6% 15.0 -- BATI-MIA - BellSouth Network Solutions, Inc 20 - AS34695 7252 0.5% 164.8 -- E4A-AS E4A Primary AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3043 3039 0.2% 3039.0 -- AMPHIB-AS - Amphibian Media Corporation 2 - AS30298 988 0.1% 988.0 -- FIRST-AMERICAN-BANK-SSB - First American Bank 3 - AS34378 900 0.1% 900.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS12922 842 0.1% 842.0 -- MULTITRADE-AS Bank Outsourcer 5 - AS34984 794 0.1% 794.0 -- BITEL-AS BILISIM TELEKOM 6 - AS35080 784 0.1% 784.0 -- OYAK-TELEKOM-AS Oyak Telekom Hizm. BGP AS 7 - AS39298 762 0.1% 762.0 -- SERI Seri Bilgi Teknolojileri ve Destek Hizmetleri 8 - AS4271 1493 0.1% 746.5 -- WORX - Networx 9 - AS31526 745 0.1% 745.0 -- TEKOFAKS-AS TEKOFAKS 10 - AS29666 725 0.1% 725.0 -- TRHENKEL Turk Henkel Kimya Sanayi 11 - AS39080 721 0.1% 721.0 -- SIMETRI-AS SIMETRI YAZILIM 12 - AS31365 1432 0.1% 716.0 -- SGSTELEKOM SGS Telekom Autonomous System 13 - AS31085 711 0.1% 711.0 -- VIKINGNET-AS VIKING TUR 14 - AS29635 700 0.1% 700.0 -- BANVIT-AS Banvit A.S 15 - AS30734 682 0.1% 682.0 -- METISBILG-AS Metis Bilgi Sistemleri A.S 16 - AS31704 677 0.1% 677.0 -- ROBERTCOLLEGE-AS Robert College 17 - AS38920 676 0.1% 676.0 -- MNGBANK-TR Mng Turkiye 18 - AS39328 668 0.1% 668.0 -- BOTO-AS Borusan Oto 19 - AS31307 668 0.1% 668.0 -- YKYATIRIM YAPI KREDI YATIRIM 20 - AS29549 2646 0.2% 661.5 -- ZIRAATBANK-AS T.C. Ziraat Bankasi A.S. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.125.147.0/24 3980 0.2% AS17557 -- PKTELECOM-AS-AP Pakistan Telecom 2 - 208.0.225.0/24 3068 0.2% AS11139 -- CWRIN CW BARBADOS 3 - 209.140.24.0/24 3039 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 5 - 143.81.0.0/21 1618 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 6 - 205.98.32.0/20 1147 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 7 - 195.46.34.0/23 1013 0.1% AS31200 -- NTK Novotelecom ltd. 8 - 216.85.162.0/23 1001 0.1% AS6467 -- ESPIRECOMM - Xspedius Communications Co. 9 - 209.189.231.0/24 988 0.1% AS30298 -- FIRST-AMERICAN-BANK-SSB - First American Bank 10 - 205.97.69.0/24 933 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 11 - 130.36.88.0/21 931 0.1% AS2686 -- AT&T Global Network Services - EMEA 12 - 205.97.70.0/24 930 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 13 - 80.64.80.0/23 928 0.1% AS31200 -- NTK Novotelecom ltd. 14 - 193.242.123.0/24 900 0.1% AS34378 -- RUG-AS Razguliay-UKRROS Group 15 - 217.195.192.0/21 843 0.1% AS9121 -- TTNET TTnet Autonomous System 16 - 194.105.61.0/24 842 0.1% AS12922 -- MULTITRADE-AS Bank Outsourcer 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 18 - 216.51.192.0/18 808 0.1% AS5056 -- INS-NET-2 - Iowa Network Services 19 - 213.91.174.0/24 800 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 20 - 85.29.0.0/18 794 0.1% AS34984 -- BITEL-AS BILISIM TELEKOM Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org ausnog(a)ausnog.net

13 12

apple.com/mac.com Postmaster Contacts
by Tom Daly 10 Sep '06

10 Sep '06

Hi Folks, Does anyone have specific contact information for apple.com or mac.com postmasters? I've tried the standard postmaster/hostmaster addresses at both domains, with no response/autoresponders, etc. If you have this information available and are willing to share, please contact me of list. Thanks, Tom Daly -- Thomas J. Daly tom(a)dyndns.com Dynamic Network Services, Inc. http://www.dyndns.com/

1 0

Multiple BGP Routes in FIB
by Glen Kent 09 Sep '06

09 Sep '06

Hi, There is an interesting discussion going on in the IDR WG and i am cross posting a mail on Nanog to hear from the operators, if what is described below, a common practise followed by them: >> >> I don't think its correct to advertise one while using both for >> >> forwarding. >> >> NOTE: I am assuming that the routes share the same path length but have >> >> different AS Paths (as mentioned by you earlier in this mail) >> > >> > I think this is being done by many providers. >> >> Consider two paths for nlri X >> >> as_path 1 {x y z} next_hop n1 >> as_path 2 {m n z} next_hop n2 >> >> Are you suggesting that providers are installing ecmp routes for X with >> next-hops n1 and n2, while advertising only one of the paths to their IBGP >> peers? >> > Yes. Do providers really do this? Would they install multiple BGP Paths with different AS Paths (but same length) in their FIB, and yet advertise only one? Is the the right thing to do? Glen

4 4

Re: portability... HAH!
by Fergie 09 Sep '06

09 Sep '06

-- bmanning(a)vacation.karoshi.com wrote: [snip] >man I'd love to live in your universe... or are you suggesting >that things have evolved in the last decade to the point that the >ostensible goal of the IETF PIER wg can finally be met, to >completely renumber the entire Internet every 20 minutes... :) Man, I remember that vaguely. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Fergie 09 Sep '06

09 Sep '06

-- "Stephen Sprunk" <stephen(a)sprunk.org> wrote: >The entire suit is predicated on the concept that IP addresses can >be owned and traded like other property. The rest is a house of >cards that will fall if ARIN can prove that to be incorrect -- and >will probably stand if they can't. [snip] I like how Jack Bates framed it: The IP address space is a "community asset" and as such, the allocation of it needs to be done in a way which serves & benefits the Internet community at-large. That said, we have had this discussion many times over the years, especially within IEPG discussions, and punching holes in CIDR blocks, for the sake of alighning address space w.r.t. special interests (as opposed to some sanity in allocation policy which attempts to preserve allocation to allow CIDR aggregation) is a Bad Thing. It will be interesing to see how this plays out... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: Data Center Wiring Standards
by Frank Coluccio 09 Sep '06

09 Sep '06

I would add to the recommendations already stated by Mark and John the folllowing: Depending on the dimensions of the colo in question and the length of the cabling runs you plan to install, take note of the distance limitations of STP for DS1 signals and the in-house coaxial connections for DS3 signals and higher, which are (were) governed by ANSI/Bellcore, the last time I looked. Fiber, likewise, must be coordinated with network element interfaces (GBICs, ST, etc.) and here again distance is a major consideration. The latter may become an issue in large structures, or in the event that you plan to run media between buildings, or if you plan to interconnect with service providers at the f-o level (Layer1). For your optical media and connection hardware (patch panels, raceways, etc.), have a long hard talk with at least two reputable fiber optic cable suppliers (e.g., Corning, CommScope, Sumitomo, etc.) and develop an understanding about the limitations and advantages of the various s-m and m-m options you have available to you, per the types of solutions you need to implement and the distances they dictate. Incoming fiber from the street (dark fiber providers, included) will be single-mode, primarily, but the preponderance of your in-house cabling between switches, routers and servers, if fiber distances are indicated, will be multi-mode, requiring a different patch bay selection. Where distances permit (<100 meter channels) UTP should suffice for Ethernet speeds up to 10Gb/sec now, with 10Gb/sec (10GBASE-T) ratified only recently (I'm quite certain), but I suggest reading the following article from Cabling Installation & Maintenance Magazine, just the same. http://tinyurl.com/mrack Note, Cat5e and vanilla Cat6 will not suffice (perhaps a Cat6A will, not sure at this stage, but do your homework before purchasing anyone's Cat7) for 10GbE (it may work, but your hardware vendors will not honor warranties when problems arise), so be prepared to make some long range planning decisions in coming to terms with a cabling plant that's going to last you a while. HTH. Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile On Fri Sep 8 23:31 , John L Lee sent: > > > > > > > >Rick, > > > >The organization and standards you are looking for are: > > > >BICSI - http://www.bicsi.org/ and TIA/EIA 568 et al for structured >cabling design for low voltage distribution. > > > >The BICSI organization has training and certification for RCDD >Registered Communications Distribution Designer > > > >A BICSI article that is on there web site about data center design is >http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf. > > > >TIA/EIA 568(ab) how ever many they are up to discuss structured cabling >design for UTP/STP/fiber/coax including patch cables single and multi >pair UTP/STP/fiber patch panels, HVAC control, fire system control >and security systems. > > > >John (ISDN) Lee > > > > > > > >Rick Kunkel wrote: > > > Heya folks, > >I hope this is on-topic. I read the charter, and it falls somewhere along >the fuzzy border I think... > >Can anyone tell me the standard way to deal with patch panels, racks, and >switches in a data center used for colocation? I've a sneaking suspicion >that we're doing it in a fairly non-scalable way. (I am not responsible >for the current method, and I think I'm glad to say that.) Strangely >enough, I can find like NO resources on this. I've spent the better part >of two hours looking. > >Right now, we have a rack filled with nothing but patch panels. We have >some switches in another rack, and colocation customers scattered around >other racks. When a new customer comes in, we run a long wire from their >computer(s) and/or other device(s) to the patch panel. Then, from the >appropriate block connectors on the back of the panel, we run another wire >that terminates in a RJ-45 to plug into the switch. > >Sounds bonkers I think, doesn't it? > >My thoughts go like this: We put a patch panel in each rack. Each of >these patch panels is permanently (more or less) wired to a patch panel in >our main patch cabinet. So, essentially what you've got is a main patch >cabinet with a patch panel that corresponds to a patch panel in each other >cabinet. Making connection is cinchy and only requires 3-6 foot >off-the-shelf cables. > >Does that sound more correct? > >I talked to someone else in the office here, and they believe that they've >seen it done with a switch in each cabinet, although they couldn't >remember is there was a patch panel as well. If you're running 802.1q >trunks between a bunch of switches (no patch-panels needed), I can see >that working too, I suppose. > >Any standards? Best practices? Suggestions? Resources, in the form of >books, web pages, RFCs, or white papers? > >Thanks! > >Rick Kunkel > > > > > > >

1 0