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

RE: [EFM] OAM loop back / echo server function


What about a "loop back" within the OAM overhead?  That would be able to 
function regardless of the Ethernet traffic and network.  It may not be 
what some people are wanting, but it is better than nothing.

Thank you,
Roy Bynum

At 02:11 PM 8/31/01 -0700, Geoff Thompson wrote:

>This reminds me how dumb I get sometimes in that I did not jump on this 
>I believe that Bob is correct in his statement that looping back Ethernet 
>is a really bad idea.
>I'll say it again more explicitly:
>         Raw physical loopback of Ethernet is a really bad idea.
>It breaks/screws up networks that were not designed to tolerate it.
>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"
>At 12:02 PM 8/30/01 -0700, Denton Gentry wrote:
>>>Bob Barrett wrote:
>>>Remote loop back of Ethernet packets / 802.3 frames is a really bad idea.
>>>No mater how well intentioned it will go wrong sometimes and when it does
>>>it is really bad news.
>>>I thought we were looking at some form of simple echo server function i.e.
>>>take a received packet, swap the SA and DA, then send it back out with a
>>>new CRC, same payload ????
>>  There was a presentation to that effect at the last meeting, describing
>>the merits of the LLC2 TEST frame and how having something like it be
>>widely implemented would be a good thing. There will likely be a followup
>>presentation in Copenhagen discussing details of the proposed mechanism.
>>  I don't think an honest to goodness remote loopback, where the RX is
>>logically connected to the TX at the remote end, is even possible in EFM
>>for the simple reason that the links we're looking at may be asymmetric.
>>PONs and DSL-based copper solutions can provide more bandwidth in one
>>direction than another.