Conference netcad::hub_mgnt

    Hi John read note 1511 for more information on the experiences
    and references to other notes conferences where the raw ipx thing
    is discussed. In a pure Novell shop it probably works fine, but
    in a mixed vendor network, it spells nothing but trouble, and
    should be avoided if possible.
    
    Bob

    Been there, seen it, done it.
    
    Didn't think about ramifications though before suggesting it.  However,
    could it be made a MENU option on the setup port so you dind't have to
    get into hubwatch and all that just to tweak the one feature?  
    
    At the moment, because I've not figured out how to setup an ODI
    driver...aarugh...I have a customer that got their equipment set up
    only because I brought in my PC to do it.  Setting up HUBWATCH for an
    OEM environment is a pain.
    
    (i.e. we have a vendor who wants to use our DECswitch in their product
    as a native Novell environment and it is a PAIN for them to setup/use
    HUBWATCH just to use the switch as a stand alone component.  U c?
    
    Whatcha think?
    
    j
    

    Hi John - I've extracted your suggestion from here and will
    pass it on to the wave-3 switch/bridge team for consideration.
    
    Bob

    Raw 802.3 is not guaranteed to work in an extended LAN consisting of
    both FDDI and Ethernet.  Reason we don't want to have it be the
    DEFAULT is because it messes up the customers who use
    Ethernetv2 encapsulation, which IS guaranteed to work in any
    configuration.  (The basic problem is that there is no such thing as
    "raw FDDI" -- however there is a standard way to translate the Ethernet
    packet to FDDI format).
    
    The reason why it's not in the setup menu is because this menu is
    intended only for the initial setup and not for configuring the box
    (eg - to give it an IP address so you can manage it).  If we put in odds
    and ends for various customers then we'd end up putting everything that
    can be done by SNMP in the menu, and then it would no longer be a
    setup menu but a "console" -- and that is a LOT of work.  Instead
    we decided to make HUBwatch on PC's very affordable.
    
    Anil

    I should add, there is a way around HUBwatch -- you can use any SNMP
    management station (or SNMP freeware that runs on workstations/PC's)
    to set "esysIPXSwitch" in the DEC Vendor MIB to "true".
    
    Anil

    You're missing the point though.  In an all-Novell default V3
    environment (there are a *LOT* of them out there) it adds complexity.
    THere are out-of-the-box vendors who play in Novell WITHOUT any special
    set-up.  (i.e. Networth for example).  
    
    The OEM who I'm dealing with wants to plug in a box and go.  They
    provide color lab systems which have NOTHING to do with network
    management.  Having to set-up HUBWATCH places us at a disadvantage
    because they can get other 3rd party stuff that will do FDDI/Ethernet
    with LESS HASSLE than us.  
    
    So, for folks who are OEM or Novell shops, who don't muck with SNMP who
    just want to plug stuff in and go; it's a MAJOR pain and cost.  
    
    Bottom line - go to a Novell show and you'll see - LOTS of stuff that
    is plug-and-play with Novell.  Please consider this option because it
    SPECIFICALLY addresses the Novell environment.
    
    u c?
    j
    

    Anil - also one other note - a few months back about $300k of DEChub
    stuff ALMOST was returned because of the difficulty, and lack of
    understanding, of the Novell problem at an installation that was being
    done by Pioneer.  Thanks to quick help from Gee Ng we were able to find
    Shou Lee and get it resolved.
    
    But again - the fact that a Novell customer could buy this switch and
    then find out that 'oh I need to configure/setup HUBWATCH/managmenet
    etc' to use it...*WILL* cause them to send it back.
    
    It is a VERY DIFFERENT mindset - ESPECIALLY, as I said, when folks can
    by other off-the-shelf products that do NOT require added tinkering and
    $500 extra management software to turn on!
    
    HELP!
    j
    

    
    You're missing the essential point that lead to the choice of default:
    
       The NOVELL RAW mode is broken and in violation of all the
       relevant standards, and even Novell admits it and recomends
       that users not use it.
    
    If we make it the default, then people who really know what they are
    doing will have to configure the box to do the _right_ thing.
    
    Granted, all this places some extra burden on the field to understand
    the issue and head it off.

    No, I do not think that we should make it the default.
    
    However we should make it easier to change.
    
    *YOU* may want to go out and tell a Novell shop that's running fat,
    dumb and happy at V3.x that they're wrong.  However there has to be a
    COMPELLING $ and � reason for the shop to change.
    
    Novell made a big boo-boo.  However MANY folks out there simply don't
    care. We need to make it EASY for them to live with their environment
    without needing to install/configure other SW packages. )i.e. HUBWATCH
    
    For example, when I mentioned this to the shop that I installed it in
    their reaction was:
     a.) I took the Novell defaults
     b.) It works
     c.) Changing would mean downtime for me and my LAN consultant would
         cost me $
     d.) My OEM to others is not going to interface with other LANS
     e.) The only reason that you'd want me to change is to use your
         (Digital) equipment
     f.) I can use another vendor
    
    We nearly killed $300K worth of product because this was SO painful to
    do.  If we don't need the $300k but do need to be right...well...we can
    be right and be out of business.  Somewhere in the middle ground lays
    the compromise of making this EASIER for folks to do WITHOUT installing
    HUBWATCH.
    
    There are a FEW Novell V3 LANS out there ya know.....just a few.
    
    When are we going to learn to do what the CUSTOMER wants and LEAD them
    to what is right....it doesn't work the other way around...!
    j
    

    One other note - the Gigaswitch does not handle this well - except with
    a firmware upgrade.  A 3rd party installed one into an insurance
    company - it took A MONTH to get it working.  It got working because I
    got out of a meeting, jumped on a plane, flew there, (NDU would NOT
    upgrade it), mailed it back to the NPSS folks, had them upgrade the
    firmware and then reinstall it.
    
    It worked.
    
    However, the PEOPLE time in fixing this $*@*#&@U#*)@*#)(*@#)(@ thing
    was way over 6 weeks. (I'll mail you the post-mortem offline).
    
    No, Midland Insurance will NOT convert their 400 PCs because they WORK. 
    The Gigaswitch didn't work and, if it didn't work in THEIR environment
    we lose $50k of revenue.
    
    So far I've given you $350K of examples in revenue where this is
    important.  Do you need more?
    
    j

    Question John - Does the Novell shop you refer to, (or the others that 
    you have visited), use other network manegement tools (other than
    HUBwatch)? If so do any of these other network mgnt tools use SNMP?
    Perhaps giving us a broad-stroked picture of some of these sites
    and what percentage of your total accounts are similar might help
    paint a better picture of the significance of your expressed concerns.
    
    Bob

    Bob - the Novell shop that I visited was an OEM who processes color
    photos on PCs, does ads, etc.  They want to migrate to high performance
    LAN technology because of the bits on the wire that they pass during
    picture processing.
    
    So, they hoped to just plunk down a DECswithc 900EF and a
    DECconcentrator 900MX and begin migrating some stations to FDDI.  They
    decided to use a DEC FDDI card in the Novell server because of the
    possibilities of doing full-duplex FDDI.
    
    I believe that they will have one main server and about 12 PCs or so. 
    They have no network management software nor other protocols than
    Novell.
    
    So, they were a bit put off when they learned that to use our product
    they would have to install network management software.
    
    They could use a NETworth box that would offer a combination FDDI
    concentrator, multiport Ethernet bridge and FDDI ring in a box with NO
    need for network management.  
    
    They're only using us because they like the Digital name, not because
    it's easy to use.  If it was a flat out contest - Networth would win.
    
    Because of the COMPLEXITY and COST of setting up Hubwatch (at $500 a
    pop) just to set the switch to Novell compatibility mode and exit...and
    the pain of needing to specially set it up with software (i.e. assign
    an IP address, put it on the network, bring it up test it etc.) it's
    not as attractive.  u c?  It INCREASES the complexity of the bundled
    solution to THEIR customer.
    
    But it the Novell option were on the set-up port...it would be simple
    and could be done from ANY PC with Microsoft Terminal under Windows or
    even Kermit!
    
    Make sense?
    j

Isn't $350K a clear enough picture?  Or does the 'K' have to turn into an 'M'
before it gets noticed?

...Roger...

    
    Whatever _any_ vendor claims, it is not smart for anyone to 'just plunk
    down' any switch in the middle of a working network without having
    both:
    
      A) A basic understanding of that switch is and what it really does.
    
      B) Some means of monitoring and controlling its operation.
    
    If any sales people (Digital, reseller, or competitor) are claiming
    that you don't need the above in a mission-critical network, then they
    are behaving in an irresponsible way.  It should be pretty easy for any
    experienced field person to describe to customers scenarios that
    illustrate this.
    
    We cannot help the fact that other vendors will make unsupoortable
    an inaccurate claims about thier products.
    

    
    To enable the Raw Mode IPX workaround in the DECswitch products, set
    the SNMP mib object:
    
    dec.ema.decMIBextension.elanext.ebridge.ebrNTP.esysIPXSwitch
    (1.3.6.1.4.1.36.2.18.1.4.11.2.0)
    
    to '1' (it is an integer).
    
    The default value is '2', which disables the workaround and should be
    used in shops that are not using raw mode ipx.
    
    The mib is available at ftp.digital.com, as usual.
    
    

    I think it's understood about the perspective of keeping things
    simple from the customer's perspective. However the key word
    that rings out to me is that the customer wants to migrate to
    a high performance LAN technology etc. but it appears that they
    want to accomplish this migration on the cheap, at least at the
    outset. Perhaps there is still a door open to understand that
    they may perhaps recognize that they may ultimately have to have 
    a tool to manage the LAN that they anticipate migrating to.
    Somehow I have a perception that we should help them understand the
    advantages of having a network management tool, in place *today*,
    so that they can learn how to use such a tool *today*, while their
    network is still relatively benign. When their network grows, they
    will perhaps most certainly regret not taking advantage of the
    use of a modestly priced tool (even if they don't have to rely on it
    on a daily basis *today*). It definitely seems like they are just
    putting off *today* what they will ultimately need tomorrow, when 
    their migration to FDDI (and perhaps other LAN technologies like
    ATM) are more firmly entrenched. A price of $500.00 for a network
    tool like HUBwatch is a pretty modest price to pay for a tool that
    could be installed on a PC and in their caase allowed to sit on a hard 
    disk unused until it's needed, but at least it's installed and in place
    in case a significant problem comes up. Hopefully, the NOVELL shop
    customers desire to migrate to higher performance LANs in the future 
    includes DEC as a partner in that endeavour.
    
    Bob

    re. .16
    
    We have given HUBWATCH away a couple of times up here when the sale is
    strategic or large.  Usually gets around network management issues real
    fast.
    
    dave
    

    Ahem.......folks....
    
    THE COMPETITION DOES IT WITHOUT A MANAGEMNET PLATFORM, OUT OF THE BOX.
    
    An all-Novell shop HAS NEVER SEEN SNMP nor do they want to.
    
    The BOUGHT NOVELL instead of PATHWORKS because it *IS* simpler to
    configure and works.
    
    LANS are simply plumbing for data - they really don't care if the pipes
    are plastic, copper or how many "T" junctions the stuff goes through. 
    THey just simply need to use the sink, tub or whatever.
    
    IF you STOP THINKING LIKE AN ENGINEER and think like the user of a john
    - just HOW MUCH do you think about the infrsatructure when you go in to
    that little room to use the plumbing.....not a lot, right?  DITTO for
    the folks out there in COMMODITY LAND who think likewise about
    Ethernet, FDDI or technology-x.  Just plug it in, if it doesn't work,
    pay an expert to come in and fix it until it breaks again.
    
    A reseller, ANIXTER, etc., is NOT going to 'give away' anything.  They
    are measured on SELLING product.
    
    DIGITAL is NOT going to give away anything - there's NOBODY out there
    selling it direct much anymore.
    
    SO PLEASE STOP THINKING LIKE FOLKS ARE DESIGNING THE
    GRAND-LAN-PERFECT-OSI-ALL-THAT-OTHER-CRAP.  To MOST folks it's magic
    and they just accept it at that!  
    
    If the competition has a box that they can plug in, WIHTOUT anything
    else, it WORKS and (at least to TWO times that I've seen) has put us at
    risk for loosing $300k...isn't it time to make a product tweak????
    
    
    ------
    Now - on the calmer side...
    
    I understand the costs associated with firmware changes, the need to
    keep module set-up simple etc.  I've written that stuff before and run
    programs a tad large than that before.
    
    Given that all that I'm suggesting is that:
    
      - Novell is a slightly visible force in the market (outside of LKG)
      - It NEEDS to be seriously addressed and catered to
      - Catering a bit to it gives use HUGE potential in Novell shops
      - Getting ONE large Novell shop to like us breeds lots of
        word-of-mouth growth in a tight user community
      - Adding an option on a set-up menu that says NOVELL for Raw IPX
        etc., is a way to make the use of the product easier for Novell
        customers
      - It would seem to be good engineering and product marketing to
        design features in that make it easier for 60% of the PC market
        to use out-of-the-box rather than argue about how the customer
        should change their thinking
    
    PLEASE DO THIS to cater to Novell customers.  Right now the biggest
    reference that we're creating about Digital networking equipment in the
    Novell space is "yeah it's ok but boy was it a pain to set-up..."
    
    j

    Besides - Bob  / Scott - in this OEM situation NEITHER of you have
    given me any compelling financial reason why you - as on OEM - would buy the
    DECswitch 900EF.  The NETWORTH box (offering 4 FDDI ports and 6
    Ethernet ports) offers more functionality and requires no management
    set-up.  It's more plug-and-play.
    
    The customer doesn't care about:
      - Sanitary Ethernet versus RAW IPX - RAW IPX works and is ok as
        far as they are concerned
      - LAN management - it's a bounded solution
     
    They are going to OEM hundreds of these - why should they buy our
    product when it's more expensive and consumes more people-time to
    configure or fix?  (Putting on my CONSULTANT hat I'd tell them that our
    products do NOT fit....I can NOT justify it financially nor
    technically.)
    
    ----
    One OTHER note - the product spec sheet says NOTHING about the key
    product differentiator - 0 measured latency on Ethernet-Ethernet - and
    that Ethernet-Ethert traffic does NOT go across FDDI.  You only learn
    that from gleaning it Digital/internal - great selling kids.  You think
    that ANIXTER or our DISTRIBUTORS know that?  NOR does it say ANTYHING
    about needing HUBWATCH to manage/turn on any features.  GREAT
    bait-and-switch kids.  So you expect me to sell this when  you don't
    tell people HOW much better it is than Networth NOR what tools are
    needed?  And don't give me "that's a marketing issue" - it's a damn
    PRODUCT issue because if we DON't sell it it's unlikely that we'll need
    anybody to build ANYTHING.  So - when WAS the last time you read the
    spec sheet and asked the questions about the product - "if I saw this,
    and bought it from the spec sheet - would I be s'prised by any gotchas? 
    And what DIDN't the spec sheet tell me that are real key
    differentiators...?"
    
    
    j
    ^--getting more fumed as he reads the product spec sheet....

    I just presented the DECswitch line to ANIXTER last week in Pittsburgh. 
    When I stressed the need for HUBWATCH in a NOVELL environment their
    faces went from happy to "oh ok...bummer..."  because they can sell
    OTHER products that do it simpler.
    
    Is that enough reason to THINK about making the NOVELL set-up port
    change?  
    
    Anixter is CLEARLY not going to push stuff that requires extra set-up.
    
    Regards,
    j
    

    
    re .20 
    
      Any simple SNMP NMS can set this MIB variable (HUBwatch is not 
      required):
    
    	enterprises(1) dec(36) ema(2) decMIBextension(18) elanext(1) 
    		ebridge(4) ebrNTP(11) esysIPXSwitch(2) = true or false 
    
    
    Bill
        

    Having been a participant in here in this discussion, I would
    like to make the following suggestion.
    
    - It would behoove you to strongly make your concerns made with
    regard to this to our product management, and probably our
    artchitecture folks. Discussing it in here is making your concerns
    only visible to a technical audience (in HUB Engineering),
    for the most part. You should substantiate and re-enforce your
    concerns for this type of feature with facts like,
    
    - the number of descrete customer installations where you encounter
      this scenario but still have hubs installed.
    - the number of descrete customer installations where you have been
      received negatively and sale didn't go thru.
    - the total amount of lost/potential dollars revenue because this feature
      isn't available either by quarter or annually.
    
    Send this information to our product mangement, and make noise in
    a clear and concise manner. Bottom line, if you feel *strongly*
    about this, then make it known to an appropriate audience.
    
    Bob

    
    ...I can't (or don't want to) believe that this discussion has been
    going on for over a month!
    
    As a network sales support consultant of the Sales ABU, I have got
    to say that I entirely agree with John's point of view.  Further,
    I am very disheartened by the apparent utter rigidity of NIPG over
    this issue!  I am told that if NIPG is to survive as a business
    within Digital that 75%+ of NIPG revenues need to come from the
    indirect selling channels.  John is someone who works directly for
    NIPG in that market space.
    
    Why are you arguing with him?
    
    He is not asking anyone to change their philosophy on how a network
    should be properly built.  He is asking that the *customer's* point
    of view be taken into account...a p.o.v. that represents a very
    significant portion of the PC LAN-based market.
    
    Every response to from NIPG is based on "go toggle the bit via SNMP",
    but the point is that this type of customer doesn't even have the
    most basic SNMP capability!!
    
    If we are serious about building product that is easy to use, we
    should make them easy to use for the *target* customer...not just
    Digital's idea of easy to use.
    
    -Jeff
    

    
    I just got out of a HUB engineering meeting where the bridge/switch
    product manager (KARL PIEPER, DELNI::PIEPER, 226-5160, 508 486-5160)
    was present.
    
    	NEWS FLASH - NO ONE, I REPEAT NO ONE, COMPLAINING ABOUT THIS HAS
    		     CONTACTED KARL!
    
    The result of this is that the request for this functionality will not be 
    acted on unless he hears from you with numbers of bridge/switch sales 
    lost.  Engineering currently has NO plans to add this.
    
    So as of right now you are considered the "vocal minority".  If anyone
    else sees this as a problem then contact Karl.
                                    
    Bill 

    
    	Wow, this string has responses varying from preaching to the choir
    to devil's advocate... 
    
    	I work in NIS in Pittsburgh with Jon and have seen the "raw 802.3" 
    Novell issue firsthand on GIGAswitch too.
    
    	What disturbs me most is not that there is no sympathy for Novell's
    "brain dead defacto" (which there technically should not be!) but that 
    no one inNIPG/NPSS or whatever have contacted Karl about the noise
    our attitude has relayed. Yes, we are technically correct, but so was
    Beta video tape....who/what won in the end?
    
    	Futhermore it's a shame this and other product critical conferences
    aren't (apparently) monitored by the higher ups in product management.
    
    	We need to "K.I.S.S." our products our else supply a technoid to
    every installation/sale to ensure these nuances do not make Digital
    products appear to be non-standard. The mindset of Digital being 
    "Orthodox spec. conformant" was/is good for the technically savvy
    market. Unfortunately, we in the Field no longer have time to educate
    the ignorant who think that market share= goodness (Novell, Cisco,etc.)
    Most customers are like lemmings I fear. We will do what we can to
    delight the purists, but the market volume/dominance will suffer. Have
    I got that right?
    
    Phil_who_wants_to_print_IPX_SUX_bumper_stickers...
    

        You are looking at it from a different perspective.  Those in the
    field are dealing directly with the customer, and are best able to
    present the customers viewpoint to product management.  It is more
    important that those who are closest to buy/not buy decisions make their 
    viewpoint known directly to product management.
    
        Since it is clear that all of product management do *not* follow
    notes conferences regularly, if you expect your opinions and complaints
    to be heard by the correct people, you must either pick up the phone,
    or send mail.
    
    MDL
    
    P.S. You have *not* seen the "raw 802.3" Novell issue firsthand on the
    GIGAswitch - that was a flooding bug, plain and simple, and was fixed when 
    it was identified.  It just happened that some of the Novell frames
    were affected by the bug.  

    I too am amazed at how hot this discussion got and NO ONE contacted me
    directly about this issue (and some of you actually talked to me on the
    telephone about other issues while this note "argument" was going on!)
    (I won't name names but you know who you are).  Also for others, please
    realize that some of us just don't have the time to peruse Notesfiles. 
    We only get into them sporadically.
    
    In any case a BUSINESS decision is what needs to be made during any 
    analysis of using Engineering resources.  What I still don't have is
    any real commitment of additional business if we make the change.  But
    I am going on "gut instinct" and Engineering will add a "Novell" switch
    into the setup menu for Wave III (the next hub release this spring).
    
    But I need to get notifications of sales wins due to this change to
    justify my demand on Engineering otherwise you may be dealing with a
    new product manager that won't run with a "gut" feeling.  So please let
    me know what additional wins we get.
    
    Karl
        

    To all those folks who griped that I didn't put a note to the product
    manager etc.:
    
     - Since I'm a bit far from LKG I do not always know who is managing
       which products, nor do I always know if something is appropriate
       to bring to that level or if it's more an engineering associated
       issue;
    
     - It amazes me that somebody who KNEW who the product manager was
       wouldn't say "Oh, gee, this is something that Fred should see, and
       forward it off with a note saying so..."
    
     - I sort of assumed that folks on a project team who did read the
       notes files would pass info back and forth, isn't that what notes
       and EMAIL are for?
    
     - Yes, I do know there is a PMLOC data base and when I checked it
       it's not terribly complete - i.e. DE425, DEFMA, DEHUB, DEHUX,
       DMTMR, DECMR, DETMR, DEFAR, DEFMR, DEMON, DEFGL, DEFGB, 
       DEWGB (any variant), DEIAP, DEINA, DNS* (any variant), DEWBR,
       etc.  all are NOT in there.  It's NOT a trivial task to locate
       a product manager if you're not in LKG.
    
    
    So, hey, if I say something that needs to be forwarded please hit
    button and forward it.  It's probably just as easy to push it up the
    line to the right person as it is to push it back to the folks in the
    field.
    
    
    ttfn,
    j

One problem is that when we in engineering propose a feature product managers
ask, "How much additional revenue can I expect from adding this feature?"
(These irritating people are concerned with impure, worldly issues like how
much money we make.)  About the most clever answer I'm able to come up with 
is, "Uh, gee, I dunno".  Or sometimes, using a voice which I hope sounds like 
Dustin Hoffman in "Rain Man", I answer, "Bout a hundred dollars".  We hope 
that people like you can make up better answers.

So, hey, if you really want a feature to help you sell more products,
try to get in the habit of calling the product manager.  That's what
telephones and product managers are for.  It's probably just as easy
to call the product manager as it is to get engineers to forward messages
to product managers.

						-Shawn

p.s.  For the humor impaired, please insert smiley emoticons liberally.

    Shawn - that is EXACTLY why we need a field/engineer rotation program. 
    I think that if we got more folks out and about thing would change.
    Until we do that and start functioning OUTSIDE of the boxes - then
    we'll be doomed to loosing things that we should EASILY win because we
    have the engineering talent to do it.
    
    I believe that we recently lost a large EDS opportunity because EDS
    felt that "your labs build stuff and then you go out and figure out if
    you can sell it....".  THAT did not speak well to what EDS felt of the
    company that they wanted to to business with.  We don't do enough
    industrial engineering - just product engineering.
    
    All you can do is help to complete a chain - and by forwarding mail
    then at least it gets in the right lap.
    
    Me, hey, MOST of the field network folks travel at least 800-1,200
    miles a week.  My parents asked me the other night if I'd be able to be
    around for something and, since I didn't have my schedule as I was at
    their house, I couldn't tell them.  I'd venture to say including the
    weekend most of the network field sales and support force spend 3 MAYBE
    4 nights a week at home if that.  So - yes - it IS difficult to
    understand exactly WHO does WHAT at LKG.
    
    We simply need more folks who are interested in COMPLETING things and
    working OUTSIDE the boxes of assigned tasks.  Figuring out the bigger
    picture and working together will help us sell LOTS more stuff and I
    get DAMN PISSED when Digital looses business because of quirky stuff in
    the products. (i.e. lack of modular media adapters, etc.).
    
    Engineering has GOT to come up with field rotation.
    j
    

    You get three nights a week at home??  Wow !!  I just come home
    saturdays to do laundry, and pick up the mail....

    Of course that INCLUDES weekends. (grin) Tho, damn, this past weekend I
    was at a resellers training on Saturday and this coming Saturday I'm at
    a local trade show so...aarugh.
    j