RE: [EFM] OAM - Faye's seven points
Fletcher
If the CPE is multiport it would be nice to be able to turn ports on and
off, but I guess you are right, this is an SP control requirement that sits
above EFM. However, it does need an OAM channel over which vendors can do as
they wish. I guess vendors can always do this stuff via IP (SNMP/UDP) over
the Ethernet MAC.
DOCSIS is a complete management specification, not just a comms channel. I
am with you on the 'keep it simple' issue, but as I already have IPR that
supports side-band comms channels and OAM without needing all that software
and processing power, I am biased :-). If EFM doesn't change the PHY at all
(likely in the short term) then my stuff stays proprietary, and I will build
EFM standard product with extras. If EFM changes the PHY for OAM side-band
then I would throw my circuit stuff in as a contribution. Might as well be
hung for a sheep as a lamb :-).
Bob
> -----Original Message-----
> From: Fletcher E Kittredge [mailto:fkittred@xxxxxxx]
> Sent: 21 September 2001 16:25
> To: bob.barrett@xxxxxxxxxxxxxxx
> Cc: Faye Ly; Geoff Thompson; stds-802-3-efm@ieee.org
> Subject: Re: [EFM] OAM - Faye's seven points
>
>
>
> Bob;
>
> I am going to respond to your posting, not Faye's because
> ASCII is easier for me to read.
>
> On Tue, 18 Sep 2001 11:25:43 +0100 "Bob Barrett" wrote:
>
>
> > > 5. Subscriber activation and deactivation (or generally referred to as
> > > provisioning)
> >
> > Mandatory - at the level of EFM this is probably no more then turning a
> > subscriber port on and off, and may be changing an interface from 10M to
> > 100M to 1GE. Anything else is above the scope of EFM I would think.
>
> Why does this have to be part of the EFM standard? Isn't this a
> function of the SP-side equipment?
>
> > > 6. CPE maintanence (upgrade, backup ...)
> >
> > Desirable - possibly an area where EFM defines a cooms channel
> but not the
> > protocol or methodology that vendors implement over it ????
>
> This sounds like the DOCIS rat-hole. Good to have, but as Howard
> Frasier pointed out in an earlier message:
>
> * The Project Authorization Request (PAR) for 802.3ah defines the scope
> * of the project as:
> *
> * Define 802.3 Media Access Control (MAC) parameters and
> * minimal augmentation of the MAC operation, physical layer
> * specifications, and management parameters for the transfer
> * of 802.3 format frames in subscriber access networks at
> * operating speeds within the scope of the current IEEE Std
> * 802.3 and approved new projects.
> *
> * Note that there is no mention of adding priorities, extending VLAN
> * tag fields, DOCSIS head end compatibility, tftp, encryption, security,
> * QoS, port authentication, interoperability with 802.17, voice, video,
> * or many of the other issues that have been raised on this reflector
> * lately.
> *
> * We will be writing an 802.3 standard, which means that our scope
> * is limited to the MAC, the PHY, and layer management. Fortunately,
> * these are very well defined and narrowly scoped areas for study.
> * That means we have some hope of completing the project in a reasonable
> * length of time.
>
> regards,
> fletcher
>