Conference azur::mcc

    Wally, you are right, there are many aspects to topology.  I hope that
    DECmcc someday treats them all.  Ordering new bandwidth just in time
    would be a nice selling point.  However, I plead for attacking this
    problem one step at a time.  Please solve the simple problems quickly,
    then work on the more complex ones.  Don't wait until you have topology
    models in place - cause we have to compete against other simple
    solutions today.  Today's topology requirements is the ability to find
    who's there, who's connected to who - and draw a map that is close and 
    provides enough nice map editing tools to make it right.  IP is where
    most the advances are going on - but if you can do it with DECnet and
    DEC's bridges and FDDI that is great.  Very few vendors can detect
    changes in real time.  HP talks like they can - and I understand that
    you must employ lanprobes to make that feature work.  However, with
    smarthubs and the new lanprobes on the market (using 12mips risc
    processors), there is all sorts of information to input into your NMS's
    autotopology routines.  THIS DOES NOT SOLVE THE WHOLE PROBLEM!  However
    as other vendors solve some of the problems - MCC must keep up.  Some
    of the problem is being solved - and customers will buy the leaders
    that are solving what they perceive as 'problems being solved today'.
    This note has the same 'incremental' theme as the other one I just
    wrote.  Guess it's just something I think we need to understand and
    address before the Digital sales force can bring in our FY91 revenue.
    
    bill

    re: .1
    Bill, who said we were waiting around until we solve the whole thing.
    We are working several parts of the problem in V1.2. We have people
    actively developing an automatic map generation tool. We have people
    building a CIRCUIT MM which implements the NMF Circuit. The circuit
    concept has simple topology structures inherent in it so that it
    can be used to model simple connectivity NOW. We are also adding
    to the Alarms FM a target entity capability, and adding to the
    iconic map a mechanism that allows us to use lines as icons.
    Collectively, we are adding a lot of simple pieces to the topology
    question in V1.2. 
    
    The plan is to phase topology in over multiple releases. We heard you
    many months ago. I think you misunderstood my motivation for placing
    the note in the file. 
    
    I want to share the vision of where we are going, so that we have that
    vision during the journey. I don't want us to think that our simple
    milestones are the ultimate end of the journey. I want us to make
    sure that we pursue simple things that lead to the end goal and are
    careful to not overzealously think that the simple solutions are all
    that is necessary.
    
    wally

    The MSU folks are shipping autotopology for both decnet and ip in their
    next release (October) and ran into an interesting problem.  Some of
    the field test customers have cicso routers - which support decnet
    routing, but you get at the routing tables using SNMP (no NICE support).
    The answer is obvious - either restrict it to DEC routers (not a
    marketable solution) or make the auto-topology routines flexible enough
    to ask for the routing info via NICE or SNMP.  How would MCC handle 
    this?
    
    bill

    There is a bit confusion between the terms auto-config and auto-toplogy.
    Both are parts of CONFIGUARTION management. Auto-config is to figure out 
    the configuration in an automated manner. Topology deals with 
    configurations and the relations among the entities that are configured. 
    Auto toplogy is to figure those relations along with the configuration
    in an automated manner.
    
    The product mentioned in .-1 is auto_config or auto-toplogy?
    
    Thanks.
    
    / Jay
    

Re: .-1
    
>    The product mentioned in .-1 is auto_config or auto-toplogy?

A bit of each really.  Given a single IP gateway or DECnet router, MSU's 
discovery function will do auto-config to determine the other IP gateways or
DECnet routers by essentially tracing routing (network) layer connectivity.
Thus the resultant map reflects the IP routing or DECnet network topology.

So by your definition, it does auto-config by determining other entities that
are part of the total configuration, and auto-topology by tracing network-layer
connectivity relationships to produce the resultant map.

