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