Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage i

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Yair, again – I don’t want my fingerprints on this broken car. This text is unnecessary, and I oppose it. The language issue that Chad changed was an example of the kind of trouble we can get ourselves in.

As previously written, it was problematic because, in IEEE Standards, certain words have special meanings. “May” is one of them. Text with “May” in it needs to work when substituted with “is permitted to”, and it’s use is primarily intended for guides, not standards (see https://standards.ieee.org/develop/stdswritten.html ) , and, in standards it usually is indicating a specified option.

What you meant to say can be achieved with the word “can” and thereby avoid one source of potential delay to our standard. There are several in the sponsor ballot pool who often watch out for the special words and generate comments if it appears even remotely inappropriate, thereby delaying our standard another 1 or 2 rounds of circulation for something that added or changed no normative requirements. What you meant was it “can” change the value, which isn’t a special word so it doesn’t cause a comment.

Additionally there is the language issue of “affect” vs. “effect” – it often causes comments, hence, avoiding that use of language avoids yet another language-oriented comment.

It is important to know that we are at the point now where what we want to do is avoid having an additional comment cycle. You can argue that you were right all you want, but the argument only delays us. Remember that the people this ultimately depends on are not all on the reflector nor do they attend our meetings – that’s the nature of Sponsor ballot. NOT MAKING CHANGES THAT DON’T FIX PROBLEMS WITH REQUIREMENTS is the best way to get convergence to a final standard. Even small language issues can cause comments and additional cycles.

George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications

1-310-920-3860

george@xxxxxxxxxxxxxxxxxxxx

From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Thursday, June 14, 2018 11:20 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Hi George,

I believe that you are referring to my latest proposal to Lennart (on June 13) to a shorter text i.e. :

"IPort_MPS may be affected by Irev. See 145.2.10.4, 145.3.8.8.” which you also suggested to Chad. All my emails for the last 3 days where about this text and not the previous longer one.

I believe that the probability for this text to create new comments is low. And if I am wrong, let’s take this text and remove or change the things that you believe are problematic.

Addressing your inputs:

-why using “may” is a problem in informative text?

-The question if using affect or effect looks to me trivial since the text says “…may be affected..” which looks to me as a correct form when “affected” is used. Am I missing anything here?

What about:

"Irev may change the value of IPort_MPS. See 145.2.10.4, 145.3.8.8.”

(so one less concern)

Regarding “may”, still I don’t see the problem?

Yair

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, June 14, 2018 8:05 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

FYI – I had suggested this to Chad because the text as proposed would likely have generated another round of comments (due to the use of may, and common confusion with “affect” vs. “effect”). This is the kind of thing that happens when you change text at the last minute without actually adding a technical specification. I want to make it clear – I still oppose the change, which is purely informative and doesn’t change the technical requirements.

I did not send the suggestion to the reflector because I did not want (and do not want) to help fix a broken car and therefore put my fingerprints on it, only to later find it involved in a hit-and-run accident…

George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications

1-310-920-3860

george@xxxxxxxxxxxxxxxxxxxx

From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Thursday, June 14, 2018 9:44 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Which I am OK with this solution.

Yair

From: Chad Jones (cmjones) [mailto:00000b60b3f54e8d-dmarc-request@xxxxxxxx]
Sent: Thursday, June 14, 2018 7:39 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Editorial suggestions have been sent to me offline. Here is the recommended text to consider as the solution:

IPort_MPS can be impacted by Irev. See 145.2.10.4, 145.3.8.8.

Chad Jones

Tech Lead, Cisco Systems

Chair, IEEE P802.3bt 4PPoE Task Force

Principal, NFPA 70 CMP3

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Reply-To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Date: Thursday, June 14, 2018 at 9:16 AM
To: 4PPOE Reflector <STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Yair – your argument would be correct IF the standard were the ONLY document or source of information available to the PD designer. I won’t be, and already isn’t. Unless this is a new requirement (rather than a pointer to another place in the document) the standard is complete and doesn’t need it. I understand your desire to make the standard more understandable, but the large number of cross references within the standard is actually making it less understandable. At some point the reader stops following those “see x.y.z” statements because they have become too numerous. In my opinion, they already have. It would be far better to take the more detailed explanation of the situation (which you have nicely provided in this thread) into an explanatory or tutorial whitepaper or other publication to help the PD designer.

George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications

1-310-920-3860

george@xxxxxxxxxxxxxxxxxxxx

From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Thursday, June 14, 2018 8:09 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Hi Chris,

All what you said is true but it is not easy to understand the effect of Irev on PD.

See how much work I and others invested to investigate the potential issues, we have found issues and as a result we change the proposed baseline until we clear all issues. We did it for every function. We didn’t do it for MPS. Now I am trying to complete my work and address this item to.

As I said in my previous mails: This is the first time that setting a PD parameter is depend on other PSE parameter in a very complex scenario:

PSE is a 4-pair but operate in 2-pair that is actually 3-pair and is connected to a PD that uses ideal diode bridge that if it gets 3-pairs due to design mistake (that many of us did..) is backffeding and as a result anything that exists at the PSE unpowered pair is reflected and became part of the PD signature, PD class (new news: PD MPS) which may alter its performance.

Now, how a PD designer will understand all of this in fair amount of time without being part of our group or without given a hint to look for this dependencies?

The key issue is: we had never had a parameter specified in the PD that is affected by a parameter in the PSE. Please check and verify that until D3.4 all PD initial parameters where set only by the PD and PSE has zero control on it. D3.5 violates this concept and we need to make sure that we are not misleading the reader.

Yair

From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
Sent: Thursday, June 14, 2018 4:51 PM
To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>; STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Hi Yair,

In clause 33, we did not mention Ihold in the PD section. If the PD designer wanted to implement the feature that you are talking about, he would have had to read the PSE section to understand the Ihold thresholds and timing. The same is true in 802.3bt, except now the PD designer needs to read the PSE section to understand Ihold and Irev. This is nothing new.

Thanks,

Chris

From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Sent: Thursday, June 14, 2018 8:34 AM
To: Chris Bullock (bullock) <bullock@xxxxxxxxx>; STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Hi Chris,

Not sure that I understand the question.

In clause 33, we are working on 2-pair. When working over 2-pair, you need to meet backffed at any voltage (detection , classification powerup/on) which means maximum 2.8V over 100K i.e. maximum 28uA. This means that nothing is reflected from the unpowered pair to the signature resistor, classification current or MPS. So, we don’t have problem and PD set its MPS current per the PD needs without the concern that something in the PSE will affect the MPS current.

In 802.3bt D3.5 in a 4-pair system, when we operate in 2-pair (which is 3-pair), we need to address the case of the PDs with the ideal diode bridge that doesn’t meet backfeed in 3-pair. This behavior cause to any impedance on the PSE on the unpowered pair to be reflected in parallel to the PD elements and cause that to change their total value which ends up with change of resistance or current at the PD.

In our case it is the MPS. The MPS current is affected by Irev which is generated in the PSE on the unpowered pair. So, a PD is set its MPS in order to be disconnected but due to Irev in the PSE, the PD MPS setting will be changed and present a new value that may end with keep the PD powered which was not the intent of the PD!

Now in order to not mislead the PD designer, in case he is not aware of Irev because Irev is not in the PD spec, I suggest to tell the PD that he need to be aware of Irev when he sets the value of the PD MPS in order to achieve the PD goals.

Yair

From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
Sent: Wednesday, June 13, 2018 6:21 PM
To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>; STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Hi Yair,

In clause 33, we did not tell the PD designer about Ihold. Why is this different?

Thanks,

Chris

From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Sent: Wednesday, June 13, 2018 8:39 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Hi George,

I am not necessarily suggesting new values or more informative information etc. This is not my intention. You are welcome to offer simpler text.

I can’t agree to leave this as is. Again, the problem is:

If PD vendors don’t read PSE section, how they can be aware of Irev in 3-pair mode which is in the PSE section and affect the MPS on the PD section?

Before we wavered on backffed requirements in 3-pair mode i.e. backfeed was required to be met and all PSE voltage range, we had never this situation before that meeting the PD spec depends on PSE spec. This situation will be a source of interoperability issues and I am trying to resolve it at ZERO cost/issues for the ideal diode bridges in the field (instead of asking again to disallow new Type 3 and 4 PDs from having backfeed issues in power on state).

Without adding some hint/link/text to the PSE Irev in PD MPS clause, we will mislead the PD designer.

Please note that my proposed approach was the normal approach we took in similar cases. This is no different than the other cases.

Yair

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, June 12, 2018 9:56 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Yair – all of these values are tutorial in nature. There are no requirements in your proposed text, therefore they are completely advisory.

We write standards – the important thing to capture is what is required. The information may be valuable to implementers, I don’t argue that. However, publish that elsewhere (for example, in an EA whitepaper) if you so desire.

George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications

1-310-920-3860

george@xxxxxxxxxxxxxxxxxxxx

From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Sent: Tuesday, June 12, 2018 11:23 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

Hi George,

The value of the proposed text is much higher that you have described see why:

The issue is:

-PD operates in 3-pair mode with ideal diode bridge that has the backfeed issue. This means that whatever load is in the unpowered PSE alternative, it is reflected to the PD load and added up.

-PD wants to be powered off. As a result it sets its MPS to 3.9mA which means must be OFF. PD vendor may not be aware of the Irev spec since it is in the PSE spec.

-Now in this condition Irev=1.3mA will be added from the PSE to the PD MPS i.e. 3.9mA+1.3mA=5.2mA and PD will not be disconnected.

This is the problem.

The solution is that the PD vendor will take the 1.3mA in account of the MPS setting.

The problem is that the PD vendor is not aware of Irev since this is the PSE spec and many times as a response to comment we agree to add text to PD section to tell PD about parameters that affects the PD but appear in the PSE i.e. we said that the PD vendor get a PD spec and start to design without looking on PSE spec or aware of it which I believe it is a correct scenario.

By the way, during last meeting we change the PSE and PD spec to address similar issues concerning to the effect of Irev on other spec items and this is one of them.

I can never agree to a situation that you have a clear requirement in a PD for what to do regarding MPS (or other spec items) without telling the PD vendor that there is something waiting for him in the corner… in the PSE spec that is not mentioned in the PD spec that can make his PD uncompliant. I don’t see a reason to hide such critical information.

Yair

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, June 12, 2018 8:36 PM
To: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Cc: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Yair - the proposed text is purely advisory and informative. At this stage we should only be concerned with missing or incorrect requirements or correcting (preferably deleting) incorrect information. I just don’t see the point of adding more informative advice to the standard.

George A. Zimmerman, Ph.D.

CME Consulting, Inc.

Experts in PHYsical Layer Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

On Jun 12, 2018, at 10:27 AM, Yair Darshan <YDarshan@xxxxxxxxxxxxx> wrote:

Hi Lennart,

I agree that it doesn’t affect the case when the PD is disconnected from the cable.

I was referring to the case that the PD is connected and wants power removal. The question if it is rare or not, is irrelevant since it is already in the spec and we need to address it somehow and meet it.

I agree that the solution can be that PDs that do want to have power removed can set their Iport_mps value for power removal to be lower than (4mA-1.3mA)=2.7mA. However, in order to make this clear to the PD vendor (since Irev is in the PSE section) I believe that we need to add text to the PD MPS section as follows (or equivalent):

Proposed remedy:

Add the following text in clause 145.3.9, page 222 text after line 49:

"When a PD is operating under 3-pair mode conditions, the value of IPort_MPS as seen by the PSE over the powered pair may increase by Irev (See 145.2.10.4, 145.3.8.8 ). As a result, the PD may need to set IPort_MPS to alower value than IPort_MPS min to ensure power removal."

Yair

From: Lennart Yseboodt [mailto:00000b30a2081bcd-dmarc-request@xxxxxxxx]
Sent: Tuesday, June 12, 2018 12:04 AM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] MPS issue due to the allowance for reflected voltage in 3-pair mode

