On Thu, 23 Jul 2020 at 21:08, Nick Hilliard <[email protected]> wrote: > The whole idea of having your routing stack poll a remote server with a > query which essentially asks "should I continue to operate?" with a > default answer of "No" seems like a unusually stupid way to provision a > network. Regardless of the timeout parameters.
I think it's well done and I can see applications where it adds real value to customers. For us the OPEX of dealing with licenses is too much, we want a one-time fire and forget solution, which they offer. But if I'd install and decom hundreds of CPEs yearly, with varying level of features and I'd immediately transfer feature costs to customers, this is really attractive. You buy the boxes without licenses and you buy licenses separately, and you ship just-in-time the license you actually need, and you return it to your pool once you're done. If pools run dry, you get alerts and you procure more. I also think licenses are a good idea, but often horrible execution. Not having licenses means you're subsiding people who use features heavily. Not having licenses also means the vendor doesn't know where money is pouring in, should they invest in multicast, 6VPE, LISP NRE or something else? Licenses mean you don't subsidize other players, you pay for features you use, vendor will understand where to invest NRE for better return. Similarly as a metered Internet is a great idea, with almost universally horrible executions. I am a heavy user, who is being subsidized by low income moms and pops, doesn't feel fair. For my electricity I pay separately for transmission and consumption, which is a great and fair model. Transmission is fixed cost, use or not, consumption is not. Uncongested Internet would be market driven fact for metered, because in flat rate Internet dropping packets increases margins, in metered Internet it reduces. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
