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

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




[Date: 09/06/2001  From Seto]

Geoff,  

>I don't think this is one that we are going to solve on casual mail 
>discussions.

I agree.  

>There are tradeoffs between the local testing that MAC control provides vs 
>the general capability. I don't think a service provider is going to get 
>very far without knowing the MAC address of subscriber anyway.
>I think this one goes on the issues list.

I agree with the requirements.  How farther we as 802.3 want to 
go is also something we should discuss.  

Seto

>Seto-
>
>At 07:52 AM 9/6/01 +0900, you wrote:
>
>>[Date: 09/06/2001  From Seto]
>>
>>Geoff,
>>
>>Thanks for your comments.
>>
>> >I agree with this goal.
>> >I agree that it should not require IP.
>> >I don't think that means that it needs to be done in MAC Control (but I am
>> >certainly open to discussion)
>>
>>I agree whether we should do it in MAC control is something we
>>should discuss.  ;-)
>>
>> >This brings up the much uglier issue of discovery, also a topic that has
>> >always been outside the scope of 802.3.
>> >If there is going to be a bridge or router at the demarc then there will
>> >have to be a discovery process that effectively logs the MAC address into
>> >the service provider's system. The service provider won't be able to
>> >Ping/Echo the box until it knows the MAC address.
>>
>>I disagree with your presumption that service provider need to
>>know the MAC address of each demarc.  I'm thinking of a frame
>>with 802.1 reserved DA like a 802.3x pause frame.  This frame
>>should not be forwarded by a bridge.  This frame should be
>>ignored by a MAC which does support this L2 ping.  This frame
>>should be used only in P2P networks defined for EFM networks
>>including P2P emulated EPON.
>
>I don't think this is one that we are going to solve on casual mail 
>discussions.
>There are tradeoffs between the local testing that MAC control provides vs 
>the general capability. I don't think a service provider is going to get 
>very far without knowing the MAC address of subscriber anyway.
>I think this one goes on the issues list.
>
>>
>>
>>Seto
>
>Best regards,
>
>Geoff
>