Re: IEEE 802.3ah - EOAM - clause 57 - need clarification on the statements in section 57.2.11.4 & 57.2.11.6

Dominique bastien <[email protected]> Thu, 16 Feb 2006 22:17:54 -0500 (EST)
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
Q: 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?

A: Few thing can happen, the local peer can resend the
loopback command or wait an other second. In a network
in trouble you maybe need to send few loopback command
before receiving the Information TLV with the State
octet set properly. When the state field
(local_par_action parameter to LB and the
local_mux_action to DISCARD) show you that you can
begin to send test traffic, the test can begin. It's
only a matter of resending message versus waiting for
response.


Dominique

--- Geetha K <[email protected]> wrote:

> 
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 



	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca