- Test - lists.nanog.org

need contact info
by Naiming Shen 12 Sep '97

12 Sep '97

Any one has good contact info for crl.net? I tried noc(a)crl.net, peering(a)crl.net, routing(a)crl.net, all failed. any info also on ServInt.com? ------------------------------------------------------------------- - Naiming Shen MCI - MCI Internet Engineering 2100 Reston Parkway - +1 703-715-7056 fax: 703-715-7066 v272-7056 Reston, VA 20191

5 4

Re: need contact info
by Sean Donelan 12 Sep '97

12 Sep '97

nshen(a)mci.NET (Naiming Shen) writes: >Any one has good contact info for crl.net? I tried noc(a)crl.net, >peering(a)crl.net, routing(a)crl.net, all failed. > >any info also on ServInt.com? Since NANOG seems to have turned into directory assistance, does anyone know the preferred, listed, international phone number for the MCI NOC, not a 1-800, or 1-888 number. Hopefully a number that will be in service longer than three months. All the non-1800 phone numbers our MCI sales person locate seem to be DID numbers to individual's voice mail or stop working when the person leaves MCI. Hint, Hint: I have 9 other North American Network Operators on my contact list which seem unable to supply a direct-dial non-1800 phone numbers. And unlike Joe McCarthy, I'm willing to show you my list. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: ATM (was Re: too many routes)
by Tony Li 12 Sep '97

12 Sep '97

> >Again, Sean will have to identify pst, but tli is Tony Li of Juniper > >formerly of Cisco and 10.2-viktor is one of many IOS versions. I suppose > >most people realize that ICM-DC is ICM in Washington DC and RENATER is a > >large network in France. > > So far three people have informed me that pst is Paul S. Traina currently > with Shockwave. You might note that Shockwave Engineering is Paul's home consulting firm. His full time employment is at Juniper. You might note that Li Consulting is my home consulting firm. My full time employment is at Juniper. Leon and Viktor are not Juniper employees. Yet. ;-) Tony

1 0

Re: ATM (was Re: too many routes)
by Michael Dillon 12 Sep '97

12 Sep '97

>Again, Sean will have to identify pst, but tli is Tony Li of Juniper >formerly of Cisco and 10.2-viktor is one of many IOS versions. I suppose >most people realize that ICM-DC is ICM in Washington DC and RENATER is a >large network in France. So far three people have informed me that pst is Paul S. Traina currently with Shockwave. >>Oh that and helping beat on CEF/DFIB packet-by-packet load >>balancing before my last retirement. > >Once again, I'm at a loss as to what CEF/DFIB stands for. And a couple of replies on this one... here's the OFRV employee version: CEF (Cisco Express Forwarding) is the marketing name of what we originally called FIB (Forwarding Information Base, where the FIB is initially completely populated, instead of traffic- driven cached). The dCEF/dFIB reference is where the FIB is pushed onto the VIP (Versatile Interface Processor) cards, otherwise known as the linecards. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

2 1

The Cidr Report
by Tony Bates 12 Sep '97

12 Sep '97

1 0

House panel votes behind closed doors to build in Big Brother
by Declan McCullagh 12 Sep '97

12 Sep '97

