Re: [EFM] RE: OAM Proposals - a ping by any other name
- To: Geoff Thompson <gthompso@xxxxxxxxxxxxxxxxxx>
- Subject: Re: [EFM] RE: OAM Proposals - a ping by any other name
- From: Roy Bynum <rabynum@xxxxxxxxxxxxxx>
- Date: Mon, 22 Apr 2002 13:38:41 -0500
- Cc: "Martin Nuss" <nuss@internetphotonics.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, <bob.barrett@fiberintheloop.com>, "Taborek, Rich" <rich.taborek@intel.com>, <Kevin.Daines@worldwidepackets.com>, <hsuzuki@cisco.com>, <MSquire@hatterasnetworks.com>, "Richard Brand"<rbrand@nortelnetworks.com>, stds-802-3-efm@ieee.org
- In-Reply-To: <4.2.0.58.20020422102401.00ba1aa0@xxxxxxxxxxxxxxxxxxxxxx>
- References: <5.1.0.14.2.20020422101105.01b8b1d0@xxxxxxxxxxxxxxxxxx>
- Sender: owner-stds-802-3-efm@majordomo.ieee.org
Geoff,
What you are talking about are packet services, not private line. Customer
facilities already participate in private line services because of the TDM
overhead framing that exists in local loop facility services. The
customer's CSU/DSU supports the framing overhead and provides the ability
to do such things as loop back, bit level performance monitoring, etc.
For packet services, often the customer router/switch is in a different
management domain that can not inter-operate with the service provider's
management domain because of security reasons. OAMiF tends to be able to
provide a "Line" equivalent level of support.
Thank you,
Roy Bynum
At 10:29 AM 4/22/2002 -0700, Geoff Thompson wrote:
>Roy-
>
>At 10:12 AM 4/22/02 -0500, Roy Bynum wrote:
>
>>Martin,
>>
>>For packet services such as Ethernet VPN, OAMiP is useful to provide
>>"Section" equivalent level autonomous fault bit alarms, or a very low
>>level maintenance function such as turning on or off "Section" equivalent
>>level loop back functions. This is the reason that I supported a
>>simplified version of OAMiP as being optional for EFM.
>>
>>For Private Line services OAMiP is useless.
>
>I do not believe that this is true.
>
>This assumes that the provide wants to keep a sophisticated customer
>completely segregated from OAM. In fact this is not the case, especially
>over long term trends. As carriers get squeezed for revenue they will
>depend more and more for input from their customers. Customer's facilities
>will span several supplier's environments. They are gonna have to be able
>to participate. I believe that putting the relevant data within frames is
>the only viable way to allow that to happen.
>
>
>>Thank you,
>>Roy Bynum
>
>Geoff
>
>