[ax25-layer2] IP Routing

[Timothy J. Salo]

> Date: Mon, 19 Sep 2005 22:44:23 -0500
> From: <pete>
> Subject: RE: [ax25-layer2] IP Routing
> 
> > -----Original Message-----
> > From: Robert Bruninga [mailto:bruninga at usna.edu] 
> > If it is to change AX.25 to be incompatible with current use 
> > and to enforce such use, then I may have some issues with it...
> 
> I have been consistent in my desire to not change the AX.25 protocol.
> 
> > No problem with that, as long as it maintains backward 
> > compatibility to current use.
> 
> It may be backward compatible in some ways but not support some of the
> things which are currently supported such as source routing in UI frames
> and long distance routing (in essence, attempting to make AX.25 a layer
> 3 protocol).

Backward compatibility is, like the say, a bit like pregnancy: either
you are or you aren't -- there is no half way.

Your proposed or desired changes will create a version of AX.25 that
is incompatible with the existing standard and usage.

My simple answer is: this simply isn't going to happen.  First, you
have a lot of devices in use that simply aren't modifiable.  Some
devices, particularly TNCs, are no longer supported by the vendor
and so the vendor isn't going to invest any money in modifying the
microcode.  Furthermore, this source code is owned by the vendor,
and the vendor hasn't released it to the public, and so no one else
can modify it.  I understand that there are some devices that have
no unused memory, and so can't really be modified.  I also understand
that some devices are programmed in assembly language, and so it
will be expensive to modify them, even if you can find the programmer
who understands the code.  Second, no one is going to remove digipeating
from their products, whether they be commercial or open source.
Too many people use digipeating.

The most you could hope for would be a configuration option to disable
digipeating, but I suspect that even that is pretty unlikely.
 
> These things go against layer 2 designs and do not need to
> be supported.  The writers of the v2.0 spec recognized this and the
> writers of the v2.2 spec wrote out of the spec long distance digipeater
> routing.

The developers of the original AX.25 spec recognized the need for
a real routing protocol.  They also recognized that designing routing 
protocols is hard.  They provided an interim solution, digipeating,
until a routing protocol became available.

Trying to get rid of the interim solution, digipeating, before the
more satisfactory solution, one or more routing protocols, is available
is backwards.

The answer appears pretty simple [to me]: design, implement, and
demonstrate a routing solution that obviates the need for digipeating.
Then, and only then, does it make sense to even talk about whether
to eliminate digipeating.

-tjs