- Test - lists.nanog.org

MAE-ATM Wire Speed PVC Interest Poll
by Mike Leber 11 Sep '00

11 Sep '00

MAE-ATM users, if you are interested in having the option to set a PVC to wirespeed (like Pac Bell or Ameritech) (which can increase your effective utilization of your MAE-ATM port and reduce management costs) please send me email with your name, your company name, your phone number and your email address. I will pass the collected list onto this manager (email below) at Worldcom. The information will be used for that purpose only. Thank you, Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +---------------------------------------------------------------------------+ ---------- Forwarded message ---------- Date: Mon, 11 Sep 2000 13:11:42 -0400 From: Alla Reznik <Alla.Reznik(a)wcom.com> To: Mike Leber <mleber(a)he.net> Subject: RE: MAE OC40 requirements?? - Hurricane Electric (fwd) Would be very very helpful - please send if you could, thanks Alla Reznik Manager Int'l Internet/MAE/Paging/Packet WorldCom Business Markets V227-6441 or (703)343-6441 -----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Sunday, September 10, 2000 8:26 PM To: Alla Reznik Subject: RE: MAE OC40 requirements?? - Hurricane Electric (fwd) If I could give you a list (with contact names and phone numbers) of MAE-ATM customers that want this feature would it help? On Sun, 10 Sep 2000, Alla Reznik wrote: > Thanks for the feedback, Mike. > > Alla Reznik > Manager > Int'l Internet/MAE/Paging/Packet > WorldCom Business Markets > V227-6441 or (703)343-6441 > > > > > -----Original Message----- > From: Mike Leber [mailto:mleber@he.net] > Sent: Thursday, September 07, 2000 2:24 AM > To: Alla.Reznik(a)wcom.com > Subject: Re: MAE OC40 requirements?? - Hurricane Electric (fwd) > > > > Our number one request is for wirespeed PVCs like Pac Bell NAP or > Ameritech. This feature could be added with a checkbox in peermaker. > > > Date: Mon, 07 Aug 2000 15:17:41 -0400 > > From: Alla Reznik <Alla.Reznik(a)wcom.com> > > To: peering(a)he.net > > Subject: MAE OC40 requirements?? - Hurricane Electric > > > > Dear customer, our records indicate that you are using OC12 MAE ATM > service > > from WorldCom. We would like to find out from you if you have any plans to > > move up to OC48 level of service and what are your specific requirements > for > > such service would be. As you might already know Worldcom does not offer > > MAE service above OC12 level at this time, but we recognize it as a > > requirements going forward and have made plans to offer it next year. > > However, we would like to hear from you and learn more about your > > requirements as well as timeframe as to when you are planning to make such > > move, so that we can respond in the best manner possible with the service > > suitable to your requirements. > > > > Alexandra (Alla) Reznik > > WorldCom Business Markets > > Data and Enterprise Product Marketing > > Int'l Internet, MAE, and Packet Services > > (703) 343-6441 > > http://datamarketing.wcomnet.com/index.html > > > > > > +------------------- H U R R I C A N E - E L E C T R I > C -------------------+ > | Mike Leber Direct Internet Connections Voice 510 580 4100 > | > | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 > | > | mleber(a)he.net http://www.he.net > | > +--------------------------------------------------------------------------- > + > +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +--------------------------------------------------------------------------- +

1 0

RE: PI or PA?
by James Cumming 11 Sep '00

11 Sep '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ray, You'd be better off getting the customer to apply for a /24 of PI space. It is entirely possible for a provider to advertise address space that belongs to a different provider although most providers will refuse to do this as it requires co-operation between providers to both set-up (and in future remove). Most providers tend to have a standard portfolio of 'products' and these do not normally include multi-homing clients with other service providers whilst using their own address space. A normal service to sell is transit, i.e.. routing a customers PI space (and their AS). This way you need not care which other provider the customer approaches, nor pay any attention to the set-up process with that ISP as they are done independently. James - -----Original Message----- From: Ray Davis [mailto:ray@carpe.net] Sent: 05 September 2000 20:51 To: nanog(a)merit.edu Subject: PI or PA? A customer needs a /24 which is to be announced by us and other ASes (including uunet). Should we just give them a /24 out of our space or would it be better to apply for a /24 PI space? Thanks, Ray -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBObY9XDyrtEQtecfwEQJeRACgmbpWVGaQ/Go28OratCo3c/m3uHsAn3oM Rfkxc28evO4gMEopGzsjS35R =AXKc -----END PGP SIGNATURE-----

