RE: [EFM] OAM - Faye's seven points
Bob,
Thanks for the tip. Will bear that in mind.
-faye
-----Original Message-----
From: Bob Barrett
Sent: Sat 9/22/2001 8:38 AM
To: Faye Ly; Harry Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Faye,
I have been out of the LAN world for a while.
I'll listen to the service providers for my lead on what stats
to keep. I hate doing things just for the sake of it :-). If every time
I check the counters they are either zero because of no errors or zero
because the line is down then I don't gain a lot by having them. In
fiber I think one parameter to keep a record of is receive optical
power, and we should ensure that we cater for this in the definition of
managed objects (and encourage the component vendors to support this
function in receivers).
Best regards
Bob Barrett
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Faye Ly
Sent: 21 September 2001 18:32
To: bob.barrett@xxxxxxxxxxxxxxx; Harry Hvostov; Roy
Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Bob,
Some 15 minutes monitoring stats are actually used for
'trend analysis' in the LAN world as well. At least
that
is my own experience. But I am more than happy to
hear your thoughts on this.
-faye
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Bob Barrett
Sent: Friday, September 21, 2001 4:24 AM
To: Faye Ly; Harry Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven points
Preserve us from specifying a G.821 stats like
requirement in EFM for SLA monitoring. That has to be a vendor specific
thing driven by market requirements.
That's me with my LAN head on :-).
Bob Barrett
-----Original Message-----
From: Faye Ly
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Faye Ly
Sent: 21 September 2001 01:11
To: Roy Bynum; Harry Hvostov; Harry
Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven
points
Roy,
Yes, some emails ago I did state that
having a side band
not only ensure OAM traffic will go
through but also
makes sure it doesn't step over to the
user data traffic.
You know sometimes we get carried away
with that
monitoring traffic every 15 minutes :)-
-faye
-----Original Message-----
From: Roy Bynum
Sent: Thu 9/20/2001 3:10 PM
To: Harry Hvostov; Faye Ly; Harry
Hvostov; Roy Bynum
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's seven
points
Harry,
I think that Faye is correct. If the
OAM is "frame" based, then it will
share the same bandwidth with the
customer traffic. Only if the OAM is
"side band" will it not share the same
bandwidth as the customer traffic.
Thank you,
Roy Bynum
At 02:31 PM 9/20/01 -0700, Harry Hvostov
wrote:
>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