North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Interesting new spam technique - getting a lot more popular.
On Jun 15, 2006, at 7:06 AM, Kristal, Jeremiah wrote:
I don't think it was Extreme that filed it, or at least they didn't write it. It was the good folks at Qwest engineering who came up with the idea, which was implemented (for some low value of implemented) by Extreme. The authors had moved on by the time the RFC was published, but they were certainly Qwesties (and probably CSN before that).
Nope, not at all CSN..
Yep, pointer here, for folks interested in the current state of that work within the IETF: http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-05.txt
Unfortunately for those of us who had to actually implement saidIndeed, as there's a discernible gap there from concept to implementation,
implementation to network engineering, beta/EFT, and from network
engineering & beta/EFT to deployment & operationalizing any such
technology. If you disregard any of these phases, for whatever reason,
it'll likely to come back to bite you.
Customers hated it because of some very serious operational flaws. Some
As with any new technology, some amount of education is often required when change occurs. In this case, a reasonable response would be to first ask if anything was broken as a result, and if not, then to explain the benefits such a service model provides from a billing, Internet address conservation and security perspective. Customers hating something simply because they liked and are no longer seeing broadcast traffic seems a bit intractable to me. This is the perfect example where a small amount of education can go a long way. Now, if something is broken, OTOH, that's different.
Some stuff was truly flawed, like having some small percentage of packets leaking across sub-VLANs.
Indeed, and this is clearly an implementation bug, and potentially, a security vulnerability, if an attacker could determine how to elicit such a behavior.
Trying to convince your vendor that this (and other) flaw exists when you're the only client using it in production, and you're pushing several orders of magnitude more traffic than their labs, can be slightly frustrating.
Again, this is why it's important to be able to clearly articulate such a problem, and why phases 2 & 3 above are so critical, and why each new application of such a mechanism requires revisiting the entire process.
I personally felt that this was a solution in search of a problem. The
IIRC, the "enterprise hosting solution of an RBOC" wasn't the intended initial application, though I do suspect such a solution would provide considerable advantages in a deployment such as that - again, assuming it was engineered and operationalized appropriately.
The current low-end hosting environment is a problem that fits pretty
While I'm not sure about any of the deployment details beyond the initial problem set, which falls pretty much squarely within your "that fits pretty well" category, I would be interested in hearing what your solution to such a problem is? Certainly, some amount of engineering needs to be applied, and customers that justify their own IP subnets should be handled as such, but in this day and age, I'd hope that most folks separate customers into different Link layer broadcast domains, and employ some bit of cognition WRT Internet address space conversation. -danny