- NANOG - lists.nanog.org

RE: dsl providers that will route /24
by Roeland Meyer 28 Mar '01

28 Mar '01

> -----Original Message----- > From: David Schwartz [mailto:davids@webmaster.com] > Sent: Wednesday, March 28, 2001 3:38 PM > Fine with me, I don't care. (But think long and hard before > coercing your > customers into an arrangement you yourself couldn't live with.) I think that this is a good general rule, that many tend to lose sight of. Do unto others, as you would have them do unto you.

1 0

RE: MBone access
by Bill Nickless 28 Mar '01

28 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- At 07:30 PM 3/27/2001 -0500, Martin, Christian wrote: >One of the things that appears to be a major impediment to large-scale >deployment is the lack of SA transitivity, which is limited by MSDP's RPF >rules. Therefore, the Internet needs a dense mesh of MSDP peerings to allow >any-to-any connectivity. As of now, this is not the case. SSM will fix >this. > >regards, >chris Two responses, not mutually exclusive: - The Internet already has a "dense mesh" of BGP peerings. All the pieces are in place from the major router vendors to turn on MSDP and PIM-SM at the same places; it seems to me that it's just a matter of doing it. - Come on over to the IETF MSDP working group. In Minneapolis I presented an I-D that would avoid the RPF rules. However, in the MSDP working group there is very strong resistance to dropping the RPF rules, because then you can't build an "MSDP traceroute". My personal response to that is something along the lines of 'there is no "DNS traceroute" but DNS works just fine anyway, and you just use other mechanisms to debug it.' It was agreed in Minneapolis that building an RPF-free MSDP would be deferred until the current MSDP reaches standard status, and then we would build MSDPv2 without RPF rules if we thought it was needed. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOsJkF6wgm7ipJDXBAQGIWwP/ZjtGv/fA1I17v2GQD/jeW2zWzBgj9z30 ZsgOi6xUBfKFHvzaB+NMSP+CYAiv9jXhusR1MHeH/+vSDEP5Z5wSYNF39/uEC1zd kLA0WGyIF/+zm7VXMsxdx4iwb+iSVhaTbIA+TYcgsQzigNnWbfWpnB43EvNDp6Xb x7tjGssZkAY= =nsmd -----END PGP SIGNATURE-----

1 0

Re: MBone access
by Bill Nickless 28 Mar '01

28 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- At 03:23 PM 3/27/2001 -0500, Jared Mauch wrote: > Should someone do a presentation @ NANOG on how to configure >multicast in the pim-sm,msdp,mbgp days? Also, with ssm there >is almost no configuration that will be required other than >turning on pim (and mbgp.. no msdp is needed). The week before NANOG I've agreed to do just such a tutorial at the next Internet2 meeting. If there's interest I would be happy to run the same tutorial at NANOG the following week. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOsJjIKwgm7ipJDXBAQHxdgP/dmv5DUaAswclI0M53Zc3YXo813/rIh0S gg8q3xs0qypSz7xnid4uHL3UBvCwQA3Nqi51DUNJmtbOo3gsB+93CEOoHlJL4ETj vaRe6cCi1H5xCa452Bp9S37js3QJxTiIkR545Laf4E9sQ+rXqBD0rI0xXIIRJ+ue jF6mJGH80m4= =BymP -----END PGP SIGNATURE-----

1 0

Looking for a T-1 loop in Antigua
by Justin A. Kraft 28 Mar '01

28 Mar '01

I have a connection opportunity in Antigua, but I need to find a provider who would be able to provide a clear channel T1 from Ft. Lauderdale to Antigua. Any suggestions? Justin A. Kraft Sales Engineer PRIMUS Managed Hosting Solutions (781) 586-6141

1 0

RE: Statements against new.net?
by Roeland Meyer 28 Mar '01

28 Mar '01

