Conference netcad::hub_mgnt

1372.0. "Field input. Things required to make us competitive." by NACAD::GALLAGHER () Fri Sep 02 1994 14:12

---- Many forwarding headers removed.  ----
---- Posted with permission from the author. ----

Date: Wed, 31 Aug 1994 19:18:52 -0400
From: [email protected] (Mark Jay Harris, Sales, DTN 521-4013)
To:   [email protected] (Bill Hawe)
Subject: Mark Harris, Comments. Part 1 of 2

    Jeff Low stated recently that engineering was VERY open to listen to
    input from the field, so here's my list of comments on our products or
    products 'holes' -- things are are required to make us competitive in
    today's market.
    
    We all know that we make alot of really exciting products. We don't
    need to pat each other on the back right now -- we need to transform each
    and every dollar we spend on R&D to maximuize the revenue to be seen
    from THAT dollar.

    Anyone else care to add to this, feel free. The list is in approximate
    categories, but...
    
    regards, Mark Harris
__________________________________________________________________________

Price/Promotion:
================
    1. Magazine and consultant coverage is all but missing and/or negative.
    There are very few times in which Digital's Networking products are
    spoken about at all or compared against other similar products in
    'industry roundups' and other published comparison charts. Ironically,
    this is in the same publications and with the same consultants that
    Digital is paying for advertisements or other consulting services.
    Digital's Networking supplier image and product Promotion is suffering.
    The only glimmer is the 'Purple/Green Chameleon' ad and that doesn't
    seem to support any real vision or purpose-- but it does bring to mind
    the TCPIP offering from NetManage Corporation who calls their product
    "Chameleon"...

    2. Digital's pricing policies are not competitive with street pricing for
    comparable products in the market. Over the past 6 months, it has
    become  the rule rather than the exception to have to go to great
    lengths to make our end-users' cost competitive. Our products should
    stand at their given pricing in such a way that our channel partners
    can sell them quickly and easily and assure themselves of a good
    margin. This affects the desire of our partners to sell our hubs rather
    than the competitions'. It should be no harder for them to make 'x'
    dollars (or percent profit) with our products versus Synoptics or 3COM's.
    A good example is manageable 10baseT ports. Digital DECrepeaters will
    cost $85 per port after normal discounts, while the competition will
    sell theirs at $65 per port - a 30% difference!

Management:
===========
    3. Hubwatch is the SINGLE largest reason for losing DEChub 90/900 sales.
    We are in a very poor position today and apparently through the
    remainder of this calendar year- if not longer. There is NO mechanism
    today to sell our Hubs with a clear management tool that maps to our
    end-users the way THEY think; Their Sites, buildings and finally hubs.
    We offer no 'drill-down' iconic mapping- the #1 asked for feature and
    the  piece that loses the sale of the hub a great number of times (It
    even drops us out of the running in many cases BEFORE our foot is even
    in the door!).
    Polycenter/Netview integration seems to have been Digital's 'answer'
    when product management was asked for the past year, but
    Polycenter/Netview is both expensive and still NOT available or
    integrated with HUBwatch on any common platform. Even the fabled
    'HUBwatch for Openview' seems to be out in the distant future. It
    should be in each network sales person's pocket TODAY. Bottom line is
    we need a $2500 or less tool with iconic mapping and drill-down to the
    actual hubs, routers and probes in the network.

    4. Channelworks is sold without any management tool available from
    Digital. To many customers, it's crazy to have to deal with Digital for
    the hardware and someone else for the software. Our channel partners
    and/or NIS/MCS are the obvious solution, but neither has
    whole-heartedly jumped on the  Channelworks bandwagon.

    5. Novell NMS port for Hubwatch? There is a great ground swelling for this 
    management platform for Hubs. Even Synoptics has ported their
    management tool to NMS/Optivity due to the shear market share. Novell
    NMS port?

    6. Terminal Servers do not provide IP services for management, nor do they
    cleanly play into the DEChub management scheme (No auto-detect, MAC
    addresses need to be manually entered). The fact that these product 
    were engineered by two different groups is no excuse. ANY module that
    can plug into the DEChub900 should be fully management aware- it
    should provide IP services and auto-MAC identification. (For example,
    in a large  corporation, if a DECserver900 were swapped due to
    maintenance or additions  the network manager would have to be called
    by telephone and given the MAC  address for the new module before the
    manager would be able to 'see' or  manage it. This is not a perfect
    world... not even close.)

    7. DEChub900 slot architecture is closed. We did it with the UniBus,
    BI-Bus  and LAT. IBM did it with the Micro-Channel and APPN. Anytime we
    use protectionism tactics as our differentiator, it fails in the
    industry. There are too many choices which are more open. We need to
    make the SPEC  open so that ANYONE can build product, and then we need
    to strive to make THE BEST modules so that others won't get our
    business. If we fail to make the best module and someone else has it,
    at least we get DEChub900 backplanes and potentials for future Digital
    business. If we lose the  backplane and management architecture, we
    lose the account for a very long time.
	(See my follow-up memo regarding DEChub900 Slot Openness)

