[c-nsp] Licensing question for ASR9000

[Saku Ytti]

On Fri, 24 Oct 2025 at 09:38, Mark Tinka via cisco-nsp
<cisco-nsp at puck.nether.net> wrote:

> Unfortunately, Cisco are not alone. Juniper are also quickly going down
> this path, especially with their newer MX line.
>
> I have sensed a linear relationship between this strategy and the
> growing silence on c-nsp and j-nsp.
>
> Operators are losing interest.

In principle I am not against licensing. I do sympathise to a degree
with vendor's struggling with the business case of providing routers
for SP customers.

In an ideal world license would help to put cost where demand is, as
we constantly do see quite stupid features arriving that some customer
with big RFP pushed, which adds fragility, complexity and cost to
everyone. But of course in the world we actually live in, licenses are
motivated by need to increase revenue, not to distribute it where the
use is.

Investors love to hear the YRC/MRC story, instead of one off purchase
story, and it already feels like we are leasing routers not buying,
considering support costs more than the devices over the lifetime. And
many of us only pay the support, because software is bad, creating
perverse incentive for software quality.

Having gotten that rant out of the way. The situation isn't too dire,
both Cisco and Juniper allow you to use licenses in such a way that
the device doesn't degrade customer services while in service, despite
licenses. And I would encourage everyone to reject the notion where
license issues cause customer observable issues.

I am fine with the process where we /must/ configure call-come, and
this call-home should support HTTP (not S) proxy. Where HTTPS proxy
then calls the vendor.  The data sent should be human readable, like
JSON, YAML with no mystery strings or byte arrays so we can confirm no
sensitive data is extracted.
And upon license expiration or call-home not working, your account
team would make it a business problem, not a technical problem of
service users.

I know that smart licenses can be set up in such a way that license
expiration causes outages, but I've always rejected that solution from
Cisco and they do provide alternatives. We've tried to get HTTPS
certificates working for +20years and still for most of BCP appears to
be 'wait until they expire and you have an outage, then panic and
swear it'll be handled properly from now on'.  Idea that we wouldn't
have process problems renewing licenses constantly is naive.







-- 
  ++ytti