Re: Should we share?
- To: email@example.com (Fred Goldstein)
- Subject: Re: Should we share?
- From: firstname.lastname@example.org (c.small-acacia-ele-student-90064116)
- Date: Fri, 2 Dec 94 10:10:32 EST
- Cc: email@example.com (TCP-group relay)
- In-reply-to: <199412011444.GAA22589@ucsd.edu>; from "Fred Goldstein" at Dec 1, 94 09:33:28 am
> Gary K8LT writes,
> >implementation work, despite known bugs and limitations. It would be
> >interesting to know the network topologies.
> >Is anyone interested in collaborating to try to implement the RSPF 2.2 spec?
> Someone in Australia currently has plans to begin an implementation
> quite soon. We've been discussing some of the technical issues via
> mail. I hope this does come to pass.
That person is me. I had my last exam on Wednesday and have had a closer
look at RSPF 2.2 spec, there's a message winging its way to you now about
What I'm looking for from this group is any suggestions or quirks that the
current implementation has. I'll be coming from a different direction when
I code it that the one currently in NOS.
I'm not after ways to change the spec as such or any protocol suggestions
but rather the behaviour or ideas for add-ons.
Examples could be:
I run a three port system. The route for 44.136.8/24 is via port A. When
a station, say 184.108.40.206, arps me on port B I send everything via port
A, except the arp reply.
Station xyz runs rspf and has public routes to every with all a quality of 1.
Is there a way of ignoring these naughty nodes?
I run RSPF and would dearly like it to work properly, so I want to do a good
job on it. My thesis (or final year project) is on writing this implementation,
amongst other things so you see that there is a lot of incentive for me to get
it right. Due to lack of hardware drivers, it looks like it will be written
for NOS, then ported over to Linux.
> RSPF 2.2 thus explicitly states that there are no subnets; rather,
> there are "node groups". These look the same to most routers, but
> when you get down to the local level, they have what we former DECnet
> users might call "layer 1 routing" among members of the node group.
> (Short horizons handle this.)
Reading the spec and having a think, it is more important to get rspf to
look at the layer 2 addresses, rather than layer 3. Sure you need to keep
in your mind the overall picture of we are doing all this to get layer 3
routes, but the only guarrantee you have that station X is on your same
frequency is if you see an ax.25 frame from it (digipeaters are the exception,
and wiretap may answer that). While it's early days yet with the modification
to NOS, not the actual rspf coding, I have a feeling that the ARP code is more
important that the iproute area.
- Craig vk2xlz