Conference azur::mcc

	Ok, so I'll ask a simpler question.

	Is my request so naive, that it has placed itself at the end of the 
proverbial '10 foot pole', or have I stumbled upon a weakness of MCC?

	Regards,
		Gord C.

    You have stated the problem that needs to be addressed by Distributed
    Network Management very well, with an extermely pertainent example.
    Nothing naive about it.
    
    The introduction of WAN management is one that often gets overlooked by
    those spoiled by 10 MB/sec.  Distribution will be addressed by DECmcc
    V2.0.  Problems that exist now involve the fact that DECmcc is run
    as a process and not a server.   Set Host will require some tricks
    to attach to a remote MCC and maintain that MCC after the link is
    broken.
    
    The deficency you have "stumbled" over has been know for some time
    now.  The example you have provided should help a lot in getting
    the requirements for a solution better understood.
    
    -Kevin
     

    
    	You are also pointing out that we don't have today in our
        package offer one that is addressing the Low-Tech described
        in your note.
    		 Integrating the enterprise means making these low-tech
    	sites 'full citizens' of the enterprise network.
    
    	One of the way to address this issue (waiting for the Version 2.0
    	that 'll hopefully solve it ) is to have a low-end package offer .
    	In your situation (x25 WAN) PSImail could be very helpfull in order
        to send back to the central management point information . For
        instance within the rule definition you could use PISmail to 
        send the information back to the central point . Set h/x29 would
    	also not imply to have a DLM up everytime . So it seems that 
    	within an X25 WAN backbone we could have some nice answers in the 
    	short term if we come with this package (this is work on right 
    	NOW).
    
    	It's worth to resay it again that through our Service organization
    	we could and should also provide some solution (Netsupport/NMOS
        kind of services).
    
    	Regards .
    
    MaRc 

    From a services perspective (NETsupport), I would like to see a
    provision to connect to a remote MCC station via a dialup line if
    the network connection failed.
    
    Bob Safran - NWSS NETsupport Consultant

    I strongly support previous requests. But the scope could be somewhat
    different, since several of our customers may have WANs with up to 120
    sites, linked by PSDN or RTC. Each site can be either a significant
    Ethernet LAN or a single CPU. Their major concern would be mostly to monitor
    for instance WAN traffic over X25, packets rates, packet size
    distribution, etc.. to feedback their communication costs..
    Could we expect AMs towards these needs, perhaps interfaced to
    PSI-accounting, or by other means.
    
    Another issue is that EMA approach is based upon retrieving, reading or
    getting events, alarms, etc... But nothing as to react to events. For
    instance, the same WAN customers would like to detect a RTC line failure
    and automatically turn on a circuit over PSDN or ISDN. It seems to me
    that it is out of the aim of DECmcc offer, but what are your ideas
    about that. 
    
    Regards.
    
    Laurent Moussu

     Hi Laurent,

     I would like to respond to the some of the requirements your customers
     have on MCC. Specifically your need to do Alarms on events is precisely
     the functionality we are about to deliver in V1.1. 

     Jim Cary or anyone from DECnet team should be able to help you out on
     setting up an event sink.  But once you cross that hurdle, and there
     is a DECnet event that is sinked to the local event  sink, following
     Alarms rule will monitor for RTC line failure!

  Create MCC 0 alarms rule RTC_LINE_FAILED			        -
    expression = (OCCURS( node4 < child entity name>  < event name >)) ,-
    Procedure          =  MCC_COMMON:CHANGE_CIRCUIT_OVER               ,-
    Parameter          = "LFOIS1::MOUSSU"                              ,-
    exception handler  =  MCC_COMMON:MCC_ALARMS_LOG_EXCEPTION          ,-
    category           = "LOG file notification"                       ,-
    Perceived Severity =  critical

     Where

     CHANGE_CIRCUIT_OVER.COM is a com procedure that will do the corrective
     action. I suspect you could invoke MCC from here and do all the SETs
     you want!

     Note that if you also invoke MCC_COMMON:MCC_ALARMS_MAIL_ALARMS form
     this procedure, it will send a mail to  LFOIS1::MOUSSU! The only
     tricky part is to set the event sink and get x.25 related events
     sinked.

     Does this help?

     - Anil Navkal




                                 <<< Note 466.5 by LFOIS1::MOUSSU "EIS cream...is good for you" >>>
                                      -< REQUEST - More X.25 infos, & alarm reaction needed >-

    I strongly support previous requests. But the scope could be somewhat
    different, since several of our customers may have WANs with up to 120
    sites, linked by PSDN or RTC. Each site can be either a significant
    Ethernet LAN or a single CPU. Their major concern would be mostly to monitor
    for instance WAN traffic over X25, packets rates, packet size
    distribution, etc.. to feedback their communication costs..
    Could we expect AMs towards these needs, perhaps interfaced to
    PSI-accounting, or by other means.

    Another issue is that EMA approach is based upon retrieving, reading or
    getting events, alarms, etc... But nothing as to react to events. For
    instance, the same WAN customers would like to detect a RTC line failure
    and automatically turn on a circuit over PSDN or ISDN. It seems to me
    that it is out of the aim of DECmcc offer, but what are your ideas
    about that.

    Regards.

    Laurent Moussu

    
    	The specification of the PA included that Performance Analysis
    	of X25 Lines and X25 circuits (DLM) are provided .
    		We are right now testing this with the EFT 1.1 in
    	Valbonne , and found some problems right now that are Qar'ed.
    	
    	If you look the DECnet Ph IV Entity Model , you'll
    	see that the X25 part is low (compared  to the DECnet/OSI Ph V
    	entity Model) . It means that in order to set up , Manage the 
    	X25 part with Phase IV , NCP will be required for a while (
    	Setting DTE's etc ...).
    Regards ,
    
    MaRc 

    Thanks for answering, Anil.
    I was aware of DECnet event and MCC Alarms FM as to event sinking,
    but was not about the ability to trigger an active action (by contrast
    with mail or log infos) from alarms.
    Yes, this really helps, though, as our discussion in this topic attests,
    the major concern is about X.25 traffic analysis and management.
    I stay tuned,
    
    BTW, sorry having misused RTC, a "froggy" acronym for PSTN, but I understand
    you have corrected it yourself.
    
    Laurent.
    
    

    
    Re:.7
    
    Yes, and thanks for finding those problems.  By slightly limiting the
    performance data returned for X.25 lines we will be able to provide
    some information.  Its not clear that the statistics we'll be removing
    could be considered to have any value. (Anwar, this is what you told
    me, isn't it?)
    
    On X.25.  Yeah, in DECnet Phase IV the support isn't as robust as we
    would like it to be.  It is work that has been consistently traded off
    against tasks that have seemed more important.
    
    Do you feel that more robust X.25 support is critical?  Having some
    feedback on its importance should help us to prioritize where we invest
    the people we have available.
    
    -Jim Carey
    

    In general terms, I think strong X.25 support it's critical to gain
    most network management proyects in Europe. 
    
    The scene described on .0 it's the most typical. For instance even our
    national phone company it's implementing exactly the same, over 200
    LAN's joined by a X.25 WAN, and they want to use TCP/IP and UNIX as
    much as possible. They are implementing also a central network
    management center, but they don't seem to consider our products suitable
    for their needs (Integrated event-driven management of X.25 and TCP/IP
    networks). 
    
    On another level we have talks for a proyect involving the management
    of their own X.25 switches, and the more we could use standar products
    for it, the better.
    

    
    	X.25 support in DECmcc is a vital point and it has to get the
    right priority because our customers are puting it on the reqirement
    list for taking DECmcc, at least here in GY.  My biggest customer,
    BASF, will use Wellfleet in many cases and then we hope that
    Wellfleet's own AM will help there but they are allso going to do
    X.25 with other vendors.
    
    	Regards,
    		R�nar.

    The same goes for France. I would say 50% of our customers networks are
    X25-based (Transpac OR private). The main criticism we got for
    DECnet/monitor was its rather minimal support of X25 nets. Let's not
    make the same mistake with DECmcc which is rated by our customers as
    one of the best products DEC has come up with lately.
    
    Regards,
    
    Philippe.

    
    I can only support the other replies to this note. At the moment we are
    bidding for a project in which 700 branches will be connected via X25.
    Here (Germany) many customer networks are based on x25 and the ability
    to manage these networks via mcc is very important.
    
    Regards
      Val

	We'll folks, I guess since I started this mess, the least I can do is 
respond.....I've been busy with this project, and haven't kept up with
my notes, but when I saw the discussion building in this note, I felt
I had to respond.

	It's obvious that I am all for X.25 support/functionality within the 
MCC platform, but I have a few more generic concerns that I think, raise the 
priority of including this functionality ASAP.  I should mention that the 
situation I described in .0 is not unique, and in fact we have a lot of
Canadian/International customers who have x.25 links between their various 
offices/branches.


	If we stand on the DEC partyline, as being one of, if not THE, premier
System/Network Integrator's, then x.25 support within MCC can give become  a 
very powereful lever, to bring in new business.
	
	One concern that I have is hilited by Jim's response
in reply .9;

>>>    On X.25.  Yeah, in DECnet Phase IV the support isn't as robust as we
>>>    would like it to be.  It is work that has been consistently traded off
>>>    against tasks that have seemed more important.


	To me, the statement above is scarey, because we, as DECees, are so
bent on DECnet that we feel the world revolves around it! What does X.25
support have to do with DECnet anyway?.  To me DECMCC, although somewhat less
limited perhaps, should be able to exist without DECnet at all!  But as the 
statement above illustrates, we always try to relate 'networking' back to 
DECnet, and we shouldn't.   Obviously, we should try to push our products, and
without question we have an excellent product set, but in the real world not
everybody has DECnet software, Yet!  If we  propose DECMCC, and the power 
it  offers to these customer's then not only can we illustrate our true
Enterprise Management capability., but maybe we can also excite them about 
the power they would have if they acquired the DEC sfwe suite!

	Ok, so I'll step down off the soapbox now, and get back to the task
at hand.  Seriosuly though, I think that one of our problems in DEC, is that
our products are so good, we have trouble making the  customer appreciate
their power and flexibility until they've actually tried them.  And since 
they don't try them until they appreciate the benefits, well its the old
catch-22.  Sooo, if we can illustrate our functionality, on their turf, 
then hey how can we loose.  I think that DECMCC with inherent x.25 support would
accomplish this task, and lead us into a lot of business that we normally would
have lost.

	Alright, now I've really stepped down.

	Am I in left field?

	Regards,
		Gord C.

    OK, It looks like my time to jump into this. I manage the Decnet phase
    4 and Decnet phase 5 AMs as well as the OSI AM that is currently in
    advanced development. 
    
    Jim Carey stated that our x.25 support is not as robust as we would
    like. That is a fact of life. It was a conscious trade-off made 2
    years ago to get more functionality into the DECmcc platform. No one
    made an issue of it then. If this is a serious problem (I personally
    believe it to be significant), then someone needs to make product
    management and base product marketing aware of it. There are several
    parts of the problem. First, there is support for the DNA4 x.25
    objects. Second, there is distribution of DECmcc in a distributed
    network where x.25 is the primary connection between nodes. Thirdly
    is customizing DECmcc configurations to take into account low
    bandwidth paths between the distributed parts.
    
    NME in its business plan is trying to reduce our investment in the
    DNA4 AM development so as to accelerate OSI AM development. In the
    current economic climate we do not have the resources to do both.
    Is there anyone out there who feels strongly enough about adding
    DNA4 AM support for x.25 objects to fund the development? If so
    please contact me and or John Egolf. If it is so critical to so
    many projects, someone should have a vested interest in either doing
    it or funding the development.
    
    I am quite prepared to discuss either funded development or joint
    development with anyone who feels that they have the interest and
    the funding to complete the DNA4 AM.
    

    I unfortunately cannot volunteer to get funds committed for X.25
    efforts.  I would however like to add another instance to the case
    for making X.25 a full member of the brotherhood of transports.

    Last week Consolidated Freight from Portland Oregon was in asking for
    a management environment that would handle their world-wide network
    of Ethernets/Vaxes joined by X.25.  They of course want transparent
    central control and management (i.e., Hierarchically integrated
    instances of MCC Directors... or perhaps MCC agents that would allow the
    product to seem such) of (in rough order of priority ):

        X.25 Path components
        VMS Operating systems (& applications)
        Terminal Servers 
        Intelligent 10baseT hubs
        Ethernet Node entities 
        Vitalinks & DEC Bridges
        PC Servers 
        SNMP entities 

    They have only NCP right now (!), and liked what they saw of EFT1.1.
    It's evident that they have put some thought into what they'd like.
    They would pretty quickly discover however that the current DECmcc
    product set isn't going to deliver against major pieces of what they
    need.  I'm not suggesting how to spread development dollars; just
    wanted to advertise that another one of our customers is asking for
    what is becoming a familiar laundry list of functions mentioned in
    this note.

    In a former life, I managed Network Management Architecture for one
    of the larger X.25 switch vendors. I am well aware of the needs to
    provide a management capability in networks which are X.25 based.
    I am also painfully aware of the lack of standards in this
    environment. Each X.25 vendor has their own management scheme that
    is proprietary. There is also a wide spectrum of bandwidth between
    x.25 nodes (9.6 kbit to 2 Mbit and in some special cases 100Mbit).
    The first issue to solve is the management protocol between the
    m-object and the manager (entity and director in EMA jargon). Current
    x.25 products all use proprietary protocols layered on X.25, IP, or
    TCP. You need an AM for each of these. Hopefully future products
    will use the SNMP protocols which will allow  a single AM to
    provide support.
    
    Now, the issue of distribution of DECmcc over X.25 networks etc.
    Distribution of DECmcc requires an RPC like implementation. Sometime
    in the next year we will be implementing a version. We will use
    whatever standard RPC mechanism that becomes the corporate standard
    (likely whatever OSF specifies). It is very unlikely that what becomes
    available will be implemented over raw X.25. It is a NON trivial
    task to build an X.25 based RPC mechanism. I would suggest that
    a connection oriented protocol such as TP4 is the most straight
    forward way to implement it. Yes, This suggests an OSI based solution.
    That is the rub. Getting the various x.25 customers to understand
    that they need to migrate to OSI to get the benefits that they
    are looking for. 
    
    Lastly, Distribution of DECmcc over low bandwidth paths. This is also
    a non-trivial exercise. The flexibility of DECmcc will allow the
    installers to badly botch the distribution if they do not clearly
    understand the volume of data that will be exchanged between various
    directors. It has been my experience that the x.25 networking customers
    are looking for panaceas and clearly do not understand the various
    traffic loading of the management scenarios that they are looking for.
    
    wally