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

RE: FW: [EFM] EFM Requirements


I think that it has been recognized that any upper layer functionality, 
such as DHCP does not belong within 802.3.  This thread seems to going more 
towards a specific direction of application support, not part of what can 
be within the requirements of EFM.  This may be of importance to you and 
many other people, but it is an implementation specific upper layer support 
for specific applications.  It is distracting from what should be the real 
work of 802.3ah, EFM.

Please do not confuse the issues with IETF IP standards implementations 
with what 802.3 provides.  Issues that you may have with IP application 
support needs to be taken to IETF, not 802.3.  Having tested Ethernet 
inherent performance properties over various systems and environments, I 
can assure you that whatever EFM comes up with, if your applications can be 
supported over a closed Ethernet full duplex link today, they will be 
supported by EFM.

Thank you,
Roy Bynum

At 09:09 AM 8/23/01 -0400, Francois D. Menard wrote:

>Fletcher Kittredge wrote:
> > Here is my current argument on compatibility with DOCSIS:
> > 1) That EFM be DHCP compatible.  If there is any configuration of the
> >   client premises equipment (CPE), it be via DHCP.  the CPE should
> >   support the features that DOCSIS supports, such as "relay agent".
>DHCP is a great abobination compared to the Neighbourhood Discovery
>Protocol of IPv6.  However, I agree that IPv4 DHCP needs to be
> > 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
> > 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.
> > 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.
>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