Conference azur::mcc

    I would assume that this functionality is a natural by-product of
    the MCC Topology effort which is currently going on.  Perhaps someone
    from the Topology team (or Wally?) would like to confirm or deny this
    rumor I have just started :-)
    
    -Matt.

    Rumor, what rumor? We all wear blue skin tight suits with a Red S on
    our chest! 
    
    Seriously, the note hit on many different items and we only provide a
    small part of the answer. Yes, we intend to provide a DECnet path trace
    at some point. The development is currently underway with the EZnet
    Engineering group for their use in migrating EZnet from Phase IV to
    Phase V. We will productize that at some time as part of a DECnet
    FDA. When, you ask! When it is working and we can get it documented.
    I wouldn't anticipate it for V1.2.
    
    There was a description of a SIZZLE user presentation of the Path
    trace tool. I would expect some way to highlight the path on the
    currently displayed domain. I am not sure that color is the right
    way to present it since colors will be used for alarms. We will find
    some way to highlight that portion of the path that is part of the
    current domain view. Fred and Jim Lemmon will figure that out but not
    in V1.2.
    
    Dynamic changing view; well those of us with the Red S aren't sure
    that this is feasible and further we have reservations of its need
    vs. its cost.
    
    DECnet and TCP, YUP! OSI, YUP! SNA, It would be really nice! Other
    protocols such as LAT, etc. It will depend on someone who is
    responsible for those protocols (ie. third parties) writing appropriate
    path trace FMs for their protocols. 
    
    A generic Path trace so that everyone gets it without writing an
    appropriate path trace FM. I doubt that this is feasible. Topology
    can provide the normative static path between 2 objects but it is
    not always possible to track the dynamic changes from second to
    second, nor is it possible to validate continuity through some
    components such as matrix switches etc. without using technology
    specific probing which obviates the ability to provide a generic
    tool. We will come as close as feasible, but don't hold your breath
    waiting for the ultimate answer.
    
    wally

    Watch out, Wally.  Topology can be a real tar-baby when it comes to
    functionality.  But one of the most important functions it needs to
    provide (some may argue, THE most important function), is to be able to
    answer the question, "Can I get from Point A to Point B, NOW"?  If you
    can answer that question, then that can become the basis for much more
    sophisticated functionality.  For example, ask the question every 15
    minutes.  Or, "if I can get from Point A to Point B, and from Point B
    to Point C, then I can get from Point A to Point C".  Or, using reverse
    logic, "If I CANNOT get from Point A to Point C, but I can get from
    Point A to Point B, then I must not be able to get from Point B to
    Point C" (assuming the normal connectivity rules of A->B->C).  In other
    words, the functionality becomes the basis for the Fault Isolation
    functionality.  
    
    And it's okay to say, "We require Management Modules to implement the
    TEST PATH function for us to answer that question", because the answer
    is important to providing the complete network management solution.
    
    -Matt.

    Giuseppina,
    
    The DECnet FDA gives you a Netpath-like facility, but not in a
    graphic fashion... Use the "Perform Path Trace" function.
    
    Philippe.
    
    P.S. What are the plans for the release of the FDA ? I heard it was on
    hold for some reason....

    Will TCP/IP FDA give path tracing ability?  Since MSU and HP node
    manager have it, it becomes a competitive issue.
    
    bill

    
        Will TCP/IP FDA give path tracing ability?  Since MSU and HP node
        manager have it, it becomes a competitive issue.
    
    >
    > Yes, we plan on incorporating the path tracing capability of
    > traceroute utility into a PERFORM PATHTRACE directive on the
    > MCC director. The plan is to use the public domain software and
    > have it installed on the U*IX node from which the path trace is
    > to start. It will be invoked remotely from the MCC director in
    > the same manner as we invoke remote diagnostic scripts, namely
    > using a daemon we provide for installation on U*IX systems.
    >
    > We'll then format the output on the MCC director.
    >
    > Alan

Does FDA  path tracing handle Phase V and, equally important, mixed Phase IV
and Phase V routers running a mixture of RV and LS routing algorithms?

