Subject: questions to netatalk

From: [email-masked] (Guenter Roeck)
Date: Fri, 27 Nov 92 12:05:43 MET

Hello,

I am an implementer of AppleTalk router software at Conware GmbH. After 
examination of the Michigan implementation netatalk 1.2.1 and comparison with 
the AppleTalk definitions in 'Inside AppleTalk' edited by Sidhu, Andrews and 
Oppenheimer, I noticed a lot of differences. In some cases it's not obvious to 
me why these changes were made and even if they are correct. It would be helpful
to me, if you sent back some comments to the following list of differences:

NBP:
        1. In NBP e.g. register packets are sent to the AppleTalk internet      
           address 0000.00 .I assume that these packets are handled by DDP as   
           local packets and no packets are sent out to any data link. Is this  
           assumption correct ?

RTMP:
        2. Bad entries are not deleted from the routing table at a RT-check.
        3. Bad entries and entries with a distance >= 15 are included in RTMP   
           data packets. Bad entries are sent with the distance given in the    
           routing table.
        4. A routing table entry does not have a port number associated with it.
        5. Only better routes are accepted from any neighboured routers.        
           AppleTalk Phase I (the book) also accepts routes with equal          
           distances.
        6. No worse route is accepted, if the routing table entry's gateway is  
           equal to the source address in the RTMP packet (and the ports are    
           equal).
        7. Split horizon is applied (split horizon is not defined in Phase I).
        8. Each router must read the source of a RTMP data or a RTMP response   
           packet if the receiving port isn't already configured with a nonzero 
           network number. This is not being done in netatalk. Thus, how is the 
           port being configured if it's not a seed router ?
        9. Only a timer of 30 seconds is used for both the validity and the send
           timer. Accordingly to the specification of Phase I the following     
           timer values must be used:
                validity timer          20 seconds
                send timer              10 seconds

        Point 2. could cause a large routing table, and together with point 3.  
        will result in large RTMP data packets. Also the exhaustive search      
        through the RT is more expensive in computing time.
        Furthermore, counting to infinity can occur in case of split horizon.   
        Therefore the distance of entries should be checked before updating     
        routing entries or no routing information may be sent about routes with 
        a distance greater than 14. Otherwise counting to infinity wouldn't     
        break.

ZIP:
        10. ZIP Takedown and ZIP Bringup are not handled.
        11. The ZIP Query-Retransmission timer is set to 30 seconds (Phase I
            defines 10 seconds).

Thanks in advance

                Konrad Juelg

--------------------------------------------------------------------------
Konrad Juelg  -  Conware GmbH                   Phone: (0049) 721-9495-0
  Internet: [email-masked]                    Fax:   (0049) 721-9495-146
--------------------------------------------------------------------------

---

From: Charles Clark <[email-masked]>
Date: Sat, 28 Nov 92 13:59:37 EST

> From:     [email-masked] (Guenter Roeck)

> examination of the Michigan implementation netatalk 1.2.1 and comparison with

etc.  This was mailed to us at Uof Michigan and replied to the original
author by wes.  Here is the content of his reply, FYI.

From:       [email-masked]
Subject:    Re: Request for comments to netatalk 1.2.1 
To:         JUELG <[email-masked]>
cc:         [email-masked]
Date:       Thu, 26 Nov 92 21:57:16 -0500

			----------------

> From:    JUELG <[email-masked]>
> To:      [email-masked]

Konrad, thanks for the comments.  You have obviously spent significant
time looking over the code.  I think that's great, so I'll try to take
as much care with my reply.

> NBP:
> 	1. In NBP e.g. register packets are sent to the AppleTalk
> 	   internet address 0000.00 .I assume that these packets are
> 	   handled by DDP as local packets and no packets are sent out
> 	   to any data link. Is this assumption correct ?

Right.  ATADDR_ANYNET.ATADDR_ANYNODE (0.0 on suns, 65535.0 on 4.4BSD
machines) is the configured loopback interface.  Currently, atalkd
manages the local machine's NBP database.  Some method was needed to
communicate with atalkd for name registration and deletetion.  We
picked a new NBP type, since that would localize the database control
in the same code as NBP lookups, etc.

