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
>