On 8/26/20 4:49 AM, Bjørn Mork wrote:
You aren't forcing anything if you allow the users to use any CPE and
document the features it must/should have.
You want IPv4 access without DNS? Then you need CLAT
You don't know what CLAT is? Call your CPE vendor for support
You don't care what CLAT is? Use our CPE
You want to call us for support? Use our CPE
There is no force here. It all is pretty similar to
You want to connect the CPE to our ONT? Then you need Ethernet
etc.
excluding all those TokenRing routers.
I don't force them to. I was countering the other arguments up-thread
from folks who do so, and I understand why they do.
I'd say easily 90% of my customers take my offered RG-CPE without any
questions whatsoever - they in fact have come to expect that I provide one.
Of the remaining 10%, easily half or more of them are satisfied with the
RG-CPE I provide after I explain a few things about it (and I have a
cut-sheet for the support folks to do so where applicable). They mostly
want to know that it's not a braindead piece of crap presumably because
they've had bad experiences in the past with SP-provided RG-CPEs (e.g.
AT&T U-Verse).
It's the remainder I'm talking about. It's almost all "power users".
but even where they do have a fairly firm grasp of basic and even
moderately advanced home/SMB networking, they're often unfamiliar with
SP-side features that have cropped up and start to burden the routers
such as IPv6-IPv4 transition features. This is what I'd like to address
in a more streamlined manner.
To wit:
It would be nice if the consumer router industry could get its
collective act together and at least come up with some easy-ish to
understand feature support table that customers can match up with
their service provider's list of needs.
If you create such a feature table as the service provider, and the
customer is unable to match it against their CPE documentation, then
that's a problem between the CPE vendor and the customer.
I can't understand why you want to make it your problem, as long as you
offer a CPE that just works.
I would LOVE to be able to just create such a required features table.
The issue is that there are virtually no retail (even niche online
channels) CPE devices that clearly document their capabilities to match
up with my feature table. That's what I'm whinging about that the
retail RG-CPE industry really should address, IMO.
I can adopt best practices to make sure I provide configuration info via
the proper DHCP(v6) options, attempt to delay making such features
mandatory by providing e.g. NAT444 fallback, etc. as long as possible,
etc., but eventually, people are going to have to migrate to equipment
that supports these more modern features or be left behind, and, right
now, it's very tough to even identify whether a device you're looking at
in Best Buy or WalMart supports them or not (leaving aside the fact, for
now, that the answer is often "it doesn't").
So, I'm left with the "do what works" option of attempting to enumerate
models known to work. Nobody likes this. Customers feel like they're
unnecessarily constrained, and service providers have to maintain that
list and deal with questions about it for something that should be 100%
a customer decision.
Or, I can just say "You have to use our RG-CPE otherwise you're on your
own and I can't guarantee anything useful will even work.", and that's
not a good way to sell service to the handful of generally outspoken
customers who do want to do things their own way.
--
Brandon Martin