Juniper's artificial feature blocking (was legacy /8)

Fri Apr 9 00:44:32 UTC 2010

On 04 Apr 2010 16:07, James Hess wrote:
> Using a 'key' is slightly less of a network operator nightmare than
> having 100 featuresets, and thousands of mystery meat images for the
> same software version. At least you don't need to go buy a new
> software image, and do a full upgrade procedure to gain feature access.
>
> Applying a key seems less risky and less likely that downtime is
> needed, when you decide that you now need this feature.

Indeed.  Just as importantly, developing a single image with
license-enabled features saves both vendors and customers a lot of time
on QA, acceptance testing, etc.  Since you're always running the same
image, you only need to test it once, with all features enabled, to be
sure that everything works; if there are different images for different
feature sets, you have to run a full test suite on each image.  That's a
lot of extra work for no real benefit.  Having to switch from one image
to another to enable a particular feature also entails additional risk,
downtime, etc. that simply loading a license key does not.

> Even CPU manufacturers are noted for artificially restricting features
> in software (such as VT or hyper-threading, even artificially
> disabling cores). Not all buyers of L3 switches need or want to payfor
> that, and there is more $$$ to be made from those that do.
>
> The manufacturer can either segment their market by not offering
> OSPFv3 on the device, release a new higher-end hardware model for V3
> support at 10x the cost, or offer an add-on license, as an incremental
> upgrade to a larger number of users (including the installed base).

Indeed.  Vendors face a lot of price pressure, so being able to disable
non-mandatory features to meet low-end customers' price demands is a
major competitive advantage.  However, they still need revenue to
support the development that the handful of high-end customers demand
for "new" or "optional" features, and charging for licenses to enable
those features seems to be the best way that anyone has figured out to
do that.

Heck, I work with one vendor that requires separate licenses for
virtually every checkbox in their GUI; turning up one customer port may
involve purchasing dozens of new licenses.  The customers of their
product don't like it, sure, but suggest that they pay the full cost of
enabling all options on all ports and they flip out.  Licensed features
enable customers to purchase only what they need, not what some
marketing puke decides they need (or some one-size-must-fit-all pricing
scheme, which rarely works well).

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100408/20e4cc10/attachment.bin>