Re: FW: [EFM] EFM Requirements
Fletcher,
From everything that is being said here, what is actually being inferred
is that there is a requirement for a service communications channel
embedded in the signalling overhead. This would something equivalent to
the DCC in SONET. Right?
Thank you,
Roy Bynum
At 03:55 PM 8/23/01 -0400, Fletcher E Kittredge wrote:
>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