> From: Vadim Antonov [mailto:avg@kotovnik.com] > Sent: Wednesday, March 14, 2001 12:46 PM > > On Wed, 14 Mar 2001, Mathew Butler wrote: > If it is machines communicating there's no need to do any > mnemonics. In > fact, it is still humans communicating, with the aid of the machines. > > So... we have two design constraints: > > 1) people need to be able to locate and revisit somethings in > the network > > 2) any meaningful hierarchial labeling of the real world is quite > impossible, and runs into problems of scaling, adversity, and > entrenched notions of ownership. > My proposal is to create a special hierarchy (similar to > tpc.int) which > can _only_ be used to register numeric "names" on first-come > first-served > basis. The "current" DNS then can go down in flames, for all i care. > Actually, I think this is inevitable, since some day someone > will find a > way to win a lawsuit against the whatever central naming authority is. > > Anyone who thinks numeric IDs do not work when "better" > alphanumeric IDs > are possible needs to take a look at the ICQ. It is _very_ > successful in > case you didn't notice. And so is telephony. Two points, ICQ has an address manager add-on and my contact manager makes it so I don't have to memorize phone numbers. I scroll down select and talk. New SprintPCS systems even eliminate that, you speak the name and it dials for you. Suddenly, you get into your 40's and there is more to remember than you want to work at. I'm sure you know what I mean. What about that number that you absolutely have to have, every six months? I just hacked a print server because I couldn't remember the passwd, that was last used over three years ago. I don't even know my insurance agent's name, but when someone wrecks my car, I absolutely HAVE to have his number. Long-term human memory is much better at names than numbers and is MUCH better at general class names than specific identifiers. It has to do with refresh rates, just like DRAM. > fact: for the majority of world population ASCII strings are only > marginally better than numbers in being "mnemonic" - and it > is much easier > to pronounce numbers in a native language. Okay, so you would propose yet another layer of virtualization? Let us count the layers we have already; 1) Layer 2 to IP, used by switches and the like. Services are divorced from IP addrs. Where you route is not where you think you are routing. 2) NAT, Site virtualization. You could renumber the underlayment of the NAT'd space and the outside world will never know ... 3) Straight IP virtualization, used by resonate and F5, as well as local directors, the answering host need never be the same host twice. 4) DNS, separates you from the IP addr layer altogether. If you put design dates on each of those you will probably find that they are pretty much developed in the order I listed. Each case was to implement a technical solution to a policy issue, in a futile attempt to build technical barricades between the technologist and the politicians. Give it up, you will be assimilated. You have been in retreat for years. You just didn't realize it. Vadim, you're an analyst too, how many layers of abstraction can we have before the system becomes unusable, unwieldy, non-performing, and more difficult to maintain than the tower of Babel? Speaking of which, your other point about ASCII names is also moot, with iDNS. The real answer was to stop the incursion of trademark crowd into the DNS. You can thank Dave Crocker, Kent Crispin, and their IAHC for that smooth move. Now if you think that they'd stop just because you have retreated behind yet another layer of abstraction, you are indeed naieve. They will come and hunt you out. The inclusive root zone efforts, like that of the ORSC and PacRoot, are actually trying to keep the root intact. We saw the probability of outfits like new.net, years ago. We also recognised what it meant. We spoke the warnings, we spoke them again at the Nov00 ICANN meeting in MDR. However, what really triggered the race was when the ICANN BoD assigned the BIZ TLD, knowing full well that the Atlantic Root had been registering domains there for years. That told the new.net folks that it is okay to create conflicting delegations. After all, the ICANN is doing it ... why can't they? There is no law that regulates that. There's a lot of other stuff behind that, but, I think that you get the point.

10 12

Re: Looking for a good dual homing situation in Macomb County, MI
by John Palmer (NANOG Acct) 28 Mar '01

28 Mar '01

Actually we are going to have UltraDNS do secondary for us starting in April and eventually will also become dual homed. ----- Original Message ----- From: "jamie rishaw" <jamie(a)arpa.com> To: "John Palmer (NANOG Acct)" <nanog(a)adns.net> Sent: Tuesday, March 27, 2001 12:56 PM Subject: Re: Looking for a good dual homing situation in Macomb County, MI > Why don't you partner with someone to provide you a second physical > site? That would be the best, especially for TLDs. > > You never want to run a TLD out of one site. > > Let me know if I can be of assistance. > > jamie > > On Sun, Mar 25, 2001 at 03:30:39PM -0600, John Palmer (NANOG Acct) wrote: > > Hi - We currently have PSINet routing our CIDR block to us over a DSL connection. I'd like to become dual-homed (for reliability). > > > > Anyone know of a DSL provider that serves our area and also will route an address block that isn't one of their blocks? > > > > We operate an ORSC root server as well as several large TLDs and need the reliability of two connections. > > >

1 0

Content Injection Appliance
by shane 28 Mar '01

28 Mar '01

I need someones help, I saw a product at ISPCON Fall in CA. And the product allowed me to have it operate on my core routers and watch web traffic and allow me to "Inject" a "pop-up add" or a service anouncement. I have been searching my ISPCON "stuff" I collected and I can't find it, and it is driving me crazy. What I want to do is set up this box to watch web traffic, and when a new user logs in it checks to see "for example" if he has new mail on our mail-server, and pop-up a little window on his/her screen alerting them about this. But I don't want to make the user be required to use our home page as the start page. Can anyone tell me the name of this product, I am already aware of FrontPorch and their product would work, but they require me to allow them to to advertising to my customers, I don't want that. shane brath TDS.NET Internet Services shane(a)bratnet.net

