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

Re: [802.3_4PPOE] POWER_DENIED



Dan – you seem to have pushed send just as I was about to say the same thing.

I agree – NOT A FAULT.

However, it is neither “Searching” nor “Delivering Power” either.  Does it make too much of a mess to leave “POWER_DENIED” as a separate state?  As it was pointed out, power budgeting is a natural consequence of the fact that Clause 33 is written as though PSE’s independently power ports.  They don’t.  They are parts of multiport devices which need to budget power supply and other resources – hence it is perfectly natural to allow a PSE to deny power without any fault, and I can even envision it turning power OFF after being applied, perhaps either due to (centrally controlled) green energy management or even due to prioritization of ports for powering (some PDs are more equal than others…).  We are not to decide what the market might consider useful, people can, will, do and have (I’m sure) come up with all kinds of ways to exploit this feature.

 

George Zimmerman

Principal, CME Consulting

Experts in Advanced PHYsical Communications Technology

george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

310-920-3860

 

(PLEASE NOTE NEW EMAIL ADDRESS.  THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS)

 

From: Dan Dove [mailto:dan.dove@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 11, 2015 4:14 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] POWER_DENIED

 

Hi All,

I'm glad I stirred up the discussion a little.

My own view is that POWER_DENIED is not a fault but a normal operating mode in the case where pd_requested_power > pse_available_power.

But the text says that this state is entered in the case of a fault and is ambiguous as to what exactly constitutes the fault.

I tend to believe that two entry points (where power is unavailable and not turned on) is not a fault-like condition, but the one where power has been applied and then is turned off, that seems like a fault condition.

Perhaps the best way to address this is to keep it outside of the Fault and Delivering Power blocks as a stand-alone state?

Give me another day or so and I should be able to post the proposed state diagrams. They will be preliminary and subject to review/change/etc.

Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - Mobile

On 2/11/15 3:25 PM, Bruce Nordman wrote:

I can foresee two situations:

* The PD asks for power, but not enough is available so is denied.

  It can come back and ask for a lower power level and maybe get

  an OK.

* The PD is being powered, but the PSE wants to cut it back - possibly

  to (near) zero, or possibly just something lower.  Would be nice if

  there could be some period of negotiating to a lower level that would

  not require passing through zero.

--Bruce

 

On Wed, Feb 11, 2015 at 3:17 PM, Dave Dwelley <ddwelley@xxxxxxxxxx> wrote:

This makes sense to me: no fault. But - should it be in Delivering Power (which isn't accurate), or in Searching? I'd vote Searching.

 

Dave

 

On Wed, Feb 11, 2015 at 2:47 PM, Leonard Stencel <Leonard.Stencel@xxxxxxxxxx> wrote:

“Is not a fault”

 

From: Chad Jones (cmjones) [mailto:cmjones@xxxxxxxxx]
Sent: Wednesday, February 11, 2015 1:39 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] POWER_DENIED

 

I would also agree with Bruce that a PSE denying power to a port is not necessarily a fault condition. If there was a PD fault then the PSE would not be granting power. The PSE choosing to not provide power is a system decision that is likely not a fault at all. 

 

I would suggest that you assume that POWER_DENIED is NOT a fault in the interest of expedience. I’d rather have you do it once than twice. 

 

I would like to hear more opinions as this is a group decision. Please respond to this thread with a simple “IS A FAULT” or “IS NOT A FAULT” and we can do an informal (and certainly not binding) ‘opinion of the reflector' poll.

 

Chad Jones

MGR, HW ENG, Cisco Systems

Chair, IEEE P802.3bt 4PPoE Task Force

 

 

From: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Organization: Dove Networking Solutions
Reply-To: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Date: Wednesday, February 11, 2015 at 3:26 PM
To: 4PPOE Reflector <STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_4PPOE] POWER_DENIED

 

Hi Bruce,

Agreed. I think your point below is exactly the logic and reasoning most people will have.

The question I pose, is that if you go to a candy machine with due number of coins, and it doesn't have the choice you want, do you consider that a fault?

If you are a candy machine mechanic, no..you just order a restock for it. If you are a customer, you go back to the conference room and tell everyone "that *#(! candy machine doesn't have my candy!" and while it may be the candy-stocker's fault, its clearly a fault in their eyes.

All humor aside, the language in the text is ambiguous and we probably want to straighten it out. Fixing the state diagram will be relatively easy once we hash through the text. Its only a question of which hierarchical block the state resides within the diagram.

Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - Mobile

On 2/11/15 11:16 AM, Bruce Nordman wrote:

I am not literate in the uses/implications/etc. of the state
diagrams, and recognize that.

That said, I don't see a PSE denying or removing power
from a PD as necessarily a "Fault" in the sense of failure,

particularly as a PD may be dealing with more potential
power demand from devices than the PSE has the capacity for.

As an imperfect analogy, this seems to me like a vending
machine that could be broken (so a fault) and not able to
deliver candy bars -- or one that is simply out of the kind
you want (so also unable to deliver, but not a fault in the
sense of equipment failure).

Whether this should change how the state diagrams are
constructed or labeled, I can't say.  Thanks,

--Bruce

 

On Wed, Feb 11, 2015 at 10:39 AM, Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx> wrote:

Hi All,

In my work related to cleaning up the PSE state diagram as initiated at our last meeting, a drawing was put together by Dave Dwelley as a first stab of how one might break down the PSE diagram.

In this, (attached), the state "POWER_DENIED" was included in the "Delivering Power" group. As I proceeded on my task, I noted that POWER_DENIED could be considered a "Fault" condition depending on how you read the text.

I looked at the text and found the following;

33.5.1.2.4 Power Denied or Removed (12.12)
When read as a one, bit 12.12 indicates that power has been denied or has been removed due to a fault
condition. This bit shall be set to one when the PSE state diagram (Figure 33–9) enters the states
‘POWER_DENIED’ or ‘ERROR_DELAY.’ The Power Denied bit shall be implemented with latching high
behavior as defined in 33.5.1.

So it occurs to me that the text is somewhat ambiguous. If you read it "{has been denied or has been removed} due to a fault condition"... you read the condition as a fault for either. If you read it "has been denied or {has been removed due to a fault condition}, then denial is not considered a fault, but removal due to a fault condition is a fault.

So, in order to move forward, I am going to consider the former for the basis of my effort. I will presume that denial of power is a "self-imposed fault" to advance this effort. If, due to consideration of the Task Force, its decided that this state should not be within the Fault group, it will be relatively easy to redraw things.

Feedback appreciated. In the last meeting, we discussed using the reflector for this purpose, hence, I'm reflecting on this issue.

Regards,

--
Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - Mobile




--

Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@xxxxxxx
510-486-7089
m: 510-501-7943

 

 




--

Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@xxxxxxx
510-486-7089
m: 510-501-7943