---------- Forwarded message ---------- X-FC-URL: Fight-Censorship is at http://www.eff.org/~declan/fc/ Date: Thu, 11 Sep 1997 23:37:39 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> Sender: owner-fight-censorship-announce(a)vorlon.mit.edu To: fight-censorship-announce(a)vorlon.mit.edu Subject: FC: House panel votes behind closed doors to build in Big Brother Software that protects your privacy is a controlled substance that may no longer be sold, a Congressional committee decided today. Meeting behind closed doors this morning, the House Intelligence committee voted to replace a generally pro-encryption bill with an entirely rewritten draft that builds in Big Brother into all future encryption products. (The Senate appears to be moving in a similar direction.) The new SAFE bill -- titled in a wonderfully Orwellian manner the "Security and Freedom through Encryption" act even though it provides neither -- includes these provisions: SELLING CRYPTO: Selling unapproved encryption products (that do not include "immediate access to plaintext") becomes a federal crime, immediately after this bill becomes law. Five years in jail plus fines. Distributing, importing, or manufacturing such products after January 31, 2000 is another crime. NETWORK PROVIDERS: Anyone offering scrambled "network service" including encrypted web servers or even "ssh" would be required to build in a backdoor for the government by January 31, 2000. This backdoor must provide for "immediate decryption or access to plaintext of the data." TECHNICAL STANDARDS: The Attorney General will publish technical requirements for such backdoors in network service and encryption products, within five months after the president signs this bill. LEGAL TO USE CRYPTO: "After January 31, 2000, it shall not be unlawful to use any encryption product purchased or in use prior to such date." GOVERNMENT POWERS: If prosecutors think you may be selling, importing, or distributing non-backdoor'd crypto or are "about" to do so, they can sue. "Upon the filing of the complaint seeking injunctive relief by the Attorney General, the court shall automatically issue a temporary restraining order against the party being sued." Also, there are provisions for holding secret hearings, and "public disclosure of the proceedings shall be treated as contempt of court." You can request an advisory opinion from the government to see if the program you're about to publish violates the law. ACCESS TO PLAINTEXT: Courts can issue orders, ex parte, granting police access to your encrypted data. But all the government has to do to get one is to provide "a factual basis establishing the relevance of the plaintext" to an investigation. They don't have to demonstrate probable cause, which is currently required for a search warrant. More interestingly, this explicitly gives the FISA court jurisdiction (yes, the secret court that has never denied a request for a wiretap). If they decode your messages, they'll tell you within 90 days. GOVERNMENT PURCHASING: Federal government computer purchases must use a key escrow "immediate decryption" backdoor after 1998. Same with networks "purchased directly with Federal funds to provide the security service of data confidentially." Such products can be labeled "authorized for sale to U.S. government" ENCRYPTION EXPORTS: The Defense & Commerce departments will control exports of crypto. Software "without regard to strength" can be exported if it includes a key escrow backdoor and is first submitted to the government. Export decisions aren't subject to judicial review, and the "president may by executive order waive any provision of this act" if he thinks it's a threat to national security. Within 15 days, he must send a classified briefing to Congress. ADVISORY PANEL: Creates the Encryption Industry and Information Security Board, with seven members from Justice, State, FBI, CIA, White House, and six from the industry. INTERNATIONAL: The president can negotiate international agreements and perhaps punish noncompliant governments. Can you say "trade sancation?" (Other provisions barring the use of crypto in a crime and some forms of cryptanalysis are also in the bill.) Next the Commerce Committee will vote on SAFE, and a former FBI agent-turned-Congressman is vowing to ensure that similar language to this is included. (The committees are voting on the bill in parallel, and a four-person team of Congressmen is working to forge a compromise before Commerce votes.) Then the heads of the five committees that have rewritten the legislation will sit down and work out another compromise. If it's acceptable to the House Rules committee -- and if the FBI/NSA get what they want it will be -- the bill can move to the floor for a vote. That's why the encryption outlook in Congress is abysmal. Crypto-advocates have lost, and lost miserably. A month ago, the debate was about export controls. Now the battle is over how strict the //domestic// controls will be. It's sad, really, that so many millions of lobbyist-dollars were not only wasted, but used to advance legislation that has been morphed into a truly awful proposal. I wrote more about this at: http://cgi.pathfinder.com/netly/opinion/0,1042,1385,00.html -Declan -------------------------------------------------------------------------- This list is public. To join fight-censorship-announce, send "subscribe fight-censorship-announce" to majordomo(a)vorlon.mit.edu. More information is at http://www.eff.org/~declan/fc/

2 1

R: not rewriting next-hop, pointing default, ...
by Enke Chen 12 Sep '97

12 Sep '97

