RE: [EFM] OAM - Faye's seven points
Harry,
Yes, that I do agree. Sorry about the confusion.
-faye
-----Original Message-----
From: Harry Hvostov
Sent: Thu 9/20/2001 2:31 PM
To: Faye Ly; Harry Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Faye,
What I meant was that the OAM control frames would not be
forwarded outside
the ePON network.
Harry
-----Original Message-----
From: Faye Ly [mailto:faye@xxxxxxxxxx]
Sent: Thursday, September 20, 2001 2:19 PM
To: Harry Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Harry,
I hope I am interpreting your message wrong but
OAM traffic usually terminates at the CPU of the
network equipment. In our case, there will be one
control entity terminated at the CPU of the OLT and
one at ONU. Some OAM traffic proxied from OLT to ONU
will tranverse the PON link with user data destined
for either control end points.
-faye
-----Original Message-----
From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
Sent: Thursday, September 20, 2001 11:08 AM
To: 'Roy Bynum'; Harry Hvostov; Faye Ly
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Roy,
The intent is to terminate OAM control traffic on the ePON
network
(OLT/ONU
MAC service interfaces). Since the customer does not have access
to
either
the OLT or ONU ports, customer traffic and ePON management
traffic are
effectively separated. We do need to ensure that the appropriate
forwarding/filtering interfaces and mechanisms are in place to
enforce
this.
Harry
-----Original Message-----
From: Roy Bynum [mailto:roy.bynum@xxxxxxxx]
Sent: Thursday, September 20, 2001 8:15 AM
To: Harry Hvostov; 'Faye Ly'
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Harry,
I do not like the idea of inserting frames into the customer
traffic. I
am
not sure how it would work such that, for security reasons, only
the
intended physical interface on a P2MP deployment would receive
the OAM
Ethernet frames. Call me paranoid.
Thank you,
Roy Bynum
At 11:33 AM 9/19/01 -0700, Harry Hvostov wrote:
>Faye,
>
>I would like to see a provision for Ethernet frame based OAM. I
believe
>Ethernet OAM message transport is quite viable for EFM and we
should be
>seeing some
>presentations detailing this approach.
>
>Harry
>-----Original Message-----
>From: Faye Ly [mailto:faye@xxxxxxxxxx]
>Sent: Tuesday, September 18, 2001 9:45 PM
>To: Roy Bynum
>Cc: stds-802-3-efm
>Subject: RE: [EFM] OAM - Faye's seven points
>
>Roy,
>
>Thank you for the clarification. Dedicated OAM
>channel does have the merit of pre-defined and
>set-aside bandwidth for mangement traffic. This
>not only means some sort of assurance that
>OAM will get to the CPE but also helps not
>to step over to subscriber's bandwidth.
>
>This is the mechanism I am most familiar with
>anyway. I am very open to other mechanism
>that makes sense for EFM.
>
>-faye
>-----Original Message-----
>From: Roy Bynum
>Sent: Tue 9/18/2001 7:30 PM
>To: Faye Ly
>Cc: stds-802-3-efm
>Subject: RE: [EFM] OAM - Faye's seven points
>
>Faye,
>
>Unless you get a bit error that "garbages" an octet, once a
message is
>encoded and transmitted, it does not get dropped while it is in
the
>link. Full duplex does not even have to worry about
collisions. If
the
>OAM messaging is in an "out-of-band" channel there is not even
the
conflict
>of competing with the data stream for insertion. There is no
need for
>priority queuing of the OAM messages in that type of PHY.
>
>At 04:54 PM 9/18/01 -0700, Faye Ly wrote:
> >Geoff,
> >
> >Some OAM traffic is more critical than others. For example -
> >
> >OAM command like 'reset' (in our case, reset CPE) should not
be
> >retried. Certainly don't want to reset the CPE a couple of
times
> >just because network is slow. Giving up means sending a
technician
> >to the field to actually toggle the power button on the CPE.
This
> >is very expensive. The whole reason of requesting for a
dedicated
> >OAM channel/IPG/whatever is to gurantee that no acutal human
> >needs to be sent to the field. Maybe this is not do-able
but we
> >ought to try our best.
> >
> >On a side note -
> >
> >Can you please clarify the statement "P2P PHYs do not drop
packets"?
> >This is good. I don't need to keep all those dropped
packets/bytes
> >error counters then. Thanks.
> >
> >-faye
> >
> >
> > : Geoff Thompson
> > Sent: Tue 9/18/2001 2:38 PM
> > To: bob.barrett
> > Cc: Faye Ly; Geoff Thompson; fkittred;
stds-802-3-efm
> > Subject: RE: [EFM] OAM - Faye's seven points
> >
> >
> > Bob-
> >
> > At 11:25 AM 9/18/01 +0100, Bob Barrett wrote:
> >
> >
> > Faye,
> >
> > I think your re-stating these seven points
is very
> >timely. If we were at a
> > meeting I would suggest that we had a straw
poll on
each
> >of them. I would
> > add an eighth i.e.
> >
> > 8. What kind of OAM&P traffic requires
guaranteed
> >delivery?
> >
> >
> > 1) We don't do "P". We have already agreed that
provisioning
is
> >declared to be outside our scope
> > 2) There is no such thing as guaranteed delivery
> > 3) P2P PHYs do not drop packets
> > 4) Properly designed CSMA/CD LANs do not lose
packets. At
worst
> >they try to send for awhile and if they don't get through
they give
up.
> >
> > Geoff
> >
> >
> >
> >
> > Short answer: All of it.
> >
> > Slight need for clarification: Bob Barrett
(me) is
an
> >equipment designer,
> > not a service provider. I just happen to
have been
> >designing and selling
> > access equipment for the past ten years,
rather than
> >enterprise equipment. I
> > learnt about the OAM needs of my customers
the hard
way,
> >by building-in what
> > I thought were reasonable OAM systems and
then being
> >advised that I had not
> > got it quite right (and they don't buy what
is not
quite
> >right).
> > Nevertheless, I will answer the seven points
as I
see
> >them, see below,
> >
> > Bob Barrett
> >
> > > -----Original Message-----
> > > From: Faye Ly
> [<mailto:faye@xxxxxxxxxx>mailto:faye@xxxxxxxxxx]
> > > Sent: 17 September 2001 18:32
> > > To: bob.barrett@xxxxxxxxxxxxxxx; Geoff
Thompson;
> >fkittred@xxxxxxx
> > > Cc: stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] OAM developing Geoff's
observation.
> > >
> > >
> > > Bob,
> > >
> > > This largely depends on the requirements.
What
kind
> >of OAM&P traffic
> > > requires
> > > guaranteed delivery? And also what kind
of
> >intelligence we require from
> > > the
> > > CPE and still maintain the low cost. If
you can
tell
> >me what is the
> > > requirements
> > > for each of the OAM&P traffic listed
below: (This
is
> >the minimum list
> > > of
> > > OAM&P traffic I can think of)
> > >
> > > 1. Reset command
> >
> > Mandatory
> >
> > > 2. Link failure/status
> >
> > Mandatory
> >
> > > 3. CPE registration or inventory (The
former is
the
> >action and the later
> > > is
> > > the results).
> >
> > Some form of registration, even if it is
operator
driven
> >is mandatory.
> > Auto registration is desirable.
> >
> > > 4. Connectivity diagnose (ping etc) - This
is
divided
> >into link
> > > connectivity which
> > > can be covered by 2 and subscriber line
connectivity.
> >
> > Mandatory for the link, up to a point as
close to
the
> >subscriber interface
> > as possible e.g. copper loop back on the
connector
side
> >of the IC, in the
> > last output stage of the IC (most PHY ICs
support
this
> >already).
> >
> > Tests to the subscriber equipment are
outside of the
> >scope of EFM, but in
> > real terms the service provider will
probably PING
> >something on the
> > subscriber network, given access rights.
> >
> > > 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.
> >
> > > 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
> >????
> >
> > > 7. Accounting information on the
subscriber line -
> >optional since some
> > > of
> > > the accounting data is actually collected
at the
> >aggregated box.
> >
> > I agree that this function is not required
within
the
> >CPE. However, RMON
> > type stats might be useful within the CPE as
history
for
> >diagnostics, but
> > not required as a source of relable data for
billing
> >information. I think
> > this will be a vendor specific thing. The
existing
> >standards define what can
> > be done. The vendors will choose what they
implement.
> >The customers will
> > choose equipment that has the right balance
of
features
> >and commercial terms
> > for them.
> >
> > >
> > > This will be really helpful for the
vendors that
are
> >building these
> > > equipements
> > > to justify for the need or the size of a
dedicated
> >OAM&P channel.
> >
> > Sometimes as vendors we have to make
inspired
guesses
> >:-).
> >
> > On Sanjeev Mahalawat's point in an email
to/from
Faye -
> >I think it is highly
> > desirable that some form of head-end proxy
server is
> >used to translate the
> > rather complex management requirements of
the NOC
NMS
> >systems into simpler
> > commands for the EFM systems. And also take
simple
alarm
> >and status messages
> > from EFM CPE and create SNMP traps and
browser pages
for
> >the human
> > interface. Consolidating the 'presentation
intelligence
> >and processing' in a
> > head end proxy server shares the cost of the
engine
> >across multiple CPE
> > nodes. The CPE needs only a micro-controller
(or
less),
> >rather than an
> > engine with a full IP stack. Low cost
embedded JAVA
> >processors are coming,
> > but they are taking their time :-).
> >
> > The EFM technical point is:
> >
> > 'keep EFM OAM simple; vendors can implement
the
cleaver
> >stuff; economically
> > this will probably at the head end; there is
an
> >opportunity for silicon to
> > do this at the CPE end, but that may take a
while'.
> >
> > Bob Barrett
> >
> > > -faye
> > >
> > > -----Original Message-----
> > > From: Bob Barrett
>
[<mailto:bob.barrett@xxxxxxxxxxxxxxx>mailto:bob.barrett@xxxxxxxxxxxxxxx]
> > > Sent: Saturday, September 15, 2001 5:36 AM
> > > To: Geoff Thompson; fkittred@xxxxxxx
> > > Cc: stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] OAM developing Geoff's
observation.
> > >
> > >
> > >
> > > I'm late in on this thread, so there may
be a
similar
> >comment further up
> > > my
> > > in-box from somebody else.
> > >
> > > Geoff's observation is pretty fundamental:
> > >
> > > > My expectation is that the demarcation
device
will
> >probably end
> > > > up with an IP address in order to
support:
> > > > SNMP for OA&M
> > > > Firewall services for the
subscriber
> > > >
> > > > (That issue is, of course, beyond our
scope)
> > >
> > > The logical conclusion of this observation
is that
EFM
> >should make the
> > > OAM
> > > at layer two as simplistic as possible
fulfilling
only
> >the basic
> > > requirements i.e. limited number of
managed
objects
> >and limited echo (L2
> > > ping) test. Vendors can then leverage ietf
standards
> >(note: the users
> > > tends
> > > to like these) to implement ietf style
'standard'
> >management functions.
> > > Isn't that what we all have in mind anyway
:-).
> > >
> > > The open question then is will the service
provider
> >market accept
> > > in-band
> > > management i.e. management IP frames mixed
with
user
> >traffic, or is
> > > there a
> > > real requirement for a side-band channel.
If EFM
does
> >need to include a
> > > side
> > > band channel then all that it needs to be
is a
> >communications channel
> > > (bit
> > > stream), probably squeezed in the preamble
or the
IPG
> >(we can debate
> > > that
> > > choice for a while). Vendors can then
implement
either
> >a standards based
> > > method of comms over that channel or do
there own
> >thing. Personally I
> > > would
> > > expect vendors to choose something like IP
over
PPP
> >for this.
> > >
> > > I can wrap this all up in a presentation
for the
next
> >meeting if
> > > required.
> > >
> > > (Just seen Geoff's comment on this in
response to
> >Roy's thread; as a
> > > vendor
> > > we will probably want to support both
in-band and
> >side-band,
> > > standardised or
> > > not, but we would prefer a standard for
side band
as
> >part of EFM).
> > >
> > > Bob Barrett
> > >
> > > > -----Original Message-----
> > > > From:
owner-stds-802-3-efm@majordomo.ieee.org
> > > >
>
[<mailto:owner-stds-802-3-efm@majordomo.ieee.org>mailto:owner-stds-802-3
-efm
@majordomo.ieee.org]On
>
>
><<mailto:owner-stds-802-3-efm@majordomo.ieee.org%5DOn>mailto:owner-stds
-8
> 02-3-efm@xxxxxxxxxxxxxxxxxx%5DOn> Behalf Of Geoff
> > > > Thompson
> > > > Sent: 04 September 2001 23:03
> > > > To: fkittred@xxxxxxx
> > > > Cc: stds-802-3-efm@ieee.org
> > > > Subject: Re: [EFM] OAM loop back / echo
server
> >function
> > > >
> > > >
> > > >
> > > > Fletcher-
> > > >
> > > > I don't think this is a stupid question.
> > > > I don't think we need an IP level PING
> > > > A L2 ping would do, perhaps even better,
the
demarc
> >would look for
> > > PING
> > > > type and then just swap SA & DA.
> > > > My expectation is that the demarcation
device
will
> >need a MAC address
> > > > My expectation is that the demarcation
device
will
> >probably end
> > > > up with an
> > > > IP address in order to support:
> > > > SNMP for OA&M
> > > > Firewall services for the
subscriber
> > > >
> > > > (That issue is, of course, beyond our
scope)
> > > >
> > > > Geoff
> > > >
> > > > At 03:47 PM 9/4/01 -0400, Fletcher E
Kittredge
> >wrote:
> > > > >On Fri, 31 Aug 2001 14:11:54 -0700
"Geoff
> >Thompson" wrote:
> > > > > > As I have said before, I do believe
that we
will
> >need a
> > > > demarcation device
> > > > > > that has the capability to host OA&M
functions.
> > > > > > We have talked about "loop back"
from this
point
> >in the network.
> > > > > > Let us forevermore make that "PING"
> > > > >
> > > > >Geoff;
> > > > >
> > > > > Apologies if this is a stupid
question,
> >but does PING in
> > > this
> > > > >context mean the utility that sends an
IP ICMP
ECHO
> >REQUEST packet
> > > and
> > > > >listens for an ECHO REPLY packet? If
so, am I
> >correct in thinking
> > > this
> > > > >means the demarcation device would
require an
IP
> >address?
> > > > >
> > > > >thanks!
> > > > >fletcher
> > > >
> > >
winmail.dat