Graham

    
    Thanks for all your feedbacks.
    
    I hope to see this functionality ASAP, because in a very complex
    network it is a needed support for an effective fault diagnostic.
    
    When a path changes in a DECnet Phase IV/DECnet Phase V/ TCP-IP
    network, it will probably produce a performance degradation or something 
    like this. It becomes very important to find it quickly (and I think that
    the graphics display is better) in order to apply some resolution
    actions (for example, circuit cost's changes...)
    
    In any case, it's important to know that we (DEC)  have some plans to
    implement it in the DECmcc Director. This will avoid an useless
    investement in a specific FM from the customer perspective.
    
    Giuseppina

    re .7
    
    The FDA entity model was "architectually constrained" to be a
    subordinate entity to the DECnet IV AM mostly due to interactions with
    the pending V1.1 Iconic PM.  The consequenses were not deemed
    sufficient when map interoperation was involved.
    
    Alas, no Phase V, no Mixed Phase IV and V.
    
    Kevin
    

    What about internet?  Can FDA deal with that?  I hope the
    answer isn't the same as it was for Phase V, Phase V needs an FDA 
    badly! Can you feel my blood pressure rising?
    I don't understand at all why FDA was subordinate to Phase IV entity,
    unless all of FDA's functionality was specific to Phase IV networks.

Ben-

Doesn't .6 answer the question in .10?  If so, the answer is yes.

-- Erik

    There is currently in development a TCP/IP Diagnostic Assistant which 
    as stated in .6 will handle path tracing in the TCP/IP space. It also
    has remote diagnosis capabilities of commonly occurring problems in a
    TCP/IP network environment. Things like NFS problems, Telnet problems
    and others. The product spec is/has been availabble for public review
    and can be copied from ASD::SYS$PUBLIC:TCPIP_DA_FS.PS;
    
    	-Alan

    
    The DECnet path trace that Wally mentioned (.2?) will manage path
    tracing in a mixed DECnet phase 4/5 environment.  Again, don't hold
    your breath on its being available with V1.2.
    
    There is a ton of work going on with enhancing the graphical
    capabilities of DECmcc in general, and FDA and its pathtrace will be
    taking advantage of as much of that as possible as quickly as possible.
    
    Dynamic pathing?  No, this isn't targetted at that.  This tool is
    intended to present interesting DECnet information regarding the path:
    circuits in use, costs associated, and some phase 5 specific info
    concerning the equal cost routers scattered around.  This takes time, 
    and managing it dynamically is expensive, to say the least.
    
    At first pass, no attempt is being made to explore all the possible
    routes in a phase 5 environment, just the first entry in each table.
    You can mechanically follow the rest if necessary.  This allowed us to
    bound the problem to manageable levels and present interpretable
    information to the user.  On the Easynet, the phase 5 routing
    possibilities rapidly make me dizzy.  We expect that following one of
    the cheapest DNA5 routes will provide most of the information the user
    needs and intend to ensure that it provides enough information so that
    the user can explore alternatives.
    
    Our first goal is to get the path information into DECmcc.  We have
    been discussing graphical presentation strategies and are directing our
    efforts in a direction that should make "sizzling" presentation easy.
    
    Our intent is that the IP pathtrace and the DECnet pathtrace have as
    much in common as possible, presentation and request-wise.
    
    All of this discussion has been based on logical networks, and may not
    be closely related to the underlying hardware:  DECnet doesn't know
    where the bridges are, and the pathtrace right now will be constrained
    to things that DECnet does know.
    
    Hope this makes some sense.
    
    -Jim Carey
    
    

.13 sounds  good.   When  setting  priorities for this please try to bear in
mind  that there are simple tools (e.g.  DCL command procedures) that can be
used  today  for Phase 4 but no such tools exist for Phase V and that having
the  information  available *in any form* is much better than having to wait
for 6 months and then getting a flashy display.  

The need  for simple, static path tracing in the Phase V environment is very
urgent.   I  fully  support  shipping  whatever you can as soon as possible:
static only, no equal cost paths are restrictions we can live with.

Now some fantasising about the future...

You may  want  to  consider  that there are two completely different ways to
look  at this "path trace" function.  For the relatively simple environments
we  are  familiar  with  today  they  are  equivalent  but  for the horrible
multiprotocol environments of tomorrow they are different.

The first  view of the path is that derived from the routing protocols.  For
example  you  could show the path that OSPF believes and the path that IS-IS
believes.   This  is  dependent  on the routing protocol, not on the type of
data.   So, IS-IS calculates one path which is then used for IP, OSI, DECnet,
IPX,  AppleTalk,  ....  This function isn't a "DECnet" path trace or an "IP"
path  trace,  it is an "OSPF" path trace or an "IS-IS" path trace.  However,
this  is what you are showing today using the DECnet path trace function: it
is really the DNA Phase IV routing path trace function.

The second  view of the path is that seen by a particular packet injected at
a  particular point in the network.  E.g.  what path would be taken by an IP
packet  sent  from node A to node B, with TOS X and security option Y? Or an
AppleTalk  packet  sent  from  node  M to node N? This differs from the view
above  because  different  routers  may  give  priority  to information from
different routing protocols (router R1 may prefer OSPF routes but R2 prefers
IS-IS routes, they may even make different decisions based on the options in
the packet).

These two  views  typically  make use of different databases in the routers.
The  first  uses the databases for the routing protocol, the second uses the
forwarding  database.   In  our  current  products  those  two databases are
confused  but  our competitors clearly distinguish them.  They are typically
accessed using different network management commands (if they are accessible
at  all).   For a better understanding of the significant problems caused by
trying  to merge these two views into one see one of the papers on how to do
multiprotocol routing.  It is a difficult and complex problem.

Note that  in  both  cases  the tools need to be able to handle routers with
different  management  protocols  in  the  path.   Some  will only implement
standard  SNMP  MIBs,  others  may use SNMP MIB extensions, others use CMIP,
others  use  NICE,  etc.  The manager, of course, would rather not deal with
the  difference when trying to worry about path determination! Handling that
stuff  transparently  seems  like  one  major  way  that  MCC  can  beat the
competition:  because  the  director framework provides such a big advantage
for dealing with the multi-protocol world.

Graham

    For a future functionality, I second somewhat Grahams proposal, there are 
    two views of the paths in the network, but IMHO, the different ones are
    of major interest.
    
    The one according the set up of the network and second the actual path 
    taken by the packets.

    This is different from Grahams view. I'm unsure what would searching
    for discrepancies in the router data bases and forwarding data base
    give us, other then verification of implementation correctness.
    There should be 1 to 1 relation between the two.
    It might be an interesting item but this is not what usually breaks.

    On the other hand, differences in an actual path ( which is anyway a 
    reflection of an actual state of forwarding db and dbs used to
    calculate forwarding db) and the paths as intended by the network 
    manager through costs and topology design is of great interest.

    Strange path are usually signs of overload, congestion or breaking of
    configuration rules. Usually, things don't break at once, first
    symptoms could be unintended paths, even without performance side
    effects.

    These problems are really common. 

    Thus a tool that could test consistency of a path as design against
    network reality could be a great "advance warning " tool.

    It would require a model of Network Layer inside DECmcc, something that
    would also cure and solve lots of other problems.
    
    			wlodek

I agree  with Wlodek that comparing actual paths against intended paths is a
useful thing to do.  However, he slightly misses the point of my distinction
between  routing  databases and forwarding databases.  It isn't really to do
with verifying implementation correctness, it is to do with dealing with the
fact that merging information from multiple sources is very difficult to do.

In modern multiprotocol routers there is a distinction which didn't exist in
Phase  IV  (or  even,  really  in  the WANrouters).  This is the distinction
between  the  multiple  views of the network (each view maintained by one of
the routing protocols) and the (single) forwarding database.

Consider, for  the  moment,  an  IP  router  that  implements  three routing
protocols.   Say, IS-IS, RIP and OSPF.  Each routing protocol constructs its
own  view  of  the  network.   It is does it completely independently of the
other  protocols,  considering  only  those  nodes  and links which are also
running its protocol.  

These network  views  overlap  (they  have  the  router we are looking at in
common  at  least!)  but  do not necessarily include the same nodes or links
(e.g.   if  some routers run RIP and IS-IS but not OSPF).  These "views" are
fed  into  some  process  which  decides, for each remote node (and possibly
other  factors  like  Type  of  Service  and Security options) which routing
protocol's information to believe and use.

One problem  that  can  occur  is when the manager has configured that final
selection  process  incorrectly.   This isn't an implementation bug, it is a
network  management  problem.   Fixing  it  requires  being  able to see the
topology  constructed  by  each  routing  protocol  and  also the route that
packets traversing the network actually take.

NETPATH-like tools  tell you the view of the network as seen by a particular
routing  protocol.  So, as I said in .14, it isn't a "DECnet" map or an "IP"
map  or an "Appletalk" map, it is an "IS-IS" map or an "OSPF" map or a "RIP"
map.   Ping/traceroute  tools  tell you the view of the network as seen by a
particular  packet,  of a particular protocol type, with particular options,
traversing the network.

Graham

    Graham, I'll take your word for it ! I always though that multiprotocol
    routers a la DEC ( PIS "pigs in a sack" , don't repeat that, I've just
    made that up ) are more integrated and didn't really exist in parallell
    but at separate areas.

    In any case, I see a need for yet another routing verification
    functionality .Since some time I work a lot on a real time trading
    network that has just unbelievable requirements for availability and 
    performance. Smallest error, like slightly longer paths due to some
    minor errors in implementation of routing at DECrouter 2000 ( or 250)
    and network is as good as down.

    Implementing routing protocol is very, very difficult.
    I'm sure that we have not yet found last routing bug in VMS DECnet or
    DECrouter 2000, even if we have run both implementations for years.
    There are simply so many possible dynamic situations that one can never 
    really fully test router implementations.

    But with network management commands on can have a look at pieces of
    routing databases at different routers and compare these.

    For phase 4, already knowing that all routers on a LAN can see
    each other can detect very common error conditions. Other simple checks
    can detect differences in area routing. We will probably build such
    tool for our network.

    I would guess that similar tool for a network of multiprotocol routers 
    would be very useful. Or maybe only chance . It maybe very difficult
    to find experts in several routing protocols and their interaction to
    fix difficult routing problems.

    				wlodek