For ISPs with a lot of direct (i.e., private) peers, on the public NAP routers you may want to consider not installing the routes from the private peers. This approach could reduce the damage to your private links by default-pointing attack. It may also make you less likely a target due to black-holing of certain traffic. This approach is not applicable if transit service is provided at the public NAP. -- Enke > Nanog archive > ---------------------------------------------------------------------- > [Prev][Next][Index][Thread] > > Re: not rewriting next-hop, pointing default, ... > > ---------------------------------------------------------------------- > > * To: dlr(a)bungi.com (Dave Rand) > * Subject: Re: not rewriting next-hop, pointing default, ... > * From: Naiming Shen <nshen(a)mci.net> > * Date: Fri, 12 Sep 1997 10:00:23 -0400 > * cc: Randy Bush <randy(a)psg.com>, Naiming Shen <nshen(a)mci.net>, > nanog(a)merit.edu > * In-reply-to: Your message of "Thu, 11 Sep 1997 22:02:35 PDT." > <m0x9NsK-0000LvC(a)daver.bungi.com> > * Sender: owner-nanog(a)merit.edu > > ---------------------------------------------------------------------- > > Ha, it's amazing how fast people learn when they have to. Yesterday > someone send us a traceroute: > > % traceroute -g 192.41.177.98 www.mci.net > .... > 6 core1-hssi3-0-gw.Washington.mci.net (204.70.1.222) 246 ms > Naiming Shen MCI > - MCI Internet Engineering 2100 Reston Parkway > - +1 703-715-7056 fax:703-715-7066 v272-7056 Reston, VA 20191 > > ----------------------------------------------------------------------

1 0

Re: ATM (was Re: too many routes)
by Carmen Hillenburg 12 Sep '97

12 Sep '97

Sean M. Doran wrote: > BTW, your formatting sucks to the point that your note is > unreadable and unquotable without fmt(1) or fill-paragraph. Sorry, bad program to send from ;{ >So anyway, as I was saying, I'm ignorant about such matters. Cute. ;) Its nice to know you have a sense of humor ! >Oh now THERE's a reliable source. "Hi my name is Frank > and ATM will Just Work. Hi my name is Warren and ATM is > fantastic.". Ugh. (kent bait kent bait kent bait) Not my point, I was just quoting my "source" of timings, nothing more. >At higher bandwidths bits are shorter not faster. Yes, but at lower bandwidth they are spaced further apart. >Repeat that several times. Yes, do. >Whether you are signalling at 300bps or at >293875983758917538924372589bps, the start of the first bit >arrives at the same time. I was talking about a total performance increased experienced by more bandwidth, not *just* latency. BTW the total transmission time is still reduced, my original point. I was careful to note the resultant transmission time, not latency. Also, if the cell entered the net to carry the "first bit" before it's natural TAT...... >Um, no it doesn't. As with all demand-cached forwarding >schemes you have to process a packet heavily when you have >a cache miss. You are right. I was not accurate on full implementation detail, but the concept was there. I *really* must remember *not* to use simplifications for brevity in the nanog list. But, the description was not intended as an RFC. I was only noting the advantage to not needing to look up where to send a packet , * every time *. > MPLS is conceptually related, btw. Interesting. PS. I am a supporter. >P.S.: You have some very entertaining and unique expansion > of a number of acronyms in general and relating to > ATM in particular. I'm curious how you expand "PDH". > Personally I favour "Pretty Damn Historical", > although other epithets come to mind. I repeat, I will NEVER, NEVER, NEVER, over simplify for brevity to the nanog again. Bad Richard, Bad! (But each one gave you the general idea, didn't it.) I rather liked your response(s), it was informative. I still hold to my point, though. Now rather than fire a response to all those flames, one at a time.... To One individual: Yes, I used some terms from Frame Relay, instead of ATM. (OOPs! I work with all the above, and it was the end of a 10 hour day) And yes, the acronyms are in error in literal expansion, however, not in concept. They perform the same BASIC function. ---------------------------- Never, never, never again.... ---------------------------- And to another, I did not claim that the speed of light is NOT a factor, just not the only one. And since I cannot change the speed of light ..... ---------------------------- Bad! Never, Never.. ---------------------------- (One guy hated a 12ms difference between my "on the cuff estimate", and his calculation of the RTT.) Boy, THAT invalidates ATM. ---------------------------- Never, Never, Never... ---------------------------- > I wasn't around for the invention of statistical muxing, >but I'm sure there are some people here who could clarify >with first-hand knowledge (and I'll take email from you, >thanks :) ). Neither was I. However, I wasn't being quite that literal. I will accept that I presented an inaccuracy. SDM just allowed more diverse use of a given voice circuit. A lot of this chain-flame is my fault, a little too tired.., and not exacting detail. However, Sorry, I still hold to ATM being superior for WAN, and possibly exchange delivery. This does not mean ATM will hold as well as other technologies when seriously OVERSUBSCRIBED. (Now, what fool would do that .) But, I should note that during the recent "brown outs" it was not the ATM NAP's that were collapsing. (Not that some peoples ports weren't lossy) Many of you picked at details you could find wrong, from spelling to 12ms differences in earth round trip time. etc. I hope some of you noted what was right. Those points never seem to get "cut and pasted." Some times you just can't see the forest for the all tree's in the way.. And boy there were a LOT of tree's. A) ATM is better. B) No its not! A) Yes it is! B) No its not! A) Yes it is ! B) Your hair is died !! A) Uhhh...Its only grecian formula... B) Is that your natural color ? A) Well, no, I told you I use greci... B) uh-huh, SEE! ATM isn't better! A) sigh....... Wasn't this on Monty Python ?

