RE: FW: [EFM] EFM Requirements
Francios,
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
>supported.
>
> > 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.
>
> > 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
>appropriate.
>
>-=Francois=-