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..
I *think* the same idea was floated to Cisco at the same time; their PVLAN was offered in beta not long after Extreme moved super/sub-VLANs into public release.
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 said abomination, it didn't quite work as well as promised. In fact I was just trying to decide which was more painful, taking over a hosting network with 90% of their hosts in one VLAN (VLAN2, they asked for free advice when they first started to attempt to migrate), or supporting super/sub-VLANs in an operational environment. Customers hated both, but at least they saw better performance once the hosting network was broken up per-customer VLANs.
Indeed, 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 stuff was to be expected, like seeing broadcast traffic in all subs under a super-VLAN.
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.
Residential customers don't mind, and probably would never notice. Large corporate clients who are putting important servers in a hosting environment get rather concerned when you start seeing traffic (including cleartext login info) from their neighbors on their interfaces.
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 enterprise hosting division on an RBOC was probably not the best place to deploy it.
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 well, but based on my experience in that segment, there is a much bigger return on investment in paying a couple of engineers well enough to manage your VLAN allocations correctly and use existing (generally secondary market) hardware and tools.
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