2 1

RE: ISPs offering VPN service
by Christian Kuhtz 11 Sep '00

11 Sep '00

Hey Chris, I'm not sure we're actually arguing against each other, but just to clarify... nothing wrong with enforcing a topology (or rather traffic flow) inside the SP cloud. Neccessary, and very much needed from the SPs standpoint. What makes up a topology is much more dimensional (IMHO) than just hub-and-spoke etc. So, instead of one blindly taking from customers (stubborn as they may be about it) a topology, rather than a service definition and build the most suitable topology based on that definition.. definition = "SLA"/"OLA" or other type of contract. Ideally (hah!), customers should care about how much data (if they even know quantitive measures of their traffic) from where to where, and which what characteristics (qualitative is almost equally tricky, but more achievable) by giving customers guides etc, without actually limiting them to chosing those slots. Seems once you monitor, whether you monitor in buckets or raw is more a marketing question that technical. In my experience, most customers know little or nothing about their actual needs. Once "trained" by the telcos to order in arbitrary categories such as 56DDS, T1, T3, OC-x, they sometimes don't even know they're using up all available capacity. Some don't even care. And a service offering has to match all. So, you should be able to have a "quick order VPN" as well as an "a la carte VPN". So, that's where a service provider should step in and provide guidance and counseling, since it is truely in both best interest. As one can see, though, this does very quickly transcend the technical domain. Either way, MPLS VPNs do permit both, defaulting on any one mechanism appears to be a disservice, IMHO. Interaction is what's needed, rather than engineering in a vacuum. Cheers, Chris PS: To me, hub and spoke with a single link to the hub is no longer true hub and spoke, because of the aggregation performed. Anyways, semantics, I suppose. -- Christian Kuhtz, Sr. Net & App Architect Architecture, BellSouth.net <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Atlanta, GA "Speaking for myself only." > -----Original Message----- > From: Chase, Christopher J (Chris), ALNTK [mailto:chase@att.com] > Sent: Monday, September 11, 2000 1:40 PM > To: 'Christian Kuhtz'; 'mpls wg' > Subject: RE: ISPs offering VPN service > > > Enforcing a topology within the provider portion of the VPN makes perfect > sense, rather than expecting the VPN owner to enforce a topology. > > Customers may not have the capability to implement or manage TE tunnels to > enforce a topology on top of the any-to-any connectivity. In addition, that > would require running MPLS to the CE instead of providing a VPN service that > uses standard IP CE-PE interface (e.g., FR or PPP). > > Examples of wanting other topologies: inter corporate extranets, network > based firewall services, regional company gateways. > > One big advantage of the MPLS VPN hub-and-spoke topology over the > private-line/VC model is circuit aggregation. The hub or data center site > only needs to terminate a single logical connection independent of the > number of remote sites. I know a lot of large enterprise networks using the > PVC hub-and-spoke model having to spread those PVCs across many ports and > routers at the hub site. > > Chris Chase > AT&T IP Enabled FR Architect

1 0

Need contact for RAIN, AS3215
by Thomas Kernen 11 Sep '00

11 Sep '00

Hi, I'm trying to reach the NOC at RAIN but other than their automated e-mail noc(a)rain.fr I've had no success. Direct phone lines with voice mail doesn't seem to help. Anyone with a contact that deals with routing issues would really help. Thanks, Thomas

1 0

Napster.com moved to 64.124.41.0/24?
by Dave Plonka 11 Sep '00

11 Sep '00

Just FYI, Last week Friday (2000/09/08 ~0300 CDT), I noticed that Napster.com moved all of it's advertised server redirectors and servers to a different network: 64.124.41.0/24 I'm just guessing they're only within the "/24"... the current route NETBLK-ABOVENET is for 64.124.0.0/16. The "old" list that I had been working with for detecting Napster flows was this: 208.49.228.0/24, 208.184.216.0/24, 208.49.239.240/28, 208.178.175.128/29 208.178.163.56/29. Here's a useful source of info if you want to see where Napster and work-alike servers are located, a list of "open" servers by IP address: http://www.napigator.com/list.php Anyway, apart from the questionable practice of using these IPs for access-lists, this information is useful for some of us in the measurement community to write detectors that are less likely to get false hits, such as might happen when counting Napster traffic based solely on TCP port numbers. There's a post regarding the required change for FlowScan here: http://net.doit.wisc.edu/~plonka/list/flowscan/archive/0296.html General FlowScan Napster info is here: http://net.doit.wisc.edu/data/Napster/ Dave -- plonka(a)doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI

1 0

I need an MLM PRO-Partner....,,
by melissa10＠postmaster.co.uk 11 Sep '00

11 Sep '00

1 0

Re: RE
by Masataka Ohta 11 Sep '00

11 Sep '00

Folks; If you want to see an example of variations of regular expressions, see man pages of *grep. Sometimes, '*' matches '*' only. If you want to discuss the definition of regular expressions to be used in research papers on formal language theory, do so outside of NANOG. Thanks in advance. Masataka Ohta

1 0

***New Site : IPTelephonyJobs.com***
by ip telephonyjobs 10 Sep '00

10 Sep '00

Hello, We have launched IPTelephonyJobs.com. The site is dedicated to IP Telephony professionals. The following areas are specifically targeted among others: VoIP (h.323, mgcp, sip, megaco, call agents...) PSTN(ss7, isdn, ain/in,..) Wireless(gprs, cdma, gsm,...) IP Routing/Switching + others Services offered to Job Seekers: - Profile only entries lets you keep your personal information private. - Profile + Resume entries lets the employer have a better understanding of your background. - Control access to your resume on demand. So just drop by our site and fill in your profile. http://www.iptelephonyjobs.com _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

1 0

RE: When IPv6 ... if ever?
by Roeland M.J. Meyer 10 Sep '00

10 Sep '00

> smd(a)clock.org, Sunday, September 10, 2000 6:38 AM wrote: Excellent Post, BTW. > | The bottom-line appears that everyone is waiting for > everyone else to > | twitch first, then the shoot-out starts. However, no one is all that > | interested in twitching. > > Also, nobody is willing to get shot! > > The deployment of IPv6 is going to be EXPENSIVE in terms of real opex > and probably real capex as well, it IS going to be visible on > the bottom > line of every ISP on the planet, eroding whatever margins one has. > | The real question is whom is benefiting from sustaining the current > | situation? > Now, ironically, in the whole IPv6 selection process in the IETF, > there were multiple proposals which paid a considerable amount of > attention to the problems of partial, incremental deployment at > the initial design level. CATNIP in particular was clever, because > it provided not just a new packet format (which is all IPv6 did), but > also a strategy to transition to practically ANY new packet format, > should the initial assumptions about the pervasiveness of IPX and CLNP > be wrong (which they were). > > IPv6's initial assumptions are WRONG (we will die from > routing dynamicism I tend to agree here that routing is one of our largest bugga-boos. What we have is held together with spit, baling-wire, and liberal amounts of the "racer's edge" (duct-tape). With CERF.NET bouncing all over the place, for the past three weeks, maybe I've become hyper-sensitive to those issues. But, it appears to me that the entire BGP system is a very brittle patch. It is for this reason that I recommend ABOVE.NET to all my globally visible portal/ASP/B2B clients. However, this doesn't relieve the problem of the end-user being outside the ABOVE.NET system and having to live with cold-potato routing, for uploading files to the site. We have too few public peering-points and they are under-sized (what happened to the regional NAP idea?). > Who will take the chance of a huge investment in managing > IPv6 deployment, when it is not a given that IPv6 really > will be the header networks will use after IPv4? > We're talking about stranded assets being > the only thing one gets for the money... What you are saying is that going to IPv6 is a one-way function? I've actually looked at some of this. At the risk of ridicule, may I mention Flemming's IPv8? It nested IPv4 inside the packet, as a sub-set, and actually planned for co-existance and inter-operability with IPv4. It also answered a LOT of routing issues. Regardless of specific implementation, that seems like a more prudent approach. Does anyone know why such an approach-policy wasn't followed by the IPv6 team? Yes, I agree that CATNIP was also clever. With a little work, it "could have been a contender" (Brando<g>). The choice of IPv4 and IPv6 shouldn't be an XOR function and the point remains that transition was not a consideration of the IPv6 design (this is obvious). In most commercial shops, such an approach would not have been accepted/tolerated. Let alone, win any sort of design contest, as did IPv6.

1 0

Re: When IPv6 ... if ever?
by smd＠clock.org 10 Sep '00

10 Sep '00

The solution is in a complete separation of "what" from "where", and using the "what" part to identify conversations INDEPENDENTLY from the topology across which they are desired/occurring. There are many ways to get there. More on that after dinner... Sean.

1 0