[802.3ae] FW: Apparent Inconsistencies in P802.3ae D3.1
I would like to forward to attention of the IEEE 802.3ae editors and SG
members, the following message from one of the contributors to the IETF
Ethernet WIS MIB effort. I hope that you will find the comments on the
issues raised by this message useful.
Regards,
Dan
> -----Original Message-----
> From: C. M. Heard [mailto:heard@xxxxxxxxx]
> Sent: Friday, August 03, 2001 1:26 AM
> To: Dan Romascanu
> Subject: Apparent Inconsistencies in P802.3ae D3.1
>
>
> Dan --
>
> While preparing my comments on <draft-ietf-hubmib-wis-mib-00.txt>
> I found some apparent inconsistencies in P802.3ae D3.1, which you
> will find listed below my signature. One of these seems fairly
> important because it concerns the implementability of a hardware
> interface. I'm not certain what is the proper procedure to follow
> to get this information to the IEEE. I know that in some cases it's
> customary to follow a formal liason procedure, but I don't know if
> that applies here. Some guidance or suggestion from you would be
> greatly appreciated. If you think it would suffice simply to forward
> this note to someone in the IEEE then please feel free to do so.
>
> Regards,
>
> Mike
>
> Issues with P802.3ae D3.1 uncovered while reviewing ETHER-WIS draft
> -------------------------------------------------------------------
>
> 1. aFarEndPathStatus and WIS STatus Register 3 Far-End AIS
> and LOP Bits
> are Inconsistent with the Path Status (G1) Byte Coding
> Specifications
>
> P802.3ae D3.1 clause 30.8.1.1.25 defines three bit positions for
> the managed object aFarEndPathStatus. The first bit is defined
> to indicate remote payload defects (PLM-P or LCD-P), the second
> is defined to indicate remote AIS-P defects, and the third is
> defined to indicate remote LOP-P defects. Clause 45.2.2.8 defines
> three corresponding status bits in 10G WIS Status 3 register
> (Register 2.33), viz., 2.33.10 (Far End PLM-P/LCD-P), 2.33.9 (Far
> End AIS-P), and 2.33.8 (Far End LOP-P). On the other
> hand, P802.3ae
> clause 50.3.2.1, Transmit Path Overhead Insertion, states
> that the G1
> overhead byte (STS PAth Status) is supported and is coded according
> to the specifications of ANSI T1.416-1999; and clause 50.3.2.5,
> Fault Processing, states that path defects and anomalies listed in
> Table 504 -- including, in particular, ERDI-P -- shall be
> detected and processed as defined by Section 7.5 of ANSI
> T1.416-1999.
> Section 7.5 of ANSI T1.416-1999 states in turn that the setting of
> ERDI-P in response to LOP-P and AIS-P, TIM-P or UNEQ-P, or PLM-P is
> specified in ANSI T1.231. Here is what ANSI T1.231-1997 says:
>
> 8.1.2.4.5.3 ERDI-P Signal
> The ERDI-P signal is the occurrence of a "101", "110", or "010"
> pattern in bits 5, 6, and 7 of the G1 byte in the path overhead.
> The ERDI-P signal shall be generated within 100 ms by an STS PTE
> upon detection of a defect(s) shown in the following:
> 1. ERDI-P signal="101" upon detection of an AIS-P or
> LOP-P defect
> 2. ERDI-P signal="110" upon detection of a TIM-P or
> UNEQ-P defect
> 3. ERDI-P signal="010" upon detection of a PLM-P defect (29)
> Since more than one of these defects can occur
> simultaneously and
> only one can be carried by the ERDI-P at a time, the
> defect higher
> on the list shall have priority. Transmission of the
> ERDI-P signal
> shall cease within 100 ms after the STS PTE no longer
> detects any
> one of these defects. The ERDI-P signal shall
> accurately report the
> presence or absence of any one of these defects. The
> ERDI-P signal
> is defined in ANSI T1.105. (30)
>
> 8.1.2.4.5.3.1 ERDI-P server defect (31)
> The ERDI-P server defect occurs when the presence of the ERDI-P
> signal with the G1 bits 5, 6, and 7 set to "101", or an RDI-P
> signal (i.e., G1 bits 5, 6 and 7 set to "100" or "111") in ten
> contiguous frames is detected. The ERDI-P server defect is
> terminated when a signal is detected with G1 bits 5, 6, and 7
> not set to "101", "100", or "111" in ten contiguous frames.
>
> 8.1.2.4.5.3.2 ERDI-P connectivity defect
> The ERDI-P connectivity defect occurs when the presence of the
> ERDI-P signal with the G1 bits 5, 6, and 7 set to "110" in ten
> contiguous frames is detected. The ERDI-P connectivity defect
> is terminated when a signal is detected with G1 bits 5, 6 and 7
> not set to "110" in ten contiguous frames.
>
> 8.1.2.4.5.3.3 ERDI-P payload defect
> The ERDI-P payload defect occurs when the presence of the ERDI-P
> signal with the G1 bits 5, 6, and 7 set to "010"in ten
> contiguous
> frames is detected. The ERDI-P payload defect is terminated when
> a signal is detected with G1 bits 5, 6 and 7 not set to "010" in
> ten contiguous frames.
> --
> (29) This code is also used in ATM services to indicate
> a loss of
> cell delineation defect (see ANSI T1.646).
> (30) At the time of publication of this document, ITU-T
> G.707-1996
> misstates the ERDI-P definition.
> (31)In order to provide general compatibility with the RDI-P
> specified in ANSI T1.231-1993, "100" and "111" are
> included in the
> ERDI-P server defect criteria.
>
> Clause 50.3.2.5 states that the LCD-P defect shares the same coding
> value and reporting method as the PLM-P defect, as is the case for
> ATM. T1.105 further states that the encoding for no defect is 001
> when ERDI-P is used and is 000 when RDI-P is used and that the code
> 011 is to be interpreted as no remote defect. It can be seen,
> then, that after taking into account all the specifications
> incorporated by reference that that the coding and interpretation
> of G1 bits 5, 6, and 7 is as follows:
>
> Bit Pattern When Transmitted How
> Interpreted When Received
> 000 -never- No remote
> path defect
> 001 No locally-detected path defect No remote
> path defect
> 010 PLM-P or LCD-P detected Remote
> payload defect
> 011 -never- No remote
> path defect
> 100 -never- Remote
> server defect
> 101 AIS-P or LOP-P detected Remote
> server defect
> 110 -never-
> Unspecified (see note)
> 111 -never- Remote
> server defect
>
> Note: 110 is the encoding for a remote connectivity defect, i.e.,
> TIM-P or UNEQ-P. Neither of these is supported by the WIS
> (although
> they could be, since it is possible for two WIS devices to be
> unintentionally misconnected [TIM-P] or for a WIS device to be
> unintentionally misconnected to an unprovisioned SONET
> port [UNEQ-P]).
>
> One can see from this that there is no way for
> aFarEndPathStatus or for
> 10G WIS Status 3 register to separately report remote
> AIS-P and LOP-P
> defects since both are reported to the remote end via the
> ERDI-P server
> defect code 101. The suggested fixes are as follows:
>
> - re-define WIS Status 3 Register bit 2.33.9 as a reserved bit and
> re-define WIS Status 3 Register bit 2.33.8 as a Far End AIS-P/LOP-P
> flag;
>
> - change the definitons of the bits of aFarEndPathStatus
> so that the
> first bit indicates remote payload defects (PLM-P or LCD-P) and the
> second bit indicates remote server defects (AIS-P or LOP-P).
>
> In addition, it should be clearly specified what action should be
> taken if the ERDI-P connectivity defect code 110 is received, even
> if only to say that it is ignored.
>
> 2. Status Object Clear Actions are not Atomic With Respect to Reads
>
> aSectionStatus, aLineStatus, aPathStatus, and aFarEndPathStatus are
> all defined to be latching, i.e., when a bit is set it remains set
> until cleared by one of the and have corresponding clear actions
> acClearSectionStatus, acClearLineStatus, acClearPathStatus, or
> acClearFarEndPathStatus. The problem is that the status objects
> have multiple bits. That leaves the following possibility open:
> one of the bits in a status object is set; the management statio
> issues a get and then a clear action; and while the clear
> action is
> in flight, another bit becomes set, and then the
> underlying condition
> clears. The next read will not show the evidence of the transient
> condition, which is presumably the reason for having
> latching status
> bits. It might be worthwhile to consider including a bit mask
> parameter for the clear action indicating which bits are
> to be cleared.
>
> 3. Status Objects are Mandatory but Clear Actions are Optional
>
> aSectionStatus, aLineStatus, aPathStatus, and aFarEndPathStatus
> are part of pWISBasic, but acClearSectionStatus, acClearLineStatus,
> acClearPathStatus, and acClearFarEndPathStatus are part of
> pWISOptional. It does not seem that latching status objects would
> be very useful without the corresponding clear objects. It might
> be worthwhile to consider moving the clear actions to pWISBasic.
>
application/ms-tnef