Paul

    The problem is actually not that difficult.

    There is in a network a distributed application running on all end
    nodes and routers ( my terms are very much DECnet but valid for
    TCP/IP as well) .This application detects new nodes, nodes going away
    and keeps track of best paths to other nodes.

    This application has all information to draw a complete topology of the 
    network .Depending on technology , there is one or few or a lot places that
    together keep this information.

    Topology here is meant as "logical topology", if you are on it, you are
    reachable. This application is called Network Layer or Routing.
    Creating logical topology map can be greatly simplified if one could
    ask routers for the databases. 

    In DECnet phase IV one can query every router about it's forwarding 
    database and adjacency database.

    Phase V link state packet database contains complete topology
    information for the router's area, but is not directly accessible.
    But it can be fixed ( a new NCL command to a router) or intercepted
    by an imaginary  "network management topology agent".

    This is enough to draw a DECnet network logical topology, but it is not
    enough to draw the physical topology , there are few problems here :

    - backup circuits that are usually down and that are brought up in case
      of emergency.

    - parallel circuits. I don't know a way of finding out which circuit is
      connected where in case of two parallel circuits between two routers.
    ( But there might be one it is on my "to do" list .-)   

    So , some manual fixing of a topology map cannot be avoided.

    There is another limitation of this approach, sometimes Routing doesn't
    know or doesn't exist , in this cases packets are just sent out and
    hopefully arrive at the destination. This is how DECnet routerless LAN
    works and how IP works in some cases.

    Usually, this is the case of LANs. There is no other way to know about 
    these system then to listen to the LAN. The systems might send a
    periodic ID messages or their traffic can be intercepted and address
    recorded, by our "network management topology agent". Bridge forwarding
    db can serve this purpose. In any cases, there is a need of a local piece 
    of equipment to help us .

    In summary, WAN problem is simple, routers keep all info. LAN problem
    is also simple in DECnet case. IP is harder but no hopeless if one can
    query bridge db or maybe IP router's db.


    Having a model of Network Layer fixes not only logical topology problem

    1. one can have new types of alarms, very important from network
    managers point of view . Network managers need not only know that a
    circuit is down, he must know the impact on logical topology and thus
    reachability. This may help him to make a bridge to business impact of
    a failure.

    	Possible new alarms :

    	- area reachability change
    	- partitioned area ( both phase IV and V problem )
    	- LAN router misconfigurations ( both phase IV and V problem )
    	- designated router wars
    	
    	If you think about it there are some DECnet entities today that are not
    	modeled anywhere ( an  area or a  LAN ).

    	2. Correct alarming "targets". 

    	Since routing knows that a "node down" event from a router says
    	something about the node not a router, right entity can be alarmed and 
    	right icon turn red.

    	3. Ease of use. 

    	Lots of "retargeting" events etc and definitions could be avoided
    	if all routing layer events were sent to routing. 

    	4. Network bandwidth saving.

    	Routing makes incredible effort to know who is out there and if
    	all nodes are reachable. So, if one could ask routers for
    	reachability tables, all expensive network polling could be avoided.
    	

	5. Today an the iconic map is an "arbitrary " integration point of
    	the logical topology, and thus all the problems of a static
    	definitions, Routing FM is the right place to control the topology
    	map correctness.

        						regards,
    						Wlodek

	ps. So what about bridges, repeaters , "delinis" and modems ?
    	It is important to keep right level of abstraction. All mentioned
    	components are layer 2 or 1. Mixing layers too much confuses
    	everybody, but still "some" mixing is necessary. If a bridge is
    	also an entity at Network layer ( a brouter or having a layer 3 for 
    	the sake of management, then some automated topology description
    	for this guy is possible, otherwise, we need a manual
    	intervention.)
    	
    	The manual fixing of topology will always be necessary, this is
    	something that network managers must be able to do.
    	One should concentrate on automating things that change fast,
    	like systems joining a LAN. The WAN lines take months to order and
    	don't change that fast ( yet..., wait for dynamic transmission
    	systems...) so it is not a big deal to manually define a Vitalink 
    	bridge or other transmission network component.

    Note -1 got me thinking. I think we need to take a step back and
    see if we can present this auto-topology problem in a different way.
    There are two major requirments for true auto-topology.  Firstly we need
    a way of entering the rules that govern network topologies.  These
    rules will be protocol and media dependent.  The rules will be
    used to build a graph of the network in the management station.  One
    set of rules will specify the operation of the various types of
    nodes in the graph and a second set of rules will specify the
    capabilities of the edges in the graph. An examples of a node
    rule would be something like
    
    node DECNET_LEVEL_II_ROUTER :== includes (device DECNET_LEVEL_I,
    					      device DECNET_END_NODE)
    				    interfaces ( 1 to NO_OF_INTERFACES)
    				    	attributes ( NEXT_AREA, COST)
    		                    Routing_algorithm = Least_Cost(COST)
    			            Path_split_algorithm = SPLIT_LEAST_COST
    
    edge ETHERNET_LAN	:== 	speed 10Mb
    				
    The capabilities/rules would need to be much more complex than this
    (and better thought out!). If we have a complete set of topology rules
    we can now build a topology graph,  if the values for the rule
    variables are known.  Getting this information is the second
    major requirment for auto-topology.  We need a way of mapping device
    dependant representations of the variables to the internal format used
    in the rules described above.  For this mapping a library of
    translation functions or Access module calls will need to be built
    for each of the device types that exist on the network.  Using these
    translation routines we will be able to handle cases where the next
    hop in a DECnet WAN is a Cisco or Wellfleet router.  Both of these
    devices do not support the NICE protocols so their DECnet routing
    tables cannot be queried via NCP.  This information can only be
    viewed by SNMP queries.  Our current auto-topology techniques would
    break when we hit a devices whose routing table we could not query.
    By having the translation routines available we could tell the
    auto-topology function module that the Decnet router at address
    n.nnn is a Cisco and it would use the Cisco translation routines to
    get at the data.   
    
    Breaking up the auto-topology task into two pieces like this would
    allow us to use information stored in devices like HP's Lan Probe 
    without major engineering efforts. All that would have to be written
    is a simple translation function for the new devices.
    
    - Mike
    		
    
    
    
     the determination 
    we will be able to achieve in the next few years will be computer
    assisted topology determination.  Auto topology assumes we are able 
    to get at the critical routing/bridging tables in our networking
    devices   

