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

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
> >                 > >
> >                 >