[802.3ae] RE: Apparent Inconsistencies in P802.3ae D3.1
Dan,
Thanks for the information. I'm sure that David Law and Tom Alexander have
seen this email by now, but I will follow up with them to ensure that they
look at these concerns. As a note, because this information concerns D3.1
and we're in the process of creating D3.2, we will not be able to make any
changes until the next revision of the draft. I will make the request that
Mr. Law and Mr. Alexander ensure that comments are generated to close these
issues.
When we do enter the comment and ballot period for D3.2, I would hope that
either yourself or any IETF contributor feel free to use our comment
submission tool. Or, if they would prefer, they could contact Jonathan
Thatcher or myself to have a comment submitted on their behalf.
Thanks,
Brad
Editor-in-Chief, P802.3ae
bradley.booth@xxxxxxxxx
-----Original Message-----
From: Dan Romascanu [mailto:dromasca@xxxxxxxxx]
Sent: Sunday, August 05, 2001 3:58 AM
To: HSSG_reflector (E-mail)
Cc: heard@xxxxxxxxx; hubmib@xxxxxxxx; Geoff Thompson
Subject: 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.
>