I agree with the title of .-1. "Auto topology will never be easy".
I find this discussion very interesting since we did some work in the past
on autotopology for Ethernets and IBM networks. As most of us seem to agree,
if we talk about auto topology, we actually mean two things:

1. Auto-config : finding out in an automated manner, what is connected to
                 what, and storing that in some DB.

2. Auto-layout : Using the information in the DB, producing a graph out of
                 this data.


The first one  requires knowledge on things like: how routers work, what 
information is stored in what kind of devices (routing tables, forwarding
  DB's etc), how to get and update this information (NICE, SNMP) etc, etc.

The second one requires knowledge on topology algorithms like:
how to draw a "nice" representation of a meshed network or an Ethernet or
a token ring, How to minimize crossings , etc. etc.

Both tasks are not easy , and I agree with one of the previous noters that 
we should approach both areas in a step by step manner. 

I would suggest to keep the discussion in this note separated in these two
areas. Personally I am more interested in auto-layout. I think that a good
approach for the auto-layout problem, is as mentioned in .-1. It  is
possible to develop a syntax, that would enable you to define auto-layout
rules. The auto-layout module, would than use these rules to figure out a
"nice" looking representation of the network. Notice that I mention "nice"
between quotes, because there doesn't exist such a thing as 'one correct
presentation'. Think about how many ways you can draw a meshed network with
let's say 10 nodes!

Keep this discussion going.....

Timo

PS:Given the above split, what may we expect in V1.2 from an auto-config and
   an auto-layout point of view?