Subject: RE: [Hubmib] IEEE 802.3ah - EOAM - clause 57 - need clarification on the statements in section 57.2.11.4 & 57.2.11.6

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 17 Feb 2006 09:25:03 +0200

Geetha,
 
I believe that you are asking questions that are related to the IEEE
802.3 standards, and not to the Ethernet MIB work that is being done in
the IETF. I suggest that you address your clarification questions to the
IEEE 802.3 Working Group. 
 
Best Regards,
 
Dan Romascanu
hubmib WG Chair

  _____  

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Geetha K
	Sent: Thursday, February 16, 2006 4:35 PM
	To: [email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: [Hubmib] IEEE 802.3ah - EOAM - clause 57 - need
clarification on the statements in section 57.2.11.4 & 57.2.11.6

	Section 57.2.11.6:
	=============
	To ensure correct operation, the OAM client needs to, within one
second of 
	receiving a Loopback Control OAMPDU with the Enable OAM Remote
Loopback 
	command:
	a) Set its local_par_action parameter to LB and the
local_mux_action to DISCARD 
	    via OAM_CTL.request service primitive.
	b) Send an Information OAMPDU.  

	Section 57.2.11.4:
	=============
	Since Information OAMPDUs are continually sent to keep the OAM
Discovery process
	from re-starting, the occasional loss of an Information OAMPDU
should not adversely 
	impact the operation of OAM remote loopback mode. 

	The above 2 statements are conflicting: 
	- first statement insists on sending OAMPDU within one second to
ensure correct operation 
	- second statement says that loss os Information OAMPDU should
not adversely impact 
	   the operation of OAM ermote loopback mode.

	In Remote loopback mode, what will happen if the remote peer is
not responding with 
	an information OAMPDU within a second after sending a remote
loopback command? 
	This is critical as the Multiplexer at the local DTE will be put
in Discard state until an 
	information OAMPDU is received and all the frames from higher
layers will be dropped.
	 
	Clarification on this will be highly appreciated.

	Thank you.
	 
	Regards,
	Geetha.

	
************************************************************************
***
	This message is proprietary to Future Software Limited (FSL)
	and is intended solely for the use of the individual to whom it
	is addressed. It may contain privileged or confidential
information
	and should not be circulated or used for any purpose other than
for
	what it is intended.
	
	If you have received this message in error, please notify the
	originator immediately. If you are not the intended recipient,
	you are notified that you are strictly prohibited from using,
	copying, altering, or disclosing the contents of this message.
	FSL accepts no responsibility for loss or damage arising from
	the use of the information transmitted by this email including
	damage from virus.
	
************************************************************************
***

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Geetha K" <[email-masked]>
Date: Fri, 17 Feb 2006 14:07:39 +0530

Hello Dan,
 
Thank you very much for response. I will forward my questions to IEEE 802.3
WG.
 
I have come across the draft mib "draft-ietf-hubmib-efm-mib-03.txt" for 
Ethernet OAM that expired on September, 2005. 
 
Is that MIB standardised (or) Are there any other new draft versions coming
in?
 
Thank you in advance.
 
Best Regards,
Geetha.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Friday, 17 February 2006 12:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Hubmib] IEEE 802.3ah - EOAM - clause 57 - need clarification
on the statements in section 57.2.11.4 & 57.2.11.6

Geetha,
 
I believe that you are asking questions that are related to the IEEE 802.3
standards, and not to the Ethernet MIB work that is being done in the IETF.
I suggest that you address your clarification questions to the IEEE 802.3
Working Group. 
 
Best Regards,
 
Dan Romascanu
hubmib WG Chair

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Geetha K
Sent: Thursday, February 16, 2006 4:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [Hubmib] IEEE 802.3ah - EOAM - clause 57 - need clarification on
the statements in section 57.2.11.4 & 57.2.11.6

Section 57.2.11.6:
=============
To ensure correct operation, the OAM client needs to, within one second of 
receiving a Loopback Control OAMPDU with the Enable OAM Remote Loopback 
command:
a) Set its local_par_action parameter to LB and the local_mux_action to
DISCARD 
    via OAM_CTL.request service primitive.
b) Send an Information OAMPDU.  

Section 57.2.11.4:
=============
Since Information OAMPDUs are continually sent to keep the OAM Discovery
process
from re-starting, the occasional loss of an Information OAMPDU should not
adversely 
impact the operation of OAM remote loopback mode. 

The above 2 statements are conflicting: 
- first statement insists on sending OAMPDU within one second to ensure
correct operation 
- second statement says that loss os Information OAMPDU should not adversely
impact 
   the operation of OAM ermote loopback mode.

In Remote loopback mode, what will happen if the remote peer is not
responding with 
an information OAMPDU within a second after sending a remote loopback
command? 
This is critical as the Multiplexer at the local DTE will be put in Discard
state until an 
information OAMPDU is received and all the frames from higher layers will be
dropped.

Thank you.
 
Regards,
Geetha.

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

***************************************************************************