Conference azur::mcc

    Bruno,
    I think I could help here being part of the Product Development Team
    for NSDP. NSDP is the code name for the DSP migration product.
    NSDP stands for Network Services Delivery Platform.
    NSDP is based on DECmcc platform with additional software required
    for the delivery of all Network Services.
    If you think you have specific requirements for consulting services
    I suggest you contact Amrit Patel and /or Jeremy Hodsman in Valbonne.
    The engineering effort will be done in Annecy EIC-T&N-E.
    
    Hope this help
    Daniel.

    re .0

    Something being missed (may be subtle) is that although the customer
    has no particular need for X.25, it may well pay us (Digital Services)
    to see what we can do do be pro-active about the X.25 circuit failures.
                                                                        
    May be if we can detect these circuits utilization, re transmissions
    threshold etc, then we can pro-actively manage the X.25 restarts etc in
    stead of operating in a fire fighting mode.

    The root of this (will stand corrected) note is the STRONG DESIRE IN
    EUROPE TO SUPPORT X.25 MANAGEMENT.  X.25 and ISDN are becoming more
    and more popular.

    In any case how can "we" hold "our" hands on "our: hearts and say we
    can support DECnet IV if we cant support X.25 (DLM etc) Because we have
    MCC does not mean that our customers stop using X.25 

    Any comments from European readers ?  -- (subtly being provocative ;-))

    Amrit Patel

Amrit,

don't we with DECmcc, however, have the same X25 management functionality which
is now available through NCP? i.e. receive notification of events such as:
- outgoing switched virtual circuit failed
- DTE up/dn
- clear/reset/restart

And be able to read couners of:
- resets/restarts
- max channels active
- incoming calls received

And can't we have traffic and utilisation statistics as for any DECnet circuit? 

I thought we can. Am I wrong?

I understand that we can't see, with DECmcc, what happens at LAP-B level (on a
phase IV node), but if our VAX or router is connected to a private or public
X25 network (with its own management center) the management of LAP-B could be
done by the latter. What do you think about?

Ciao
bruno

    
    Unfortunately, we don't offer the same level of support for X.25 as
    NCP does.  The DECmcc DNA4_AM doesn't support any of the X25 modules
    or the attributes associated with them.
    
    That limits our X.25 support to something just less than NCP can do.
    
    I can't make any promises on enhancing that (I'd like to).  We do try
    not to promise too much more than we have resources to deliver, but I'm
    sure you've all heard that.
    
    On that vein though, is there some absolute minimum x.25 support that
    could let you succeed with DECmcc?  Thanks for the input.
    
    -Jim Carey
    
    

    
    Re .4
    
    I suggest the minimum support that is acceptable is that given by NCP
    at the moment. 
    
    Ideally, it would be good to be able to alarm on X.25 events (7.* I
    seem to remember) and to give really good performance stats, including
    packet size distribution. This is important as the  customer has to pay
    for every byte sent over the link, and any help we can give to reduce
    this will give instant fiscal benefits to the customer.
    
    Paul.
    

    
    I tend to agree with .5.  In general, NCP offers rudimentary network
    management capabilities in Phase IV.  You can get status and integrity
    data - not information - along with events.  A common complaint that I
    receive from customers is that NCP provides raw data - much of which
    they don't understand (for example, "NCP counters give me all of these
    numbers and I don't know which counters are the important ones to
    watch.")  If MCC cannot provide at least what NCP provides, then
    customers will ask themselves why don't they just stay with NCP.  And,
    since they are typically not fond of NCP as a sophisticated management
    tool, they will remain unhappy about our total management solution.
    
    Now, back to reality.  I understand that Engineering cannot provide
    complete replacement functionality for all manageable entities right
    away.  Through windows a network manager can pull up a DECterm into NCP
    that allows him/her to manage things like X.25.  Maybe that in itself
    is the advertised capability within MCC at this time.  It may not be
    integrated management, but at least its consolidated.  (Note:  In
    recent years, consolidated management was the best we had with
    DECmcc-EMS and SMS, so we "should" be able to lean on it a little in
    areas that MCC has yet to cover.  
    
    Providing poor management capabilities for things like X.25 may be
    worse than providing no management capabilities...
    
    Mike