We're currently considering putting the NBP database in the kernel, so
that when sockets go away, the NBP name is automatically deleted.

> 	2. Bad entries are not deleted from the routing table at a

This is true.  They are marked as deleted, however, and should not be
sent out (see below).

> 	3. Bad entries and entries with a distance >= 15 are included
> 	   in RTMP data packets. Bad entries are sent with the distance
> 	   given in the routing table.

Yup.  This is a bug.  There is actually a patch that corrects the
second problem, sending out entries with bogus distances.  I'm
surprised that you are the first to mention the former problem...

> 	4. A routing table entry does not have a port number associated

It has a gateway associated with it, so we can calculate the port.  (As
a matter of fact, the 1.3 version of atalkd has an interface list, a
gateway list, and a route list, each depending from the next higher
entry -- routes are under gateways, which are under interfaces.  This
way we can keep track of the full routing set for each router and can
immediately have an alternate route when a router goes down, and
implement split horizon routing at little cost.)

> 	5. Only better routes are accepted from any neighboured
> 	   routers.  AppleTalk Phase I (the book) also accepts routes
> 	   with equal distances.

Since on unix, there is no atomic modify for routes, to change the
route each time we receive a route of equal distance will cause holes
in our routing.

> 	6. No worse route is accepted, if the routing table entry's
> 	   gateway is equal to the source address in the RTMP packet
> 	   (and the ports are equal).

Good point.  We should be doing this.

> 	7. Split horizon is applied (split horizon is not defined in

Even tho it's not in the phase 1 spec, we do split horizon because it
makes too much sense.  As a matter of fact, we were doing split horizon
routing before phase 2 was released.

> 	8. Each router must read the source of a RTMP data or a RTMP
> 	   response packet if the receiving port isn't already
> 	   configured with a nonzero network number. This is not being
> 	   done in netatalk. Thus, how is the port being configured if
> 	   it's not a seed router ?

In 1.2.1 and earlier, we don't do auto-configuration net numbers.
Version 1.3 can auto-configure everything (both phase 1 and 2), and
*always* goes through auto-configuration in case there is a
configuration conflict with some other router.

> 	9. Only a timer of 30 seconds is used for both the validity and
> 	   the send timer. Accordingly to the specification of Phase I
> 	   the following timer values must be used:

>		validity timer		20 seconds

Yes.  The alarm should actually be 10 seconds.  If this is done, the
validity timer is then correct at 20 seconds (it is currently 60
seconds, two alarm cycles).

>	Point 2. could cause a large routing table, and together with
>	point 3.  will result in large RTMP data packets. Also the
>	exhaustive search through the RT is more expensive in computing
>	time.

Right.  As I mentioned, this is fixed in version 1.3.

>	Furthermore, counting to infinity can occur in case of split
>	horizon.  Therefore the distance of entries should be checked
>	before updating routing entries or no routing information may
>	be sent about routes with a distance greater than 14. Otherwise
>	counting to infinity wouldn't break.

There is a patch that fixes the problem of accepting routes with bad
distances.  I'm not sure what you're trying to say regarding counting
to infinity.  My understanding is that phase 1 guarentees that counting
to infinity will be a problem.  Split horizon works to fix the
problem.

>	10. ZIP Takedown and ZIP Bringup are not handled.

The implementation is that we don't accept Takedown and Bringup.  This
is primarily a security decision.

>	11. The ZIP Query-Retransmission timer is set to 30 seconds
>	    (Phase I defines 10 seconds).

As in the rtmp timers, the alarm should actually to 10 seconds, not 30
seconds.  This was especially problematic on our campus, since proteon
routers only send one tuple in ZIP replies.  Since we send as many
tuples as will fit in our ZIP queries, and only queue 10 packets at the
ddp layer, we would only get about 12 ZIP replies during each ZIP query
transmission.  Compared to the ~150 networks we had at the time, this
made convergence take a long time.

wes