Re: FW: [EFM] EFM Requirements
On Thu, 23 Aug 2001 09:09:25 -0400 "Francois D. Menard" wrote:
> > 2) That if a configuration is loaded for the CPE, the loading follow
> the DOCSIS protocol state machine and message formats and tftp be
> used.
>
> TFTP is fundamentally insecure. I would prefer a more secure protocol.
> How about PXE instead (Programmable eXecution Environment), which is
> used increasingly on thin clients and on PC's. PXE is secure and
> routable.
Correct: tftp is fundamentally insecure. Security always comes at a
cost. The nature of compatibility with legacy systems means that you
need to support inferior designs. If you want to be compatible with
legacy DOCSIS backend systems, then you need to support tftp to load
modem configurations.
I reserve my opinion on: 1) the topic of whether or not loadable CPE
configurations is a good idea, 2) whether the advantage of supporting
DOCSIS is worth the cost in security. Thank you for smoking out this
issue.
> > 3) That if the CPE is capable of being monitored, that SMNP be used
> and that the DOCSIS MIB be supported.
>
> SNMPv3 at least & that the management VLAN be made available through an
> open access point of interconnection & that an EFM MIB be developed (not
> just rubber stamping DOCSIS). I would consider the DOCSIS MIB to be a
> good start off point, however there needs to be more messages conveyed
> at Layer 2 than in DOCSIS, especially as it pertains to link
> failure/resume, signal levels, etc.
A superset MIB sounds good to me. There is no cost that I can see to
a superset MIB. Once again, I would like to stress that I am not sure
that having the CPE be intelligent (IP addressable) is a good idea.
The arguments others have advanced *against* an intelligent CPE seem
strong to me.
> > Think of all the dial-up providers that wanted to do DSL using their
> legacy dial-up backends. Radius auth, PPPoE and PPPoA are a greater
> abomination that DOCSIS will ever be. Ooophs, apologies for slipping
> the opinon vigorously stated as fact in there....
>
> I'm sorry, but DOCSIS Session Identifier to Lable Switched Path (MPLS)
> mapping is an abobination as well. This is the strategy that all cable
> carriers are employing to enable open access now. I wonder to which
> extent is Cablelabs standardizing this behaviour in a CMTS.
Blargh! I missed the DOCSIS Session Identifer to MPLS mapping! Is
that in DOCSIS 1.0 or 1.1 (I know little of 1.1)? Is it a required
item in the standard[s]?
I agree that anything involved in MPLS is suspect and that it would be
a mistake to require MPLS support in any ethernet standard as required
feature.
> The only form of third party access at Layer 2 involves scalable
> management of lots of VLANs. And we have yet to even begin discussing
> how many VLAN's we're going to need and if the 12 bit limit in 802.1Q is
> appropriate.
Perhaps I am missing something, but has it been decided that the above
is a requirement? Wouldn't it be better to keep the initial
spec. very simple and add this additional (hopefully optional)
features later?
regards,
fletcher