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