Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Sun, 4 Jul 2004, Bill Woodcock wrote: > Go back and think about the purpose of an exchange: it's an economic > optimization over transit. It's the value-add that lets someone who buys > transit sell a service that's of greater value yet lesser cost than what > they buy. Now, what's an exchange that costs more money? Less effective. > > So charging more money is just a way to make an exchange less effective, > not more effective. > > Some people who don't bother to run the numbers think that reliability is > a justification for charging money at an exchange. I'd encourage them to > run the numbers. An exchange which costs twice as much money needs to be > twice as reliable to be equally effective. Ask yourself how many > exchanges there are that drop more than half the bits on the floor, > before you think of charging twice as much money. > > In other words, if it's not broke, don't fix it. I'm going to quibble with Bill a bit on this. I'm going to attempt to do so carefully, both because I work for him, and because this is an area he knows much better than I do. ;) Peering is often said to help a network (and thus add value) in two ways, by increasing performance and by reducing costs. Performance is said to increase because other networks are brought closer. Costs are said to go down because a network starts getting connectivity for free that it would otherwise be paying for. In well connected urban areas of the US, for all but the biggest networks, it's no longer clear that either of these arguments are valid. The performance arguments are probably more controversial. The arguments are that shortening the path between two networks increases performance, and that removing an extra network in the middle increases reliability. The first argument holds relatively little water, since it's in many cases only the AS Path (not really relevant for packet forwarding performance) that gets shortened, rather than the number of routers or even the number of fiber miles. If traffic goes from network A, to network A's router at an exchange point, to network C, that shouldn't be different performance-wise from the traffic going from network A, to Network B's router at the exchange point, to Network C. Assuming none of the three networks are underprovisioning, the ownership of the router in the middle shouldn't make much difference. The reliability argument is probably more valid -- one less network means one less set of engineers to screw something up, but the big transit networks tend to be pretty reliable these days, and buying transit from two of them should be quite safe. The pricing issues are simpler. There's a cost to transit (which is, to some degree, paying some other network to do your peering for you), and there's a cost to peering. Without a clear qualitative difference between the two, peering needs to be cheaper to make much sense. The costs of transit involve not just what gets paid to the transit provider for the IP transit, but also the circuit to the transit provider, the router interface connecting to the transit provider, engineering time to maintain the connection and deal with the transit provider if they have issues, and so forth. Costs of peering include not just the cost of the exchange port, but also the circuit to get to the exchange switch, sometimes colo in the exchange facility, engineering time to deal with the connection and deal with the switch operator if there are issues, and time spent dealing with each individual peer, both in convincing them to turn the session up, and dealing with problems affecting the session. Even if the port on the exchange switch were free, there would be some scenarios in which peering would not be cheaper than transit. The situation changes considerably in less developed areas. The transit costs tend to be a lot higher (largely due to increased long-haul circuit costs), and there's a significant performance cost to having your traffic go hundreds or thousands of miles to get across town. The argument against free exchanges is, I think, more of an argument in favor of full-service facilities, and the savings they provide in terms of operational engineering time. If there's a problem at 3 am at PAIX, Equinix, or NOTA (to pick three well-known North American commercial exchange operators), it's easy to pick up the phone and get it resolved. When dealing with volunteers, or with an organization that doesn't have the budget for a 24/7 paid staff, there's at least a perception that it may be hard to find somebody who will make fixing somebody else's problem their top priority. Again, it becomes a matter of plugging that cost into the cost comparison, and figuring out whether it costs more to peer with or without that level of service. > > I would bet that there is more than enough business available to > > cover the costs of intelligent spending. > > While I won't categorically dub that an oxymoron, I'd say that the > pos
Re: concern over public peering points
* [EMAIL PROTECTED] (Steve Gibbard) [Mon 05 Jul 2004, 10:19 CEST]: [..] > The performance arguments are probably more controversial. The > arguments are that shortening the path between two networks increases > performance, and that removing an extra network in the middle increases > reliability. The first argument holds relatively little water, since > it's in many cases only the AS Path (not really relevant for packet > forwarding performance) that gets shortened, rather than the number of > routers or even the number of fiber miles. "Not really"? Not always, perhaps. But it's more the rule than the exception, I think. > If traffic goes from network A, to network A's router at an exchange > point, to network C, that shouldn't be different performance-wise from > the traffic going from network A, to Network B's router at the exchange > point, to Network C. Except that, due to "peering games" some companies tend to engage in, the exchange point where A and B exchange traffic may well be in a different country from where A, C and their nearest exchange point is. > Assuming none of the three networks are underprovisioning, the > ownership of the router in the middle shouldn't make much difference. > The reliability argument is probably more valid -- one less network > means one less set of engineers to screw something up, but the big > transit networks tend to be pretty reliable these days, and buying > transit from two of them should be quite safe. The correct phrasing is indeed "one less network" and not "one less router." It's rarely one device in my experience. -- Niels.
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Sat, Jul 03, 2004 at 09:24:17PM +0200, Mikael Abrahamsson wrote: > On Sat, 3 Jul 2004, Stephen J. Wilcox wrote: [snip] > IXes are not for "top carriers" ^^^ Like the economy, perhaps this is different in .se. But this is NAnog to which you are sending the message, and the above statement is incorrect. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Sipura VoIP phone adapters and DoS against name servers
Last night we configured our equipment to reject recursive DNS lookups from non-customers. This morning, soon after normal office hours began, we started receiving around 2500 DNS lookups per second more than normal to our recursive name servers. After analyzing the DNS lookups, we found that all of the extra traffic was generated from customers of a local VoIP provider which uses Sipura (SPA-2000) phone adapters. It seems that when these adapters don't receive answers to their DNS queries, they will retransmit the query once per second (until they receive an answer). Multiply by number of adapters, and you have the recipe for a nice DoS. Shades of Netgear NTP DoS (http://www.cs.wisc.edu/~plonka/netgear-sntp/) - don't vendors ever learn? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Sipura VoIP phone adapters and DoS against name servers
> After analyzing the DNS lookups, we found that all of the extra traffic > was generated from customers of a local VoIP provider which uses Sipura > (SPA-2000) phone adapters. i just cross-posted your msg to an internal sipura beta testers' list randy
Re: Sipura VoIP phone adapters and DoS against name servers
Get in contact with manufacturing vender for a fix, and then tell us what they did or what they intend to do to remedy the problem. -Henry --- [EMAIL PROTECTED] wrote: > > Last night we configured our equipment to reject > recursive DNS lookups > from non-customers. This morning, soon after normal > office hours began, > we started receiving around 2500 DNS lookups per > second more than normal > to our recursive name servers. > > After analyzing the DNS lookups, we found that all > of the extra traffic > was generated from customers of a local VoIP > provider which uses Sipura > (SPA-2000) phone adapters. It seems that when these > adapters don't > receive answers to their DNS queries, they will > retransmit the query > once per second (until they receive an answer). > Multiply by number of > adapters, and you have the recipe for a nice DoS. > > Shades of Netgear NTP DoS > (http://www.cs.wisc.edu/~plonka/netgear-sntp/) > - don't vendors ever learn? > > Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] >
Re: Sipura VoIP phone adapters and DoS against name servers
> Get in contact with manufacturing vender for a fix, > and then tell us what they did or what they intend > to do to remedy the problem. We have already suggested this to the local VoIP provider. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Sipura VoIP phone adapters and DoS against name servers
\Get in contact with manufacturing vender for a fix, and then tell us what they did or what they intend to do to remedy the problem. We have already suggested this to the local VoIP provider. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] I guess the real question is why was the local VoIP provider giving the phones your DNS IP? Should they have been using their own DNS server? -matt
Re: Sipura VoIP phone adapters and DoS against name servers
> I guess the real question is why was the local VoIP provider giving the > phones your DNS IP? Should they have been using their own DNS server? As to why, we don't know. They *will* be using their own DNS servers soon, however :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On 7/5/04 1:18 AM, "Steve Gibbard" <[EMAIL PROTECTED]> wrote: > > > The performance arguments are probably more controversial. The arguments > are that shortening the path between two networks increases performance, > and that removing an extra network in the middle increases reliability. > The first argument holds relatively little water, since it's in many cases > only the AS Path (not really relevant for packet forwarding performance) > that gets shortened, rather than the number of routers or even the number > of fiber miles. If traffic goes from network A, to network A's router at > an exchange point, to network C, that shouldn't be different > performance-wise from the traffic going from network A, to Network B's > router at the exchange point, to Network C. Assuming none of the three > networks are underprovisioning, the ownership of the router in the middle > shouldn't make much difference. The reliability argument is probably more > valid -- one less network means one less set of engineers to screw > something up, but the big transit networks tend to be pretty reliable > these days, and buying transit from two of them should be quite safe. > I believe that peering does lead to a more robust network and somewhat better performance. Being heavily peered means that when one of my transit providers suffers a network 'event', I am less affected. Also, just because I'm sitting at a network exchange point (and take my transit there) doesn't mean that's where my transit networks peer. Quite often, I see traffic going to Stockton or Sacramento through one of my transit connections to be delivered to a router just a few cages away at PAIX. > The pricing issues are simpler. There's a cost to transit (which is, to > some degree, paying some other network to do your peering for you), and > there's a cost to peering. Without a clear qualitative difference between > the two, peering needs to be cheaper to make much sense. The costs of > transit involve not just what gets paid to the transit provider for the IP > transit, but also the circuit to the transit provider, the router > interface connecting to the transit provider, engineering time to maintain > the connection and deal with the transit provider if they have issues, and > so forth. Costs of peering include not just the cost of the exchange > port, but also the circuit to get to the exchange switch, sometimes colo > in the exchange facility, engineering time to deal with the connection and > deal with the switch operator if there are issues, and time spent dealing > with each individual peer, both in convincing them to turn the session up, > and dealing with problems affecting the session. Even if the port on the > exchange switch were free, there would be some scenarios in which peering > would not be cheaper than transit. > When we established our connection at PAIX, peering bandwidth was a factor of 20 cheaper than transit. Now they're at parity. Unfortunately, some *IX operators haven't seen fit to become more competitive on pricing to keep peering more economical than average transit pricing. $5000 for an ethernet switch port? It makes me long for the days of throwing ethernet cables over the ceiling to informally peer with other networks in a building. In the 'bad' old days of public exchanges (even the ad hoc ones), most of the problems were with the design and traffic capacity of the equipment itself (not a real problem now), not with actual 'operations'.
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Mon, Jul 05, 2004 at 10:55:42AM -0700, joe mcguckin wrote: > > $5000 for an ethernet switch port? It makes me long for the days of throwing > ethernet cables over the ceiling to informally peer with other networks in a Throwing ethernet cables over the ceiling does not scale. /vijay
Announcing a /19 from a /16
Hi- I'm working on a project within a large corporation and asked their network folks about getting a /19 from one of their /16s. I wanted it to avoid NAT and any possible overlapping from using RFC1918 addresses. This project gets connected to the internet at different times throughout the year at different locations through different ISPs. I would announce the /19 for a short period of time, maybe a month or so. The response I got back was that this was impossible since ISPs require an announcement of the /16 the /19 would come from. I have done work with ISPs before (and have read the NANOG list for many years) but haven't heard of such a requirement nor can I find any standards that indicate the same thing. Does anyone have requirements of a /19 announcement requires the /16 to be there as well? The company has plenty of /16s that it uses internally that are not being announced on the Internet at all. Thanks- -Eric
RE: Announcing a /19 from a /16
> -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > la part de Eric Pylko > Envoyé : lundi 5 juillet 2004 22:02 > À : [EMAIL PROTECTED] > Objet : Announcing a /19 from a /16 > > > Hi- > > I'm working on a project within a large corporation and asked > their network folks about getting a /19 from one of their > /16s. I wanted it to avoid NAT and any possible overlapping > from using RFC1918 addresses. This project gets connected to > the internet at different times throughout the year at > different locations through different ISPs. I would announce > the /19 for a short period of time, maybe a month or so. > > The response I got back was that this was impossible since > ISPs require an announcement of the /16 the /19 would come > from. Maybe one of the (fairly rare, from what I see) actors that ingress filter (or takes into account those small few that does) by allocation? (What prefixes are yopu talking about?) mh > I have done work with ISPs before (and have read the > NANOG list for many years) but haven't heard of such a > requirement nor can I find any standards that indicate the same thing. > > Does anyone have requirements of a /19 announcement requires > the /16 to be there as well? The company has plenty of /16s > that it uses internally that are not being announced on the > Internet at all. > > Thanks- > > -Eric > > >
RE: Announcing a /19 from a /16
> > > > Hi- > > > > I'm working on a project within a large corporation and asked > > their network folks about getting a /19 from one of their > > /16s. I wanted it to avoid NAT and any possible overlapping > > from using RFC1918 addresses. This project gets connected to > > the internet at different times throughout the year at > > different locations through different ISPs. I would announce > > the /19 for a short period of time, maybe a month or so. > > > > The response I got back was that this was impossible since > > ISPs require an announcement of the /16 the /19 would come > > from. > > Maybe one of the (fairly rare, from what I see) actors that > ingress filter > (or takes into account those small few that does) by strict > allocation border >? (What > prefixes are yopu talking about?) > > mh > ;) mh > > > I have done work with ISPs before (and have read the > > NANOG list for many years) but haven't heard of such a > > requirement nor can I find any standards that indicate the > same thing. > > > > Does anyone have requirements of a /19 announcement requires > > the /16 to be there as well? The company has plenty of /16s > > that it uses internally that are not being announced on the > > Internet at all. > > > > Thanks- > > > > -Eric > > > > > > >
Re: Announcing a /19 from a /16
> The response I got back was that this was impossible since ISPs require an > announcement of the /16 the /19 would come from. I have done work with ISPs > before (and have read the NANOG list for many years) but haven't heard of > such a requirement nor can I find any standards that indicate the same > thing. > > Does anyone have requirements of a /19 announcement requires the /16 to be > there as well? The company has plenty of /16s that it uses internally that > are not being announced on the Internet at all. The /19 is big enough to not get filtered by the majority. I don't know of any specific "rules" or "do's and don'ts" that prevents you from announcing such a space as long as you have a) permission from the /16 administrator (which you claim to have), b) non-private-AS number announcing it and perhaps c) register it in a popular IRR database (i.e. ALTDB, RADB). BGP advertisement really isn't a rocket science. What you announce and what the majority accepts is what the internet sees. -J > > Thanks- > > -Eric > -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: concern over public peering points
On Mon, 5 Jul 2004, Niels Bakker wrote: > > The correct phrasing is indeed "one less network" and not "one less > router." It's rarely one device in my experience. I'm not sure the number of routers matters much anymore, with more and more MPLS deployment you can't be sure that the path from A to B goes directly from A to B, it might go through F, G, H, I before B :( It's probably more relevant the path RTT isn't it?
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Jul 5, 2004, at 2:02 PM, vijay gill wrote: On Mon, Jul 05, 2004 at 10:55:42AM -0700, joe mcguckin wrote: $5000 for an ethernet switch port? It makes me long for the days of throwing ethernet cables over the ceiling to informally peer with other networks in a Throwing ethernet cables over the ceiling does not scale. Sure it does. The question is: "How far does it scale?" Nothing scales to infinity, and very, very few things do not scale past the degenerate case of 1. If you s/ethernet cables/optical fibers/, it scales even further. Especially since this is not being used for all his traffic. Not everyone needs a terabit of exit capacity. Guaranteeing everything you do is close to infinitely scalable is a Bad Idea for people who do not. And even if you do need a terabit of exit capacity, nothing wrong with the occasional OC768 routed through the ceiling. :) -- TTFN, patrick
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Jul 5, 2004, at 5:00 PM, Patrick W Gilmore wrote: On Jul 5, 2004, at 2:02 PM, vijay gill wrote: Throwing ethernet cables over the ceiling does not scale. Sure it does. The question is: "How far does it scale?" Nothing scales to infinity, and very, very few things do not scale past the degenerate case of 1. You need to take into account all of the aspects of the complexity that you introduce when you throw that fiber over the wall tho. While the fiber installation is simple enough, you have now created other problems: who will maintain it? Who knows it is there? Who knows that it is there in the other organization? Who needs to know about it within your own organization? How is tracked? Who does the NOC call when it goes bad? While it may be a single exception to your network architecture, if it is an exception that 100 people need to know about, then I'd argue that it doesn't scale. The fun and games that we had in Ye Olden Days o' the Internet simply are not workable when you are coordinating with hundreds of other employees. Put another way, scalability can never overlook the human element. Tony
Re: concern over public peering points [WAS: Peering point speed publicly available?]
[EMAIL PROTECTED] (vijay gill) writes: > Throwing ethernet cables over the ceiling does not scale. i think it's important to distinguish between "things aol and uunet don't think are good for aol and uunet" and "things that aren't good for anybody." what i found through my PAIX experience is that the second tier is really quite deep and broad, and that the first tier doesn't ignore them like their spokesmodels claim they do. what i found in helping to hone the ssni approach is that while public peering "ethernet style" is dead, vni/pni peering is alive and well. anyone who does not agree is free to behave that way. but it's not useful to try to dissuade cooperating adults from peering any way they want to. the interesting evolutionary aspect to this is that vni/pni peering starting with atm and moving to pni doesn't work at all, because atm by and large has a high cost per bit at the interface, and a low top end, and usually doesn't mandate co-location. but vni/pni peering over 802.1Q usually does succeed, because of the low cost per bit at the interface, the obscenely high top end, and the greater likelihood that the vni parties are co-located and so can switch to pni when the traffic volume warrants it. i've been told that if i ran a tier-1 i would lose my love for the vni/pni approach, which i think scales quite nicely even when it involves an ethernet cable through the occasional ceiling. perhaps i'll eat these words when and if that promotion comes through. meanwhile, disintermediation is still my favorite word in the internet dictionary. i like it when one's competitors are free to do business with each other, it leads to more and better innovation. -- Paul Vixie
mid-mount server rails
Hi Nanogers If I have a two post relay rack, could you advise on any generic rails that could be used to 'mid-mount' a 1-4U server on that two port rack? Thank you. Regards, Christopher J. Wolff VP CIO Broadband Laboratories, Inc. http://www.bblabs.com
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Jul 5, 2004, at 8:35 PM, Tony Li wrote: On Jul 5, 2004, at 5:00 PM, Patrick W Gilmore wrote: On Jul 5, 2004, at 2:02 PM, vijay gill wrote: Throwing ethernet cables over the ceiling does not scale. Sure it does. The question is: "How far does it scale?" Nothing scales to infinity, and very, very few things do not scale past the degenerate case of 1. You need to take into account all of the aspects of the complexity that you introduce when you throw that fiber over the wall tho. While the fiber installation is simple enough, you have now created other problems: who will maintain it? Who knows it is there? Who knows that it is there in the other organization? Who needs to know about it within your own organization? How is tracked? Who does the NOC call when it goes bad? While it may be a single exception to your network architecture, if it is an exception that 100 people need to know about, then I'd argue that it doesn't scale. The fun and games that we had in Ye Olden Days o' the Internet simply are not workable when you are coordinating with hundreds of other employees. Put another way, scalability can never overlook the human element. I'm wondering why you think that the fiber over the ceiling tile is somehow less tracked, maintained, monitored, documented, etc., than any other fiber in the network? Put another way: Just because I am not paying someone 1000s of $$ a month to watch it for me does not mean the human element is ignored. In fact, I have seen many cases where people lost track of interconnects where they were paying lots of money for someone else to watch them. So maybe the strange ones are better =) If you do not want to throw cables over the ceiling in your network, then by all means do not. I have repeated many times here and elsewhere: Your network, your decision. And for those of us who can track & maintain zero-dollar interconnects, please do not begrudge us the cost savings. -- TTFN, patrick
Re: concern over public peering points [WAS: Peering point speed publicly available?]
On Tue, Jul 06, 2004 at 01:43:14AM +, Paul Vixie wrote: > > [EMAIL PROTECTED] (vijay gill) writes: > > Throwing ethernet cables over the ceiling does not scale. > > i think it's important to distinguish between "things aol and uunet don't > think are good for aol and uunet" and "things that aren't good for anybody." > > what i found through my PAIX experience is that the second tier is really > quite deep and broad, and that the first tier doesn't ignore them like their > spokesmodels claim they do. Paul, I think you took a left at the pass and went down the wrong road here. I am not saying ethernet doesn't scale or even vni/pni doesn't scale, but the mentality embodied in the approach "throw it over the wall" doesn't bode well if you are to scale. > not agree is free to behave that way. but it's not useful to try to dissuade > cooperating adults from peering any way they want to. > > i've been told that if i ran a tier-1 i would lose my love for the vni/pni > approach, which i think scales quite nicely even when it involves an ethernet > cable through the occasional ceiling. perhaps i'll eat these words when and > if that promotion comes through. meanwhile, disintermediation is still my > favorite word in the internet dictionary. i like it when one's competitors As we have seen before in previous lives, and I'm pretty sure stephen stuart will step in, normalizing "throw the ethernet over the wall" school of design just leads to an incredible amount of pain when trying to operate, run and actually document what you've got. I thought it was illustrative to take a look at some of the other messages in this thread. People rushing in to argue the scale comment when the actual heart of the matter was something else entirely, which apparently only Tony managed to get. In any case, I am going to pull a randy here and strongly encourage my competitors to deploy this "ethernet over ceiling tile" engineering methodology. /vijay
Re: concern over public peering points [WAS: Peering point speed publicly available?]
Kind of summarizes why we are still heavy on the "best effort" side of the equation. -M Regards, -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 http://www.verisign.com/ -Original Message- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: Paul Vixie <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Sent: Mon Jul 05 21:32:14 2004 Subject: Re: concern over public peering points [WAS: Peering point speed publicly available?] On Tue, Jul 06, 2004 at 01:43:14AM +, Paul Vixie wrote: > > [EMAIL PROTECTED] (vijay gill) writes: > > Throwing ethernet cables over the ceiling does not scale. > > i think it's important to distinguish between "things aol and uunet don't > think are good for aol and uunet" and "things that aren't good for anybody." > > what i found through my PAIX experience is that the second tier is really > quite deep and broad, and that the first tier doesn't ignore them like their > spokesmodels claim they do. Paul, I think you took a left at the pass and went down the wrong road here. I am not saying ethernet doesn't scale or even vni/pni doesn't scale, but the mentality embodied in the approach "throw it over the wall" doesn't bode well if you are to scale. > not agree is free to behave that way. but it's not useful to try to dissuade > cooperating adults from peering any way they want to. > > i've been told that if i ran a tier-1 i would lose my love for the vni/pni > approach, which i think scales quite nicely even when it involves an ethernet > cable through the occasional ceiling. perhaps i'll eat these words when and > if that promotion comes through. meanwhile, disintermediation is still my > favorite word in the internet dictionary. i like it when one's competitors As we have seen before in previous lives, and I'm pretty sure stephen stuart will step in, normalizing "throw the ethernet over the wall" school of design just leads to an incredible amount of pain when trying to operate, run and actually document what you've got. I thought it was illustrative to take a look at some of the other messages in this thread. People rushing in to argue the scale comment when the actual heart of the matter was something else entirely, which apparently only Tony managed to get. In any case, I am going to pull a randy here and strongly encourage my competitors to deploy this "ethernet over ceiling tile" engineering methodology. /vijay
Re: concern over public peering points [WAS: Peering point speed publicly available?]
> > i've been told that if i ran a tier-1 i would lose my love for the > > vni/pni approach, which i think scales quite nicely even when it > > involves an ethernet cable through the occasional ceiling. perhaps > > i'll eat these words when and if that promotion comes through. > > meanwhile, disintermediation is still my favorite word in the > > internet dictionary. i like it when one's competitors > > As we have seen before in previous lives, and I'm pretty sure stephen > stuart will step in, normalizing "throw the ethernet over the wall" > school of design just leads to an incredible amount of pain when trying > to operate, run and actually document what you've got. that only happens if you grow, though. in other words it's a nice problem to have. i guess i'll defer to the people who have started from scratch and gotten all the way up to having the problem you describe. i met a lot of them though my PAIX experience. you should defer to them on this point also. > I thought it was illustrative to take a look at some of the other > messages in this thread. People rushing in to argue the scale comment > when the actual heart of the matter was something else entirely, > which apparently only Tony managed to get. i understood and agreed with tony's point. and during my mfn experience i was quite supportive of normalization, and was quite damning in my curses of what had been doing done in the early/growth period "before my time." but that doesn't mean that the occasional ethernet cable over the ceiling isn't the right business decision for people who have done what many here have not done, which is to say, started from scratch. > In any case, I am going to pull a randy here and strongly encourage my > competitors to deploy this "ethernet over ceiling tile" engineering > methodology. i would think that was puerile and shallow no matter who actually said it.
Proxy scanning for spam
Hello, If I have a network segment connected to a BGP peer, is there a way that I can hang a box of some kind off of that segment that will sniff out and block malicious/spam email before it hits the customers? Regards, Christopher J. Wolff VP CIO Broadband Laboratories, Inc. http://www.bblabs.com
Re: Proxy scanning for spam
On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > > Hello, > > If I have a network segment connected to a BGP peer, is there a way that I > can hang a box of some kind off of that segment that will sniff out and > block malicious/spam email before it hits the customers? Do you mean a host that can have all tcp/25 routed to it, transparently pick-up/scan/re-deliver emails for your customers? or did you mean something you could add to your customer relay boxes? (or your MX hosts that customers use) Or thirdly, something to protect the internet from your users?
RE: Proxy scanning for spam
Christopher, I meant option #1. -Original Message- From: Christopher L. Morrow [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 10:36 PM To: Christopher J. Wolff Cc: [EMAIL PROTECTED] Subject: Re: Proxy scanning for spam On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > > Hello, > > If I have a network segment connected to a BGP peer, is there a way that I > can hang a box of some kind off of that segment that will sniff out and > block malicious/spam email before it hits the customers? Do you mean a host that can have all tcp/25 routed to it, transparently pick-up/scan/re-deliver emails for your customers? or did you mean something you could add to your customer relay boxes? (or your MX hosts that customers use) Or thirdly, something to protect the internet from your users?
RE: Proxy scanning for spam
On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > Christopher, > > I meant option #1. a quickie google shows: http://assp.sourceforge.net/ which looks promising... additionally: http://www.ironport.com/ Though, why not just use brightmail/messagelabs if it's to MX's you can control? Offer this as a 'service' to your customers for $X/seat/month? > On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > > > > > Hello, > > > > If I have a network segment connected to a BGP peer, is there a way that I > > can hang a box of some kind off of that segment that will sniff out and > > block malicious/spam email before it hits the customers? > > Do you mean a host that can have all tcp/25 routed to it, transparently > pick-up/scan/re-deliver emails for your customers? or did you mean > something you could add to your customer relay boxes? (or your MX hosts > that customers use) Or thirdly, something to protect the internet from > your users? >
RE: Proxy scanning for spam
These are both interesting options. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Monday, July 05, 2004 11:02 PM To: Christopher J. Wolff Cc: [EMAIL PROTECTED] Subject: RE: Proxy scanning for spam On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > Christopher, > > I meant option #1. a quickie google shows: http://assp.sourceforge.net/ which looks promising... additionally: http://www.ironport.com/ Though, why not just use brightmail/messagelabs if it's to MX's you can control? Offer this as a 'service' to your customers for $X/seat/month? > On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > > > > > Hello, > > > > If I have a network segment connected to a BGP peer, is there a way that I > > can hang a box of some kind off of that segment that will sniff out and > > block malicious/spam email before it hits the customers? > > Do you mean a host that can have all tcp/25 routed to it, transparently > pick-up/scan/re-deliver emails for your customers? or did you mean > something you could add to your customer relay boxes? (or your MX hosts > that customers use) Or thirdly, something to protect the internet from > your users? >
China deploys Internet protocol version 9 network
Hello, Have you heard of IPv9? or it was IPv8? China's Internet technology Ipv9,which being compatible with IPv4 and IPv6,has been formally adapted and popularized into the civil and commercial sector. http://news.xinhuanet.com/english/2004-07/05/content_1572719.htm Thanks, -J __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
Re: concern over public peering points [WAS: Peering point speed publicly available?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-07-03, at 18.10, Mikael Abrahamsson wrote: > It's when the exchange is being run by a separate entity that needs a > marketing department, a well-paid staff of managers, technicians etc > that > price really goes up. All this to basically manage a simple ethernet > switch that needs some patching a couple of times a month at maximum. For quite some months I have spent time thinking on this particular issue. And one thing have struck me with the discussions of staffing levels. It is always true that if your day job get's payed by some other revenue generating business, running a IX with that staff should be easy. That is cross-subsidation and there is no need for recovering costs for the IXP. At the same time, there are a number of roles you can only take that far in that way. One of the most obvious ones is growing the membership number. Now, it's not always the case that an increased membership number benefits the members, but I am willing to claim that it is in most cases. Reason is simply that the cost of running the exchange is not directly proportional to the number of members. So more members means less cost per member for a non-for-profit IX. Also, more members should increase the value for the other members as they have the possibility to "peer-away" more traffic. Now, I am willing to claim that you can only get new members "by reputation" up to a certain point. After that you will need to start to actively go out and find them, and deal with them. This will cost you money. I have with great interest followed how non-for-profit IXPs in Europe have started employing "marketing" staff. I have no idea if this pays off for them, but I suspect it does. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQOpDiaarNKXTPFCVEQJDGwCfXqZw3+7YFuDPNiuvUONfVYi+mYkAnj6h Ud8VxItMH8qNXqrObTY6inSK =pr29 -END PGP SIGNATURE-
Re: China deploys Internet protocol version 9 network
On Mon, Jul 05, 2004 at 11:15:06PM -0700, John Obi wrote: > > Hello, > > Have you heard of IPv9? or it was IPv8? > > China's Internet technology Ipv9,which being > compatible with IPv4 and IPv6,has been formally > adapted and popularized into the civil and commercial > sector. > > http://news.xinhuanet.com/english/2004-07/05/content_1572719.htm > > Thanks, > > -J IPv9 is the TUBA protocol - RFC 10xx - from the last century. :) This is a modification that uses the 10digit telephone#. Tony Hain refered to this as "e164-like". Others have less complementary things to say. --bill
Re: China deploys Internet protocol version 9 network
maybe it's IPv69!
Re: China deploys Internet protocol version 9 network
On Mon, 5 Jul 2004, Randy Bush wrote: > > maybe it's IPv69! but will their firewall protect us from it?
