Conference azur::mcc

    There are no current plans to do an LTM AM that I know of. My
    understanding is that it would be the responsibility of the 
    LAN BU to develop one. There past position is that there is
    not a sufficient business case to replace LTM. If someone were
    to build a convincing business case for an LTM replacement, then
    I am sure that some group in DEC would pursue it. 
    
    There is a policy that NME in the future will develop AMs for 
    objects which use industry standard management protocols such
    as OSI CMIP, SNMP, etc. AMs which use other management protocols
    are the responsibility of the organizations which develop the
    agents for the objects. It is a tough trade off whether to use
    our limited resources on expanding the coverage of MCC to more
    objects or to provide better generic functionality. We would
    rather err on the side of providing more generic functionality
    and leave the development of non-standard AMs to others. This
    is very similar to the policy of VMS in having others develop
    device drivers and having VMS concentrate on basic OS functionality.
    
    If you believe that such an AM is critical to a customer or a set
    of customers then clearly communicate that to the LAN BU management
    so that they can include it in their Long Range Planning and
    funding cycle. 
    
    wally

	Not quite true...

	Steve Lane,  product  mgt,  is looking at external vendors with
	the intent of  some  type  of  joint  effort  between  then and
	Digital.

	NME  is  looking to  develop  "value  added  applications"  and
	Traffic Monitoring is at the top of the list.

	JCE

    re .1
    There is a big demand for LTM functionality within DECmcc.
    All our customers are crying for LAN Monitoring in DECmcc (
    functionality like HPs LAN Probe ).
    Our LTM as it is now is very limited: max 1024 addresses, max 61
    protocol types.
    In all our big networks we have overflows.
    
    Karl

    Gary,
    
    To expand on John Egolfs reply I would direct you to the DECmcc Traffic
    Monitoring Phase 0 Requirements.  You can copy them from:
    
    	DELNI::USER$182:[S_LANE.PUBLIC]DECMCC_TMF_P0_REQS.TXT
    
    A few editorial notes are also in order.  First of all, we closed
    Phase 0 on the Traffic Monitoring Requirements in early February of
    this year.  However, due to resource constraints, schedule conflicts,
    etc., we were not able to apply any engineering talent to the problem.
    As John said, Traffic Monitoring is one of our highest priorities as
    soon as the engineering resources become available.
    
    Specific to LTM, the requirements state that DECmcc must supersede LTM
    functionality.  At minimum, this means an AM to talk to the existing
    LB100 and LB150 listeners as well as an FM to do the appropriate LTM
    host software functions.  A graph window is already planned for the
    DECmcc V1.2 DECwindows PM.  Remember that it is a goal of DECmcc to
    supersede the functions of all network management point products.
    
    To go beyond the admittedly limited functions of LTM there are other
    plans/opportunities/requirements.  For example, the IETF is working on
    a Monitor MIB (data link layer only).  Any device that supports that
    MIB will, in theory, be a data source for DECmcc through the SNMP AM.
    All we need then is a generic FM to process the generic data from those 
    devices.
    
    Then there is the prospect that John alluded to -- a strategic
    relationship with a "monitor" vendor with a box capable of collecting
    traffic data at multiple layers from multiple protocols.  This would
    most likely require a specific AM and a specific FM to process the
    higher-level data.  The goal here is to provide a value-added turnkey
    solution (e.g., OEM the vendor's box and sell it as part of a DECmcc
    traffic monitoring package along with the AM and FM).  Using such
    higher-level data, it is also possible to develop value-added
    applications -- demand forecasting, performance optimization, network
    design, and, dare I say it, accounting, come to mind).
    
    Finally, there are other possible data sources.  Many smart hubs and
    routers are now, or soon will be, capable of providing traffic data.
    If they are DEC or strategic partner devices we should look collecting
    data from them as well.
    
    As for field test, I can't say when and won't be able to until we can
    get some engineers assigned to the task.  Soon, we hope.
    
    Steve
                                                

    If anyone is interested in developing an LTM AM, I can provide quite a
bit of start-up material.  At one point, I had done a full writeup for a
MRM chapter for the design of an LTM AM, and had a working prototype.  This
was quite a while ago, so the code is somewhat dated with some of the MCC
design changes (and it's written in PASCAL), but it would probably save
you several weeks in the initial phases of design & coding of an LTM AM.
I'll be happy to provide all the material I have (including the LTM
protocol spec) to anyone who's willing to do the work.  I'm leaving the MCC
group, so I won't have the opportunity to do any further work on it myself.

						Wayne

    Just to make clear that LTM functionality from MCC is very important.
    
    We have dozens of customers, that use a platorm of DEC products to
    monitor their networks, including LTM to monitor their LAN traffic.
    That we would like to change over to MCC,  but cannot until DECmcc
    can also be used to monitor their LAN trafic.
    
    So please, if at all possible, LTM functionality ASAP. For v1.2 it
    would be great.
    
    Gil

 We're currently looking at implementing an LTM AM (and possibly FM).