EXTERNAL EMAIL

Hi Yair,

Your analysis is correct, the reverse current is added to the PDs own current.

I don't consider this an issue we need to do anything about however:

- it does not impair the primary function of MPS in any way (to remove power when the PD is disconnected)

- it only affects PDs that use the method of removing MPS in order to have the PSE remove power, I would say this is pretty rare;

- PDs that do want to have power removed can accommodate for the maximum 1.3mA of reverse current (draw less than 2.7mA of their own)

Note that reverse current only happens under 3-pair conditions, and then the 'must disconnect' current level is 4mA for PSEs.

Kind regards,

Lennart

On Mon, 2018-06-11 at 12:03 +0000, Yair Darshan wrote:

Hi all,

I found new problem that we need to discuss how to handle it.

In 3-pair mode during power on state, when a PD don’t want to be powered, it generates e.g. MPS=1.9mA which means PSE must disconnect, but due to the PD that doesn’t meet the backfeed on the unpowered pair, the unpowered pair consumes additional 1.3mA and this is added to the MPS. Under these conditions, the PD will not be disconnected.

Moreover, in general, a constant error of additional MPS current is added by the PSE…..instead of PD only should control the MPS current.

Let’s start to discuss this.

Yair

Darshan Yair

Chief R&D Engineer

Analog Mixed Signal Group

Microsemi Corporation

1 Hanagar St., P.O. Box 7220
Neve Ne'eman Industrial Zone
Hod Hasharon 45421, Israel
Tel: +972-9-775-5100, EXT 210.

Cell: +972-54-4893019
Fax: +972-9-775-5111

E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>.

To unsubscribe from the STDS-802-3-4PPOE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1

To unsubscribe from the STDS-802-3-4PPOE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1