2 1

Re: RADIUS info for traveling users ...
by Mohan Sundar 28 Mar '01

28 Mar '01

Thanks for your responses and correcting my understanding. What i understand is policies are stored in a centralized policy server, and these are pushed to the Access Servers thru some mechanism, like SNMP or file transfer, etc. What is achieved by RADIUS is just getting pointer (like filter name) to the policy corresponding to a subscriber when a subscriber dials in, and dynamically binding that to the access interface in the access server. How are these policies then dynamically generated, based on the IP address that is dynamically assigned? Do policy servers also have policies based on subscriber-name (or ID)? What is the interaction between policy server and RADIUS? Thanks again. - elwin --- Brett Frankenberger <rbf(a)rbfnet.com> wrote: > > A Service Provider, having several POPs, I presume > > will be using at least one RADIUS server that is > > associated to each POP, and are usually colocated > > at the POP, along with the RAS, aggregation and > other > > IP service devices. > > For most providers, you presume incorrectly. RADIUS > is generally > hosted centrally. > > > And the IP address assigned for a subscriber > dialing > > up from one location is assigned by the > corresponding > > RADIUS server, after authentication. > > The IP Address is generally assigned by the access > server. > > > To take it further, when policies are associated > with > > this subscriber that are based on IP address, how > > is that handled when the subscriber travels? > > Static IP addresses that give a customer the same IP > address ragardless > of what POP he dials are rarely offered by dial-up > providers. Those > that do necessarily have some sort of routing hack > to get their routing > tables updated when the ustomer dials into a remote > POP. Policy is > generally implemented by filters on the Access > Server that are > dynamically created (by the RADIUS server) when the > customer dials in, > so it isn't necessary that the customer always have > the same IP > address. > > -- Brett __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text

2 1

RE: Microwave...
by Paul Lantinga 28 Mar '01

28 Mar '01

I recall that when I was working in Bangalore, India, another multinational company (I think it was Siemens but I can't recall definitively) had to poison the vultures that consistently perched on their microwave dish to get reliable point to point. Given the complete non-regulation of spectrum out there, at least once we had another provider clash with our spectrum[1], forcing us to flip the dips until we found a clear one. However, when it worked, it was incredibly solid. Chocolate bars in India were usually melted already when you bought them. ;) [1] Sometimes they would clash physically with us when they mounted extra dishes on the tower in the downtown location - as in, some guy standing on our dish to mount his. -- Paul LANtinga Q9 Networks, Inc. > -----Original Message----- > From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net] > Sent: Tuesday, March 27, 2001 9:21 PM > To: Dee McKinney > Cc: NANOG > Subject: RE: Microwave... > > > > > We've got a customer on a DS3 microwave shot. It's been more reliable > than their copper DS1 backup and has the added benefit of > being able to > melt hershey bars in nothing flat! (Old MCCES@MCAGCC29 joke) > > > --- > John Fraizer > EnterZone, Inc > > On Tue, 27 Mar 2001, Dee McKinney wrote: > > > > > If it's a commercial carrier grade shot, and it's been > engineered correctly, > > and, and, and...... > > It should work fine as I have service on microwave that > operates as good as > > our fiber. > > > > -----Original Message----- > > From: Rodney Joffe [mailto:rjoffe@centergate.com] > > Sent: Tuesday, March 27, 2001 3:16 PM > > To: NANOG > > Subject: Microwave... > > > > > > > > I' be interested in hearing about any operational > experience the users > > on this list have had, such as issues and challenges with routing, > > reliability, etc., with the use of Microwave at DS3 or > greater level.... > > > > -- > > > > > >

2 1

late DEW - 2q2001
by Bill Manning 28 Mar '01

28 Mar '01

Hi, I appologize for duplicates. Its almost time for the next quarterly walk of the inverse tree of the DNS. Since 1997, I've been walking the in-addr tree looking for numbers of delegations, accurate delegations, and types and styles of error conditions. So... this is a heads up that you will be seeing zone transfers being generated by a couple of the collecter machines here. For those of you who utilize BINDs access controls, I'd appreciate your inclusion of the collector machines in allowed transfers. The expectation is that they will be the following IP addresses: 128.9.160.57 and 198.32.4.13 If there are any questions or concerns, I'd be happy to talk about them. Past data has been presented at IEPG, Apricot and RIPE meetings. The expectation is that future data will be presented in the same and similar forums. Past data may be viewed at: http://www.isi.edu/~bmanning/in-addr-audit.html --bill 310.322.8102

1 0