This AM would layer on DECmcc V1.2 VMS and ULTRIX, providing
as much of the LTM point product functionality as possible.

 It would use as a starting point some of the work done by Wayne Morrison
(see Wayne's "limited offer" - note 1317.6).

 More information will be posted here as it becomes available.

					Chris Brienen

    Chris,
    	If you are planning on building an FM to do the graphing/exporting
    etc. would it be possible make the code generic enough to take data
    from sources other than the LTM-AM?  It would be easy to market a
    traffic analysis tool that could take data from LTM's (911 and 944
    models) and some of the other common traffic monitoring probes. 
    Customers would love to have a tool that would pull data from LTMs
    HP LAN-Probes, Novell Lanterns etc.  and consolidate the data for
    reporting.  It may be enough if we had a product that just used the
    data from the new RMON mib.  Most traffic probes will probably
    use this mib in the future.  It might be easier to build a product
    that just uses the RMON mib data and build an SNMP proxy agent for our
    listeners.
    
    Don't you just hate when somebody who has no involvement with your
    product says a change is easy ;-)
    
    - Mike

    
    Change is always easiest when incorporated in the original design!
    Now is a great time to state "requirements" and "wish-list" items.
    
    As to your statement regarding a generic LTM FM capable of taking
    data from different sources, the only questions I have are:
    
    	- how would you want us to query the data from these sources?
    	- Do you know what format/encoding algorythmn they use in
    	  passing the data?
    	- What do you see as the "common" thread between the different
    	  sets of data?
    
    As to the RMON mib, I don't know anything about their mib, but with
    the new TCP/IP diagnostic assistant, performance anyalyzer, and
    MIB compiler, along with the V1.2 iconic map graphing capabilities
    we may alreay have in 1.2 the basis for some of what you are looking
    for.
    
    jill
    

The currently held (at least by me) view is something like this:

We're talking multiple products:

	- LTM AM and possibly FM. Replace the existing LTM
	  point-product, layering on DECmcc V1.2 (VMS + RISC/ULTRIX)
	  and leveraging existing DECmcc functionality (e.g. Historian,
	  Exporter, Alarms, Graph Widget). Viewed as having a quick
	  time-to-market and a chance to test "monitoring related
	  issues/features" in the DECmcc V1.2 system.

	- Traffic Monitoring FM. Longer term (we're probably talking
	  about functionality rolled out across multiple releases). 
	  Address the LAN (can anyone say "RMON MIB"? 8*) and WAN
	  Monitoring space. Acquire necessary raw data from TCP/IP SNMP,
	  as well as other, AMs (e.g. DECnet IV and DECnet/OSI).

I agree with Jill: feel free to make your requirements/desirements known
(Mike Reilly is always a source of good ideas!)...

					Chris Brienen

    
    > As to your statement regarding a generic LTM FM capable of taking
    > data from different sources, the only questions I have are:
    >
    >	- how would you want us to query the data from these sources?
    >	- Do you know what format/encoding algorythmn they use in
    >	  passing the data?
    >	- What do you see as the "common" thread between the different
    >	  sets of data?
    
    Jill,
    	 Most traffic probes are now SNMP based.  Assume all data can be
    obtained by loading the vendor's MIB extensions. 
    
    
    	 
    > As to the RMON mib, I don't know anything about their mib, but with
    > the new TCP/IP diagnostic assistant, performance anyalyzer, and
    > MIB compiler, along with the V1.2 iconic map graphing capabilities
    > we may alreay have in 1.2 the basis for some of what you are looking
    > for.
    
    The RMON mib is an experimental MIB which holds traffic statistics
    etc for the data-link layer.  Shipping the MIB definition with
    the SNMP Access module or the LTM_FM kit may be enough to satisfy
    customer's initial needs.  The V1.2 graphing capabilities will be a
    big plus.  BTW: This MIB was recently voted an Internet Standard and
    within 1 nanosecond I had a call from a vendor who stated they had
    the first RMON compliant management station on the market!!!.
    
    Considering that the RMON mib has only support for data-link
    statistics (no protocol breakouts are provided), I wonder why vendors
    are rushing to support this MIB. Any ideas?
                                                                
    
    - Mike

> I wonder why vendors are rushing to support this MIB. Any ideas?

	1.  Because it's in fashion.

	2.  Because it's a perceived marketing/sales edge, as is the
	    ability to react quickly to the IETF and the IP community.

	3.  Because it probably does contain some new useful information, and is
	    also the first application of a more useful model:  to the crunching
	    there, send the results here, as opposed to polling for all the
	    raw data required to generate the statistic(s).

	Mike

in addition to .13   ...

The limitations of the RMON MIB allow the individual vendors the freedom 
to add proprietary statistical functions and retain market 
individuality.

...kjn