WAN:
====
    8. Lack of Dial-on-Demand. I have been asking for well over a year when 
    Digital would be getting serious about Dial-On-Demand routers. Now that 
    dial-up modems can easily run at 28.8K (with a $350 modem), Dial-Up
    routing  is becoming more essential. The Branch-Office model is rolling
    out full-steam ahead in all of our customers. This branch-Office model
    needs dial-up  routing. Products like Rockwell's NetHopper, NEC's Dr.
    BonD and Shiva's Net /LANrover products all do this quite well. As of
    last week, Digital was apparently not even looking at this technology.
    We need a dial-on-demand  router that works well with desktop
    protocols, (i.e. IP, IPX, AFP, NetBuei,  etc.)

    9. Lack of WAN sync-link compression of any type. In concert with the
    above  need for more cost-effective Branch-Office connections, WAN
    compression is  becoming more important. Each one of our customers is
    trying to REDUCE their costs for leased lines. Each would like to send
    more data across longer distances. Their are many 3rd parties that
    sell products that simply  add compression to Synchronous data-streams.
    They work quite well. Datamiser and MicroCom come to mind as having
    leading products which do this. I could envision having the code
    built-into our router which would  negotiate with the router at the
    other end of a link for compression. I realize this follows no
    'standard', but I'd like to see the same type of  strategy that we used
    with ATM FlowMaster and Full-Duplex FDDI (i.e. the  feature is
    available in a DEC-only environment due to lack of standards,  but
    falls back to 'THE STANDARD' if working in a multi-vendor environment,
    *AND* we'll implement the 'STANDARD' in a firmware upgrade if/when it
    happens).

    10. Inconsistancy of Router/Brouter management tool. Do we use TELNET or
    NCL or  NCP or a GUI front end? We need one approach that works with
    the  DECbridge900MX, DECbrouter90, WANrouter90, DECnis, etc, etc...

LAN:
====
    11. 100BaseT (CSMA/CD) NICs will be late. Most consultants are already 
    supporting the theme that VG-AnyLAN is dead, BUT, only if the 100BaseT
    (CSMA/CD) vendors get product to market quickly. Digital can remain
    'on the  fence' if we like, BUT we need to show our efforts (or
    multiple efforts- just show something being done!) and talk
    about them THIS FALL! The Hudson chip group produced a proto 100BaseT NIC
    adapter and it was  buried at the Comdex show in Las Vegas several
    months ago. Nobody has seen nor heard of ANY products that do ANY
    flavor of 100mbps ethernet since from Digital.

    12. DEChub900 power/backplane constraints force "configuration rules" when
    using newer modules (i.e. more than 5 DECbridge900MX). There are
    several modules that demand higher power requirments. This forces
    rules, which the lack of has been one of the DEChub900 biggest
    differentiators. We need a more robust power/backplane so that we
    can minimize this issue over time?

    13. Multiport, assignable DECpacketprobe900 (any flex channel). Management
    tool is needed to monitor all ports. Can we build RMON into the
    repeaters or create an inexpensive flex-channel assignable
    Packetprobe?

    14. Etherworks III controllers. We're down to 1 chip and yet we still
    have problems with price, performance, delivery and driver support.
    I had even begun to think there was no room for differentiation these
    days and then I see ads for new boards from 3COM and Farrallon and they
    boast ZERO MEMORY requirments in DOS/Windows, Parallel-Tasking for high
    performance, and get this: Daisy chaining of 10baseT WITHOUT breaking
    the repeater rule! (slick). One note: the 3COM chipset seems to be a
    fairly well recognized market leader and IS available for OEM'ing.
    This is ONE approach to gain a bit of leadership- use the leader's
    chipset and then there is little question about the robustness of the
    NIC technology.
    

    I am shocked that there has been no reply to the base note since last
    September. Anyway one must not stop trying, so here goes:
    
    What I NEED, NOW!
    
    1.	I need a DEChub 900MS that does not impose 6 Ethernet channel
    limit. Any idea how ridiculous we sound when we have to raise that up,
    right after we talk about the 2.3GBps backplane?
    
    2.	I need a 2-port DAS FDDI bridge (call it a switch, whatever), it'll
    be nice if it also have some Ethernet ports on it. There is a huge gap
    we're forcing the customer to jump when he needs more than 1 FDDI ring,
    but not a GIGAswitch.
    
    3.	8-slots is too many, we need a backplane with 4-slots to cover the
    low-end. Very often customer prefer a dual hub config for
    high-availability, but didn't need two  8-slot hubs.
    
    4.	Someone needs to explain, very compellingly, why the DEChub 900MS
    power supply is priced so high.
    
    5.	Our international uplift needs to be fixed. Country list prices are
    way out of line with MLP. For example, the EISA/FDDI adapter is US$895,
    but list in Singapore for S$1752! The exhange rate today is only S$1.40
    to a US$.
    
    Phew! That's about it for a while. Sorry I might have sounded to harsh.
    But I had a bad day with 3Com LANplex competition :(

    
    You are absolutely right. I've said the exact same things to product
    management for months. I'd be doing the same at the Americas NPB Sales
    meeting in San Francisco on July 17. 
    
    I don't know if I agree with the 4 slot hub however. I think there is
    enough redundancy with power in this one and the MAMs don't seem to
    fail that often. What specifically are you looking for when you are
    saying redundancy? I'd like to hear this since my opinion is different
    than yours.
    
    In regard to pricing, I believe that's handled on a per country basis.
    I don't think the US sets that, country management does. What's been
    ther response on pricing from your country management?