Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: FW: [EFM] EFM Requirements


 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
> > > 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
> > 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?