Conference azur::mcc

2353.0. "European EIP trip: Mgmt of large scale networks" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Mon Feb 17 1992 10:24

[Forwards deleted; cross-posted to EMA conf]

From:	RDVAX::LANDINE "DIANE, MLO1-3/B10, DTN:223-3510, RAD COMMITTEE/EIP  14-Feb-1992 1606" 14-FEB-1992 14:15:51.98
To:	@CE.DIS;
CC:	LANDINE
Subj:	Trip Report: European EIP Sessions on Large Scale Networks


EIP sessions in Europe on "Large Scale Networks" have been completed. John 
Harper was the Lead Engineer. A total of seven customers were visited between 
September and November 1991.
    
The major findings from these visits appear below, and the detailed report 
is posted in:

    	RDVAX::SYS$PUBLIC:EIP_LS_NETWORKS_EUROPE.REPORT

Pls. comment on the findings either in the RDVAX::EIP Notesfile or via mail.

Sessions with USA accounts will take place during May 4 week. Comments on 
the findings below will be very helpful in focusing those sessions.

Erwin Weiss 
             




d i g i t a l
                 I N T E R O F F I C E   M E M O R A N D U M

                                   Posted:       14-Jan-1992 
                                   From:         harper      
                                                 harper@FERIC@TAEC@OSI@MRGATE
						 @RTOIC@RTO 
                                   Dept:          
                                   Tel No:        

TO:  distribution 


Subject: EIP/LSN Report                                          



                EIP visit reports (Europe): Large Scale Networks

                           September - November 1991

                              ====================
                              COMPANY CONFIDENTIAL
                              ====================

    
    Summary
    
    During these EIP sessions, conducted during September 1991 through November 
    1991, total of seven customers were visited:
    
    	DECUS Europe, The Hague, Netherland
    	DEBIS (Daimler-Benz Information Systems), Stuttgart, Germany
    	DETECON (subsidiary of Deutsche Telekom), Bonn, Germany
    	ERICSSON, Stockholm, Sweden
    	BASF, Ludwigshafen, Germany
    	CERN, Geneva, Switzerland
    	REUTERS, London, England
    
    The EIP team consisted of:
    	
    	David Brash, 	CBN Engineering, Reading
    	Stewart Bryant, Dist.Systems Arch. & AD, Reading
    	Lois Frampton,  Dist.Systems Arch. & AD, Littelton 
    	John Harper,    Dist.Systems Arch. & AD, Reading
    	Dave Oran 	Dist.Systems Arch. & AD, Littelton
    	Mike Shand, 	Dist.Systems Arch. & AD, Reading
    	Erwin Weiss, 	EIP Program Office, Munich.
    
    With the exception of one customer (Detecon), the people we saw were 
    involved in the planning and operation of enterprise-scale networks 
    involving thousands of users across multiple sites. This is exactly what 
    we were looking for.  Several points emerged in a consistent fashion 
    across these users.  The major common points are as follows.
    
     1.Every single customer reported that their biggest headache is the need 
       to manage a network consisting of heterogeneous components, and the 
       proliferation of incompatible management tools. Several them are MCC 
       users, and they saw MCC as part of the problem (i.e. yet another 
       incompatible proprietary tool) rather than as a potential solution. 
       MCC still has a chance to succeed if it can genuinely provide 
       multi-vendor management and be perceived as a reasonable base. Users 
       also need to be able to include their own management tools (without 
       becoming MCC experts), much as they can solve system management 
       problems with DCL or Shell scripts. The credibility of MCC and EMA as 
       a solution is very low: as one customer put it, it's late, it has no 
       useful PMs, no useful FMs, and no useful AMs, but apart from that it's 
       fine. The general concept of EMA is however still liked.
    
     2.A related problem is the level of tools provided for management. 
       Simply reporting the raw data supplied by SNMP, CMIP etc is not 
       enough. Some level of analysis is needed, such as trend monitoring for 
       error counters and a configurable alarm system. There was little 
       interest in what one customer called "video games", e.g. facsimiles of 
       equipment showing the state of the LEDs on the front panel.
    
     3.The PTT tariffs in Europe are cripplingly high. This is a major factor 
       impeding the growth of wide-area data networks. (The charge for a T1 
       line is at least ten times what it is in the US). A partial exception 
       is the UK, where the PTT monopoly is weaker.
    
     4.FDDI deployment is practically zero. Even in the future, nobody except 
       CERN can see a need to have more than one per site; even CERN don't 
       expect more than a handful. Basically the issue is that nobody needs 
       that much bandwidth. Nobody is looking for 100 Mbit/sec of actual 
       performance. Only one customer (CERN again) was interesting in direct 
       attachment to FDDI, but they see the cost of doing so as prohibitive 
       at the moment.
    
     5.Most customers are doing some multi-protocol routing at the moment, 
       using routers from the usual vendors (all of the significant router 
       vendors were represented). All of them make use of packet filtering 
       (based on addresses, etc). We will make no impact in this market until 
       we are able to offer this capability.
    
     6.None of the customers had any significant OSI usage at present. Apart 
       from Phase V, which takes them to OSI whether they need it or not, 
       none reported any pressing need for OSI. Their multi-vendor 
       interconnection needs are currently being met by TCP/IP and PC-LAN 
       protocols. However nobody actually objected to OSI and they all still 
       see it as a long-term direction.
    
    Common themes of less significance are as follows.
    
     7.The ability to account for network usage (or provided detailed traffic 
       pattern monitoring, which amounts to the same thing) would be a 
       valuable differentiator. All customers were interested in this. None 
       had very detailed requirements as to exactly what should be done; the 
       current architecture would seem to be very acceptable.
    
     8.The reaction on service classes was mixed. Most saw possible uses for 
       it but no real need. One (Reuters) saw it as essential.
    
     9.There's no doubt that SNA is declining, albeit slowly. No customers 
       saw any big growth for SNA, and most are experimenting with some kind 
       of multi-protocol approach (such as SDLC tunnelling or the use of 
       gateways and PC access products).
    
    10.There was little reaction to the question of wireless/mobile 
       computing. Some companies could see possible uses for it but none had 
       any current need.
    
    11.The migration and integration issues around DNS, X.500 and other 
       naming services were seen as a concern by several customers.
    
    12.True distributed processing was very much in its infancy, at least 
       among these customers. The use of networks was very much for "network 
       computing" rather than anything more tightly integrated.
    
    13.The one distributed processing topic which did attract a lot on 
       interest was authentication. All customers agreed that good, 
       widespread user authentication was necessary for expansion of 
       distributed processing.

----------------------------------------------------------------------------
			end summary

Full text available at RDVAX::SYS$PUBLIC:EIP_LSN_EUROPE.REPORT