[HECnet] Integrating with the Italian network.

[hvlems at zonnet.nl]

We're all in the same boat, using a protocol, hardware and o/s'es from days long gome :-) so I assumed that shariing would be beneficial and thus desirable. 
The practical side is obviously a lot more complex. 
Every site starts with area 1. Merging them is not trivial. In our case even a simple solution like "one group adds 512 to its nodenumbers" won't work given the ranges in use.
Renumbering one area is one thing. Modifying DECnet exec,   line and/or circuit parameters is something else again. For the record: I operate 40 real VMS systems, two virtual ones and five or six pc systems that run decnet. That's a lot of work to maintain. 
What worries me most is the performance issue. The meshed concept is a good idea, so it seems, but might possibly be in need of an improved implementation. UDP is connectionless and hence less robust than TCP but it shouldn't drop data. 
So that needs attention IMO. 


Hans
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Mon, 28 Nov 2011 13:05:56 
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network.

Actually, connecting the italian guys shouldn't be that complicated.
If they just have one point with a fixed (or atleast somewhat static) IP 
address, we can hook up at that point. Neither side should need any 
other modifications.

The renumbering is another issue. Unfortunately, while still maybe 
simpler on our side, area 1 is still the one area with the most number 
of different stakeholders on this side as well. It is a bunch of people, 
apart from me... I've done something similar, giving out subranges to 
people in area 1.

I suspect a merge might actually be easiest. Move some machines around 
on individual basis and keep some machines around.

As for changing the address in RSX, yes, once the config have been 
changed, I need to restart DECnet. I might need to reboot as well. 
Either way, that is simple. It's just lots of work that needs to be done 
before we can do a merge.

But first we need to decide if this is something we want, before we 
start work.

By the way, it might actually be smarter to not bridge us together, but 
instead let two VAXen run a connection instead, since that will avoid 
the bridged ethernet from becoming silly large. Since Gerry indicated 
that traffic volumes are a concern, as well as packet size, the bridge 
is really not a good solution for them. If they can split their network 
into several sub-segments, they can drastically reduce network traffic, 
and by having a VMS machine with DECnet over IP used as a router in 
between, they will not increase the traffic at all, for most sites, if 
they were to hook up to HECnet.

I should check how they did the "full mesh" thing. Since this is one 
annoying problem with the bridge, if they have a good solution to it, 
maybe it would be something to implement. The normal "correct" solution 
would be to implement the spanning tree protocol in the bridge, but I've 
felt too lazy to do that before...

	Johnny

On 2011-11-28 12.08, hvlems at zonnet.nl wrote:
Gerry,
Thanks for the clear explanation of the retro DECnet setup. I agree with your evalluation of renumbering area 1, yours seems to have more system owners than HECnet's area 1.
Yes, in terms of planning it was a lot easier to modify just my own systems. The complexity of such a project increases sharply when the number of stakeholders goes up :-)
About the bridge program, I mis understood the DNS part: hence the reference to phase V. The IP part was understood and I still think it tries to solve issues that ought to be done elsewhere. I am a strong believer in the KISS principle.   Which is why I favor Johnny's original version.
Perhaps we can still merge the two, provided you guys want this and Johnny wants to move out of area 1.
Its not complicated just a lot of reboots.
I did very little with DECnet on RSX but I think a reboot is all that is needed.
Hans
-----Original Message-----
From: gerry77 at mail.com
Sender: owner-hecnet at Update.UU.SE
Date: Mon, 28 Nov 2011 02:59:45
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network.

On Sat, 26 Nov 2011 12:05:30 +0100, you wrote:

networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.

That's not our case. We just picked area 1 because it was the most "natural"
choice. At first many of us didn't bother about DECnet at all and choose the
first available value, i.e. 1.1. Then, when we started dreaming and thinking
about a network, we started choosing address ranges in the 1.1 to 1.1023
range: one location from 1.1 to 1.9, another from 1.10 to 1.19, and so on.
Each location (not always a physical one) was assigned to an administrator,
and when that administrator filled its ten-addresses range, it received an
additional one, not always contiguous to the previous. When the network
became reality we implicitly choose to keep that numbering standard.

We have also a few exceptions: the first was our Simh VAX/VMS V4.7 node that
earned 1.666 because was evil to set up to our needs; the other is 1.1010
for the TOPS-10 node which also got DIECI as its node name (because dieci is
the italian word for ten: compare it to decem in latin).

There was a time when we considered changing our area number to 39 (the
international dial code for Italy), but then there was really no need to do
that and some members of our network are somewhat difficult to reach and
speak with, so we would have ended with a mixture of areas 1 and 39, and
that led to the cancellation of the renumbering project.

When you, Hans, renumbered your systems, you were just one single person
renumbering his personal nodes, under your direct control. We are in a
situation which is more like asking the whole HECnet (or a major part of it)
to change numbers.

In another message on this thread I have posted a link to our node list. In
that list there is a column showing the administrator nickname for every
node. Well, that column does not tell the real story: there is a good number
of nodes administered by one person, but physically located remotely from
that person. Some nodes are active, but some others are switched off and do
come online from time to time, without prior advice and it's not so easy to
tell the relevant people to remember not to come online without prior
intervention from some of us in order to change the DECnet address. So, go
figure what would happen if someone comes online with e.g. the MIM address.

What I've read about the "enhancements" to the bridge program is yet another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Which is my way of saying that I'm not too fond of this "enhancement"...

I think you have misunderstood our DNS functionality. Our bridge just tries
to resolve bridge endpoint IP addresses, but it is completely DECnet
transparent, i.e. it does not and never did try to resolve DECnet node names
into DECnet addresses. That's a service specific to DECnet Phase V, as you
correctly appear to suggest.

If our bridge does not receive anything (that is neither data nor even a
hello packet) from an endpoint defined as dynamic, after a certain amount of
time it tries to resolve again the hostname of that endpoint only.

Because our bridges are transmitting and receiving most of the time, the
resolve routine gets called quite seldom, so the delay issues explained by
Johnny may be encountered as seldom as an IP address change, and we consider
it a honest "price" to pay to have automatic dynamic IP addresses working.

Bye,
G.


P.S. please, forgive any syntax or grammar error: I'm not English native.

.