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

RE: Signal vs. Idle debate (was: Here's a new idea)


I too will answer concisely below

At 10:28 AM 5/8/2000 -0700, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>(Hi All, I am re-sending this with the comments )
>(clearly identified.. my previous response to the)
>(HTML format did not come out readable. Sorry )
>( Dan Dove )
>Mr. Polk,
>I will try to address your points consisely.
>>  -----Original Message-----
>>  From: James M. Polk [mailto:jmpolk@xxxxxxxxx]
>>  Sent: Friday, May 05, 2000 11:20 AM
>>  To: DOVE,DANIEL J (HP-Roseville,ex1); stds-802-3-pwrviamdi@xxxxxxxx
>>  Subject: RE: Signal vs. Idle debate (was: Here's a new idea)
>>  Dan (and all)
>>  Comments inserted
>>  At 03:39 PM 5/4/2000 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>>  >
>>  >Hi Norman,
>>  >
>>  >I have a few issues with the direction you are taking the
>>  >discussion so far. Let me explain.
>>  >
>>  >>  If the market is growing very rapidly, then existing owners
>>  >>  of (what will soon
>>  >>  be) absurdly bulky and expensive switches will be small
>>  >>  fraction of the total
>>  >>  Ethernet market, and catering to those old switches with
>>  >>  add-on boxes to
>>  >>  supply power will be a niche market. 
>>  >
>>  >On the other hand, we are in the business of selling products
>>  >today to solve problems, not create them. There are plenty of
>>  >switches being sold today that support VoIP but don't supply
>>  >power because there is no standard for it. Are these boxes
>>  >"old, absurdly bulky or expensive"? I don't think so. Some of
>>  >them are highly integrated and very cost effective. I could
>>  >give you examples but I think you know I am right.
>>  Dan -- let's get a little realistic, here. We're not merely
>>  talking about
>>  software to be downloaded to existing equipment to take
>>  advantage of this
>>  new capability. DTE power means that customer has embraced a
>>  new technology.
>>  That means new equipment to buy (in this case). Period. That
>>  is a fact. 
>OK. A customer can buy an HP4000 today that does not provide
>power but supports VoIP. They can buy a power-insertion patch
>panel (when the standard is defined) and a phone, and they are
>now fully operational without ripping out their switch. Is that
>clear? This model works for many other switches that are in
>the installed
>base today.

I'll bet that powered patch panel cost more than that switch, or at least very close if with a high density of ports on both

>>   Devices that expect power on either pair are just being
>>  built -- therefore
>>  just bought -- therefore nothing is old or existing
>>  regarding this coming
>>  Standard. If the switch manufacturers cannot build a new
>>  switch module with
>>  power on that module -- shame on them. 
>The question is not "IF they can do it", it is "should they be
>forced to do it"? The committee decision to require mid-span
>support says "no".

I'm not stating that the powered patch panel be dropped. Sorry I you read my emails that way.

>>   Companies are already doing it and those that don't won't
>>  sell too much
>>  product. Period. This is a fact.
>I disagree. I believe that those who apply power at the switch are
>burdening the cost of the switch for a limited number of
>applications. Those who rely on a patch panel power distributor  are
>actually allowing the customer to determine which ports to provide power to
>and keeping their switch investment optimized.
>Isn't this element of the debate moot? The committee has already decided
>that mid-span insertion is a "must".

Point above -- powered patch panels should be specified.

Question though, in the Telecom closet that your office or cube gets Ethernet connectivity from.... how much room is there for an additional co-located Powered Patch panel? It could end up needing to be one for one ports to the number of desktop computers you have in your facility. Do you at HP have rack space for all those patch panels....

I honestly don't know your situation.... I just know a lot of Cisco customer situations (which are rather numerous)

If it's from the switch that is built of the same size -- rack space isn't an additional *very real* burden on those customers.

>>  As a point of reference towards past work the IEEE did: 802.1p/q made
>>  everyone purchase new Ethernet switches because no one had
>>  built their
>>  existing Switches with the ASIC capable of those additional
>>  bytes to the
>>  Ethernet Header. This too is a fact. Period.
>But people ARE providing VoIP capability in their current products and their
>customers should be able to take advantage of that capability at the least

Again -- I'll bet the product your company builds will likely cost in the low 5 figures minimum -- especially if the port count approaches more than 75 ports. Is that considered least cost? I'm not sure either -- but I'm leaning towards that not being too cost effective; plus with the additional cost of out of band management (cause it cannot be in-band) and the limited amount of rack space.....

>>  So your argument that the IEEE should (basically) only ever
>>  adopt what
>>  doesn't impact the existing installed base is a fairly foolish
>>  justification, IMO. And as far as cost of implementation is
>>  concerned --
>>  this one cost customers a lot. Now -- I'm personally glad
>>  the IEEE did do
>>  this work, there are great benefits to it.
>Pardon my foolish concern for my customers, I guess we will
>have to disagree about their best interests. I recommend that you
>have a nice cup of tea and relax. We can debate this matter without getting
>to the point of calling each other foolish or unrealistic.

Dan, perhaps I shouldn't have stated it in that way. I should have only implied it

>>  Back to this topic, what will be engineered is power into
>>  existing Ethernet
>>  Switching Chassis with new modules purchased by that new technology
>>  customer.
>I have no dispute with those who wish to offer that as a solution. I am
>arguing that we should not impair the data pairs for 10/100T or REQUIRE the
>customers to toss out their very efficient and cost-effective VoIP capable
>switches. Standards should be designed to provide flexibility for the
>>  I haven't done the numbers -- but for those that have a
>>  small fixed Ethernet
>>  Switch in a closet (<50 ports) -- I'd be surprised if building a cost
>>  effective external 'mid-span' power insertion device for
>>  those installations
>>  were the norm, not the exception. Companies will build new
>>  'stackable' or
>>  'fixed' or 'non-modular' chassis that will supply DTE power.
>>  If you don't
>>  believe that's true -- wait and see. I'll bet there will be many many
>>  offerings by many vendors by the time this 'Standard' is ratified.
>If you wish to perform the numbers regarding the justification
>for mid-span versus switch-based power insertion, I would be
>very happy to review and comment on your presentation.

That's competitive info and you know if -- so I'll pass.

>>  >>  Whether we choose the data pair or the
>>  >>  spare pair should be conditioned more on 1) the total cost
>>  >>  to the buyer of
>>  >>  equipment designed with DTE power in mind, and
>>  >
>>  >As a standards committee member, I would put "must support the
>>  >installed base of equipment without interference" as a higher
>>  >priority than cost. The cost of ripping out existing gear is
>>  >substantial. But what I have to say is less relevant than the
>>  >decision by the committee to require compatibility with 10/100T.
>>  Again, explain 802.1p/q mentioned above
>But it does not apply in this case because there is a very large installed
>base of VoIP product in the market.
>>  >> 2) on the
>>  >>  needs of 1G and
>>  >>  faster links, than on the cost of existing installations.
>>  >
>>  >Again, the committee has clearly expressed that 10/100T is a
>>  >higher priority than 1000T. Unlike 10/100T, the Gigabit stuff
>>  >today actually operates very robustly. Much of the 10/100T
>>  >installed base has been built with less-than-ideal performance
>>  >but customers want to use it. If you have a PC with an older 100T
>>  >NIC installed, do you want its performance to be impacted by the
>>  >addition of mid-span patch panels that are designed to inject
>>  >power on PDTEs?
>>  I guess I don't understand why a PC would be connected to a Mid-Span
>>  powering device and expecting power --- wouldn't that
>>  blow-up that older
>>  NIC? I sure think that NIC couldn't handle -48Vdc on either
>>  pair.... but I
>>  could be wrong.
>That older NIC would likely fail the "assert power" test, and would
>therefore not have power asserted, but might not operate reliably due to
>Return Loss and Insertion Loss impacts on the data pairs if they were used
>to insert power. If you wish to understand this point more clearly, I
>recommend that you review the numerous presentations already given to the
>committee. They clearly explain it.
>>   In the case of the "spare pairs" no impact would
>>  >exist. Sure, future 1000T products would have to deal with power
>>  >injection on their outside pairs, but 1000T is better equipped
>>  >to do so with echo cancellers, FEC, and DSP capabilities.
>>  >
>>  >>  (Note that this
>>  >>  argument says that the woes of existing 4-wire installations
>>  >>  is relatively
>>  >>  unimportant.)  In other words, I think that powering 1G is
>>  >>  more important
>>  >>  in the long term than cheaply adding on to 10M ports'
>>  capabilities.
>>  >
>>  >Unfortunately, that is not the direction that the committee has
>>  >already committed to. Support for 1000T should not be demanded at
>>  >the expense of either reliable or inexpensive 10/100T operation.
>>  > 
>>  >>  -- Norm
>>  >
>>  >Best Regards,
>>  >
>>  >Dan Dove
>>  >HP ProCurve Networks 
>>  >
>>  *************************************
>>  "At the end of the day... the most committed win!"
>>   James M. Polk
>>  Sr. Product Manager, Multiservice Architecture and Standards
>>  Enterprise Voice Business Unit
>>  Cisco Systems
>>  Dallas, Texas
>>  w) 972.813.5208
>>  f)  972.813.5280
>> <>  
>Best Regards,
>Dan Dove
>HP ProCurve Networks
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280