2 1

Re: LSR and packet filters
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 21:06, Sean M. Doran wrote: % Cool, and I now view the 2-hop notion as the first % reasonable argument for encouraging people to totally % flatten their network into a full mesh. Hmm. I wouldn't go that far :-). % Security policy should not under any circumstances prevent % the Internet as a whole from functioning reasonably well, % scaling decently, or make discovering and diagnosing % problems any harder than it already is. A reasonable security policy is focused on maintaining network availability and uptime. If one focuses exclusively on diagnostic tools, one's network will be down much more often than if one strikes a reasonably balanced overall perspective on things. All IMHO. % Your opinion may vary with mine, but I am solidly in line % with Randy's suggestion that enabling LSRR on backbone % routers should be a requirement for peering. (This is not % surprising as I used to require it of a couple of peers in % a previous life, because in practice it is unfortunately % an irreplaceable diagnostic tool). You haven't defined terms (e.g. "backbone router"), so your meaning is not clear. Assuming that "backbone router" is only those within 2 hops of an external connection and that one has a network with nice deep heirarchy (much more than 2 levels), I could agree with you. :-) I will note that its none of someone else's business what one's internal topology looks like. The only _legitimate_ need of a peer is to be able to isolate the problem to one's network (or someone else's network) so that the peer can then come after one (or one's NOC) to fix the problem(s). So I'm not trying to kill off LSR as a diagnostic tool, merely limit the downside operational risks of LSR to a reasonable level. The ultimate goal of my proposal is to _enhance_ network availability. Ran rja(a)home.net Disclaimers from yesterday's note all apply; especially the one about not enough coffee. :-) PS: I've revised the subject line to be more clear.

1 0

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

Nathan Stratton <nathan(a)netrail.net> writes: > This is what I beleave sprint is doing. They are using the new Cisco 12000 > GSR with external router servers. It is a smart way of patching the > problem. If you need more CPU or memory you can just add a bigger box and > more RAM. The GSRs are to move bits fast. They are not to act as route servers. Sprint recently announced that they are deploying 622Mbps POS cross-country links, and the GSRs are the only things you can put on the ends of such beasts that are available today. (Someone may point out that it may not be the only choice for very long, however, it's the only one whose design I know and have had any influence upon, and is therefore frankly the only one I trust, although I don't expect the people building the competing box will ship anything but a good product even if they are now rather deeply in bed with the cell-heads and about as transparent to most observers as the Kremlin during the cold war... The box being built by someone who actually worked very close to the Kremlin during the cold war is also something I don't know enough about, however that is much more due to my neglect than due to organizational attitude.) Remember that a current snapshot is not a good indicator of future health. Sure the processing demands of routing are such that the GSR's main CPU is largely idle after converging with its neighbours, however there is still a CPU spike during convergence and the processing load is non-zero. If you increase the growth curve of the number of prefixes, you increase the CPU demands during large-scale convergence. You also statistically increase the CPU demand after convergence unless you reduce the probability of any given prefix transitioning from up to down or vice versa over time. If you have a growth curve where the processing load during large-scale convergence and the processing load to handle background noise increases beyond processing capacity faster than processing capacity can be increased, you lose, no matter how crunchy your box is today relative to today's processing demands. In other words, removing the feedback mechanisms on the growth of the number of globally-visible prefixes and on prefix instability is probably a really bad idea. Sean.

5 5