2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

List overview
Download

HECnet

hecnet@lists.dfupdate.se

17 participants
15570 discussions

Start a nNew thread

by bqt＠softjar.se

On 2011-11-28 19.07, Rok Vidmar wrote: Is there anyone in the Italian or Croatian networks using area 54 at the moment? I don't want to cause any difficulties if these networks become connected to HECnet. I can say nothing for Italian network, but for Croatian I can assure you it's Slovenian, does not use area 54 and can be squeezed to any area with ten or twenty unoccupied addresses. And since it seems area 3 is about to cleared up, you can keep using that, and have all 1023 addresses to play with, without any problems. Let me know if you need more... :-) Johnny

13 years, 7 months

1
0
0 0

by rok.vidmar＠gmail.com

Is there anyone in the Italian or Croatian networks using area 54 at the moment? I don't want to cause any difficulties if these networks become connected to HECnet. I can say nothing for Italian network, but for Croatian I can assure you it's Slovenian, does not use area 54 and can be squeezed to any area with ten or twenty unoccupied addresses. -- Regards, Rok

13 years, 7 months

1
0
0 0

by HECNET＠beyondthepale.ie

I'd say that you can probably take area 54. I should check with Tore, if he's still around, but since it hasn't been used in all this time, odds are that you are free to go. I knew Tore from the cctech list. In fact I gave him a Vaxstation 3100 which once lived in area 54 - maybe that's why he asked for that area :-) I haven't seen any communication from Tore for a long time now. Perhaps he has lost interest and moved on to other things? Is there anyone in the Italian or Croatian networks using area 54 at the moment? I don't want to cause any difficulties if these networks become connected to HECnet. On the subject of connecting to HECnet, would anyone be interested in being the other end of a Multinet link to my network? I have a fixed ip address which is up all the time and at least two of my DECnet capable machines are running all the time. I think I have all the needed bits and pieces of software and licenses. Sounds like we should be able to get you up and running in no time. Great stuff - thanks. Regards, Peter Coghlan.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

On 2011-11-28 18.08, Mark Benson wrote: On 28 Nov 2011, at 16:11, Johnny Billquist<bqt at softjar.se> wrote: Moving Chrissies machines from area 3 to area 6 help in no way with area 1. Just thought if we wanted to free Area 3 it was better than moving them to Area 1 which will just add to the confusion :) Ah. Sure. Good point. So, if Chrissie don't mind, then let's get that worked over. That's all on proviso that Chrissie's wants to move... Right. Could Chrissie and you, Mark, work this over and give me an update? Will see where it goes. Presumably it would mean I have to provide area routing 24/7? That's not an issue provided the power stays on at my place. My area router needs manual intervention to restart. That is up to you to decide upon. I have no opinion. :-) Johnny

13 years, 7 months

1
0
0 0

by bqt＠softjar.se

On 2011-11-28 17.58, Peter Coghlan wrote: What is the status of area 54? Tore Sinding Bekkedal requested it a long time ago, but it has never been used. I joined the list ages back with a view to connecting to HECnet but sometimes I seem to take a long time to get around to doing things :-) You are not alone. :-) I have several DECnet capable machines that were on a now defunct network which used area 54 and I put other machines I since aquired into the same area. With all this talk about connecting to other networks resulting in renumbering and so on, I wanted to express my interest in area 54 in case someone picks it at random to renumber their existing area into. On the other hand, perhaps someone is already using 54 somewhere and wishes to continue using it, in which case I will have to make other plans. I'd say that you can probably take area 54. I should check with Tore, if he's still around, but since it hasn't been used in all this time, odds are that you are free to go. On the subject of connecting to HECnet, would anyone be interested in being the other end of a Multinet link to my network? I have a fixed ip address which is up all the time and at least two of my DECnet capable machines are running all the time. I think I have all the needed bits and pieces of software and licenses. Sounds like we should be able to get you up and running in no time. Johnny

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by md.benson＠gmail.com

On 28 Nov 2011, at 16:11, Johnny Billquist <bqt at softjar.se> wrote: Moving Chrissies machines from area 3 to area 6 help in no way with area 1. Just thought if we wanted to free Area 3 it was better than moving them to Area 1 which will just add to the confusion :) So, if Chrissie don't mind, then let's get that worked over. That's all on proviso that Chrissie's wants to move... Could Chrissie and you, Mark, work this over and give me an update? Will see where it goes. Presumably it would mean I have to provide area routing 24/7? That's not an issue provided the power stays on at my place. My area router needs manual intervention to restart. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 7 months

1
0
0 0

by HECNET＠beyondthepale.ie

What is the status of area 54? I joined the list ages back with a view to connecting to HECnet but sometimes I seem to take a long time to get around to doing things :-) I have several DECnet capable machines that were on a now defunct network which used area 54 and I put other machines I since aquired into the same area. With all this talk about connecting to other networks resulting in renumbering and so on, I wanted to express my interest in area 54 in case someone picks it at random to renumber their existing area into. On the other hand, perhaps someone is already using 54 somewhere and wishes to continue using it, in which case I will have to make other plans. On the subject of connecting to HECnet, would anyone be interested in being the other end of a Multinet link to my network? I have a fixed ip address which is up all the time and at least two of my DECnet capable machines are running all the time. I think I have all the needed bits and pieces of software and licenses. Regards, Peter Coghlan.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by hvlems＠zonnet.nl

Her response was too Rok's request to juse area 3. Once her nodes are in area 6 you can merge the Croatian net without a problem. -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 28 Nov 2011 17:11:44 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network. On 2011-11-28 16.16, Mark Benson wrote: On 28 Nov 2011, at 15:06, Chrissie Caulfield<christine.caulfield at googlemail.com> wrote: That's a fair point. I only have a three nodes now, and only one of those is an actual piece of DEC hardware. So if someone else wants area 3 I'd be happy to change my nodes. If it helps keep the Area 1 confusion to a minimum I could 'adopt' Chrissie's machines into Area 6. My area router is pretty stable and I'm on a fixed IP with no bandwidth limits. Let me know if this is needed. Moving Chrissies machines from area 3 to area 6 help in no way with area 1. However, it might be a good idea to do that move anyway. It will free area 3, which it would appear is not needed by Chrissie, and it allows a new member to connect without having to do any renumbering. So, if Chrissie don't mind, then let's get that worked over. The node list for area 3 that I have looks like this: NODE NODE NAME ADDRESS JELTZ 3.2 ARTHUR 3.10 MARSHA 3.30 TRISHA 3.31 FORD 3.32 ROOSTA 3.34 ZARQON 3.35 ZAPHOD 3.55 FENTIB 3.60 Could Chrissie and you, Mark, work this over and give me an update? Johnny

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by hvlems＠zonnet.nl

The reason I mentioned the hello messages is that to me it seemed to work for the Italian net. Then I read Gerry's post again and perhaps other parameter changes were actually more effective. But that is a route I'm not too keen on. So that's why I came up withe idea to have a single connection between HECnet and RETROnet based on your program Johnny. That way the amount of traffic may be monitored and analysed. Say an average adsl uplink is 400 kbps (and the limiting factor) and half is used for DECnet, that is 200 kbps, or 25 kB/s. That's 100 packets per second. So that siingle link won't get flooded too quickly I guess. -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 28 Nov 2011 17:07:49 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network. On 2011-11-28 15.54, hvlems at zonnet.nl wrote: Owing to cellphine limitations I can only toppost and cannot edit the original message, sorry. :-) Let's assume the two networks are to be merged. Two major issues exist: area 1 and the modified "meshed" bridge program. Right. The situation with both area 1 setups is such that merging is as complicated as renumbering. So I guess that the area which has the fewest system owners involved ought to move. In a tie, the area with the fewest nodes ought to change. The only exception is a node which has no possibility to be modified, for any technical reaon, like no kits or docs. It's not really a case of either-or. A merging implies some renumbering and some merging. Exactly in which way is something we can continue arguing separately. The bridge software issue may perhaps be solved by using a single connection between two systems , both area routers, using the original hECnet bridge software. That would prevent flooding the links. That is more complex than you think, which is why I suggested having som VMS machines with multinet links between them as an easier solution. In order to have a working connection using the bridge, atleast one of the sides needs a separate ethernet segment dedicated for this. This means having a DECnet machine with two ethernet interfaces, connected to two separate ethernet segments. All of which is certainly doable, but it will require some extra setup that might be an issue. If the number of simultaneously active nodes becomes too high then I'd suggest throttling Hello messages. That is not a good idea. If you start tossing hello messages, you loose connectivity. The hello messages is how DECnet knows which nodes are reachable. Johnny Hans -----Original Message----- From: Johnny Billquist<bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 28 Nov 2011 15:09:27 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network. On 2011-11-28 13:34, hvlems at zonnet.nl wrote: 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. True. But it all boils down to how much effort it is worth. The practical side is obviously a lot more complex. Yes. 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. Right. And once you start renumbering, it makes little difference if we renumber within one area, or change to another area. It's about the same work. But my concern here is that it's way complicated to get everyone in area 1 on either side to renumber at a somewhat same timepoint. And without that, we face larger disruptions for a longer time. Renumbering one area is one thing. Modifying DECnet exec, line and/or circuit parameters is something else again. Hmm. Right. Since the italians are tweaking all kind of parameters, it might be a real issue to get everyone on the HECnet side to tweak them in a consistent and working way. And a bridge is really not the way to go to get a really huge network. Ethernet segments that become really big will cause a *lot* of broadcast traffic going everywhere. It grows with the square of the number of connections, more or less. The more I think of it, the more I suspect that hooking the italian DECnet straight to HECnet through a bridge is not a good idea, from the italian side. We really need a router in between, to not swamp them with traffic. 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. Indeed. You are as bad as Saku... ;-) 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. My main worry would not be performance, unless we go down TCP, in which case it will be a real problem. For UDP, if something along the way can't handle the traffic, UDP packets will be dropped, which is good. DECnet have mechanisms to recover lost packets, and will slow down and retry. TCP does all of that itself, which means that if a downstream node can't handle the traffic, you will get TCP congestion, which will block TCP writes, or else give write errors at the source. And you'll have a whole backlog of data in the queue that will eventually be delivered, but it will totally mess up the DECnet timers and retransmits. A meshed solution will not really improve performance, unless you also implement dynamic rerouting, so that it can send packets the shortest path to destinations. Otherwise it is just more of a stability enhancement, since if one link is down, there is another to use. However, this is the interesting question: how does the implementation done figure out when to switch to an alternative link? You do not want to have two links active at the same time, since then you create a loop, which is the *very bad thing* I don't want. Johnny 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. .

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

On 2011-11-28 16.16, Mark Benson wrote: On 28 Nov 2011, at 15:06, Chrissie Caulfield<christine.caulfield at googlemail.com> wrote: That's a fair point. I only have a three nodes now, and only one of those is an actual piece of DEC hardware. So if someone else wants area 3 I'd be happy to change my nodes. If it helps keep the Area 1 confusion to a minimum I could 'adopt' Chrissie's machines into Area 6. My area router is pretty stable and I'm on a fixed IP with no bandwidth limits. Let me know if this is needed. Moving Chrissies machines from area 3 to area 6 help in no way with area 1. However, it might be a good idea to do that move anyway. It will free area 3, which it would appear is not needed by Chrissie, and it allows a new member to connect without having to do any renumbering. So, if Chrissie don't mind, then let's get that worked over. The node list for area 3 that I have looks like this: NODE NODE NAME ADDRESS JELTZ 3.2 ARTHUR 3.10 MARSHA 3.30 TRISHA 3.31 FORD 3.32 ROOSTA 3.34 ZARQON 3.35 ZAPHOD 3.55 FENTIB 3.60 Could Chrissie and you, Mark, work this over and give me an update? Johnny

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

On 2011-11-28 15.54, hvlems at zonnet.nl wrote: Owing to cellphine limitations I can only toppost and cannot edit the original message, sorry. :-) Let's assume the two networks are to be merged. Two major issues exist: area 1 and the modified "meshed" bridge program. Right. The situation with both area 1 setups is such that merging is as complicated as renumbering. So I guess that the area which has the fewest system owners involved ought to move. In a tie, the area with the fewest nodes ought to change. The only exception is a node which has no possibility to be modified, for any technical reaon, like no kits or docs. It's not really a case of either-or. A merging implies some renumbering and some merging. Exactly in which way is something we can continue arguing separately. The bridge software issue may perhaps be solved by using a single connection between two systems , both area routers, using the original hECnet bridge software. That would prevent flooding the links. That is more complex than you think, which is why I suggested having som VMS machines with multinet links between them as an easier solution. In order to have a working connection using the bridge, atleast one of the sides needs a separate ethernet segment dedicated for this. This means having a DECnet machine with two ethernet interfaces, connected to two separate ethernet segments. All of which is certainly doable, but it will require some extra setup that might be an issue. If the number of simultaneously active nodes becomes too high then I'd suggest throttling Hello messages. That is not a good idea. If you start tossing hello messages, you loose connectivity. The hello messages is how DECnet knows which nodes are reachable. Johnny Hans -----Original Message----- From: Johnny Billquist<bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 28 Nov 2011 15:09:27 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network. On 2011-11-28 13:34, hvlems at zonnet.nl wrote: 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. True. But it all boils down to how much effort it is worth. The practical side is obviously a lot more complex. Yes. 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. Right. And once you start renumbering, it makes little difference if we renumber within one area, or change to another area. It's about the same work. But my concern here is that it's way complicated to get everyone in area 1 on either side to renumber at a somewhat same timepoint. And without that, we face larger disruptions for a longer time. Renumbering one area is one thing. Modifying DECnet exec, line and/or circuit parameters is something else again. Hmm. Right. Since the italians are tweaking all kind of parameters, it might be a real issue to get everyone on the HECnet side to tweak them in a consistent and working way. And a bridge is really not the way to go to get a really huge network. Ethernet segments that become really big will cause a *lot* of broadcast traffic going everywhere. It grows with the square of the number of connections, more or less. The more I think of it, the more I suspect that hooking the italian DECnet straight to HECnet through a bridge is not a good idea, from the italian side. We really need a router in between, to not swamp them with traffic. 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. Indeed. You are as bad as Saku... ;-) 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. My main worry would not be performance, unless we go down TCP, in which case it will be a real problem. For UDP, if something along the way can't handle the traffic, UDP packets will be dropped, which is good. DECnet have mechanisms to recover lost packets, and will slow down and retry. TCP does all of that itself, which means that if a downstream node can't handle the traffic, you will get TCP congestion, which will block TCP writes, or else give write errors at the source. And you'll have a whole backlog of data in the queue that will eventually be delivered, but it will totally mess up the DECnet timers and retransmits. A meshed solution will not really improve performance, unless you also implement dynamic rerouting, so that it can send packets the shortest path to destinations. Otherwise it is just more of a stability enhancement, since if one link is down, there is another to use. However, this is the interesting question: how does the implementation done figure out when to switch to an alternative link? You do not want to have two links active at the same time, since then you create a loop, which is the *very bad thing* I don't want. Johnny 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. .

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by md.benson＠gmail.com

On 28 Nov 2011, at 15:06, Chrissie Caulfield <christine.caulfield at googlemail.com> wrote: That's a fair point. I only have a three nodes now, and only one of those is an actual piece of DEC hardware. So if someone else wants area 3 I'd be happy to change my nodes. If it helps keep the Area 1 confusion to a minimum I could 'adopt' Chrissie's machines into Area 6. My area router is pretty stable and I'm on a fixed IP with no bandwidth limits. Let me know if this is needed. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by christine.caulfield＠googlemail.com

On 28/11/11 14:35, Mark Wickens wrote: On 28/11/11 14:17, Rok Vidmar wrote: Multinet tunnels are definitely ok, and are used by some people already. Area 3 is currently claimed by Christine Caulfield, so we need to work something out. OK, where do I move? My guess is 100 addresses will do for the next century or so. It would be nice to get you onboard... Thanks! -- Regards, Rok Would be worth checking with Chrissie if she still has any active nodes - I took a load of DEC gear off her a couple of years ago, and AFAIK she's not active in linux decnet any more. That's a fair point. I only have a three nodes now, and only one of those is an actual piece of DEC hardware. So if someone else wants area 3 I'd be happy to change my nodes. -- Chrissie

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by hvlems＠zonnet.nl

Owing to cellphine limitations I can only toppost and cannot edit the original message, sorry. Let's assume the two networks are to be merged. Two major issues exist: area 1 and the modified "meshed" bridge program. The situation with both area 1 setups is such that merging is as complicated as renumbering. So I guess that the area which has the fewest system owners involved ought to move. In a tie, the area with the fewest nodes ought to change. The only exception is a node which has no possibility to be modified, for any technical reaon, like no kits or docs. The bridge software issue may perhaps be solved by using a single connection between two systems , both area routers, using the original hECnet bridge software. That would prevent flooding the links. If the number of simultaneously active nodes becomes too high then I'd suggest throttling Hello messages. Hans -----Original Message----- From: Johnny Billquist <bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Mon, 28 Nov 2011 15:09:27 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Integrating with the Italian network. On 2011-11-28 13:34, hvlems at zonnet.nl wrote: 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. True. But it all boils down to how much effort it is worth. The practical side is obviously a lot more complex. Yes. 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. Right. And once you start renumbering, it makes little difference if we renumber within one area, or change to another area. It's about the same work. But my concern here is that it's way complicated to get everyone in area 1 on either side to renumber at a somewhat same timepoint. And without that, we face larger disruptions for a longer time. Renumbering one area is one thing. Modifying DECnet exec, line and/or circuit parameters is something else again. Hmm. Right. Since the italians are tweaking all kind of parameters, it might be a real issue to get everyone on the HECnet side to tweak them in a consistent and working way. And a bridge is really not the way to go to get a really huge network. Ethernet segments that become really big will cause a *lot* of broadcast traffic going everywhere. It grows with the square of the number of connections, more or less. The more I think of it, the more I suspect that hooking the italian DECnet straight to HECnet through a bridge is not a good idea, from the italian side. We really need a router in between, to not swamp them with traffic. 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. Indeed. You are as bad as Saku... ;-) 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. My main worry would not be performance, unless we go down TCP, in which case it will be a real problem. For UDP, if something along the way can't handle the traffic, UDP packets will be dropped, which is good. DECnet have mechanisms to recover lost packets, and will slow down and retry. TCP does all of that itself, which means that if a downstream node can't handle the traffic, you will get TCP congestion, which will block TCP writes, or else give write errors at the source. And you'll have a whole backlog of data in the queue that will eventually be delivered, but it will totally mess up the DECnet timers and retransmits. A meshed solution will not really improve performance, unless you also implement dynamic rerouting, so that it can send packets the shortest path to destinations. Otherwise it is just more of a stability enhancement, since if one link is down, there is another to use. However, this is the interesting question: how does the implementation done figure out when to switch to an alternative link? You do not want to have two links active at the same time, since then you create a loop, which is the *very bad thing* I don't want. Johnny 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. . -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by mark＠wickensonline.co.uk

On 28/11/11 14:17, Rok Vidmar wrote: Multinet tunnels are definitely ok, and are used by some people already. Area 3 is currently claimed by Christine Caulfield, so we need to work something out. OK, where do I move? My guess is 100 addresses will do for the next century or so. It would be nice to get you onboard... Thanks! -- Regards, Rok Would be worth checking with Chrissie if she still has any active nodes - I took a load of DEC gear off her a couple of years ago, and AFAIK she's not active in linux decnet any more. Mark.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by rok.vidmar＠gmail.com

Multinet tunnels are definitely ok, and are used by some people already. Area 3 is currently claimed by Christine Caulfield, so we need to work something out. OK, where do I move? My guess is 100 addresses will do for the next century or so. It would be nice to get you onboard... Thanks! -- Regards, Rok

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

On 2011-11-28 13:34, hvlems at zonnet.nl wrote: 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. True. But it all boils down to how much effort it is worth. The practical side is obviously a lot more complex. Yes. 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. Right. And once you start renumbering, it makes little difference if we renumber within one area, or change to another area. It's about the same work. But my concern here is that it's way complicated to get everyone in area 1 on either side to renumber at a somewhat same timepoint. And without that, we face larger disruptions for a longer time. Renumbering one area is one thing. Modifying DECnet exec, line and/or circuit parameters is something else again. Hmm. Right. Since the italians are tweaking all kind of parameters, it might be a real issue to get everyone on the HECnet side to tweak them in a consistent and working way. And a bridge is really not the way to go to get a really huge network. Ethernet segments that become really big will cause a *lot* of broadcast traffic going everywhere. It grows with the square of the number of connections, more or less. The more I think of it, the more I suspect that hooking the italian DECnet straight to HECnet through a bridge is not a good idea, from the italian side. We really need a router in between, to not swamp them with traffic. 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. Indeed. You are as bad as Saku... ;-) 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. My main worry would not be performance, unless we go down TCP, in which case it will be a real problem. For UDP, if something along the way can't handle the traffic, UDP packets will be dropped, which is good. DECnet have mechanisms to recover lost packets, and will slow down and retry. TCP does all of that itself, which means that if a downstream node can't handle the traffic, you will get TCP congestion, which will block TCP writes, or else give write errors at the source. And you'll have a whole backlog of data in the queue that will eventually be delivered, but it will totally mess up the DECnet timers and retransmits. A meshed solution will not really improve performance, unless you also implement dynamic rerouting, so that it can send packets the shortest path to destinations. Otherwise it is just more of a stability enhancement, since if one link is down, there is another to use. However, this is the interesting question: how does the implementation done figure out when to switch to an alternative link? You do not want to have two links active at the same time, since then you create a loop, which is the *very bad thing* I don't want. Johnny 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. . -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

On 2011-11-28 13:26, Rok Vidmar wrote: In truth, HECnet and the Italian DECnet network are not alone: we were made aware of at least another similar Croatian-based project named SLON (the Croatian word for elephant and also the name of the SLOvenska Network in the SPAN/HEPnet time-frame). They started experimenting with Multinet tunnels ... I am the guy from SLON (responsible for the name), which is Slovenian based network, to which some nodes in libraries in the rest of former Yugoslavia were added, some of them were indeed located in Croatia. We started in '85 or so, a zoo of research institutes, universities, banks, companies, ... so we quickly learned the importance of security, painlessly though. VAXes were in majority, some RSXes and a 10. We used mix of leased lines, X.25, Multinet and Multinet-CMUIP tunnels. Good days saw 200-300 nodes online in early 90s with some 50 persisting till the turn of the century. We almost immediately moved to area 3 with area 2 reserved for DecServer uploads and area 1 reserved for Quiche Eaters, then populated areas 4 to 14 and for some years we were connected to the international meteorological DECnet network in area 53 to accommodate Slovenian nodes there. Those days are now gone, it seems that my 3 node net is all that remained. I would like to join HECnet which might lure some other guys in Slovenia to join us. Would area 3 and Multinet-Multinet tunnel be OK? -- Regards, Rok Hi, Rok. Multinet tunnels are definitely ok, and are used by some people already. Area 3 is currently claimed by Christine Caulfield, so we need to work something out. It would be nice to get you onboard... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by hvlems＠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. .

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by rok.vidmar＠gmail.com

In truth, HECnet and the Italian DECnet network are not alone: we were made aware of at least another similar Croatian-based project named SLON (the Croatian word for elephant and also the name of the SLOvenska Network in the SPAN/HEPnet time-frame). They started experimenting with Multinet tunnels ... I am the guy from SLON (responsible for the name), which is Slovenian based network, to which some nodes in libraries in the rest of former Yugoslavia were added, some of them were indeed located in Croatia. We started in '85 or so, a zoo of research institutes, universities, banks, companies, ... so we quickly learned the importance of security, painlessly though. VAXes were in majority, some RSXes and a 10. We used mix of leased lines, X.25, Multinet and Multinet-CMUIP tunnels. Good days saw 200-300 nodes online in early 90s with some 50 persisting till the turn of the century. We almost immediately moved to area 3 with area 2 reserved for DecServer uploads and area 1 reserved for Quiche Eaters, then populated areas 4 to 14 and for some years we were connected to the international meteorological DECnet network in area 53 to accommodate Slovenian nodes there. Those days are now gone, it seems that my 3 node net is all that remained. I would like to join HECnet which might lure some other guys in Slovenia to join us. Would area 3 and Multinet-Multinet tunnel be OK? -- Regards, Rok

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by bqt＠softjar.se

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.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by hvlems＠zonnet.nl

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.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by gerry77＠mail.com

On Sat, 26 Nov 2011 02:35:17 -0500, you wrote: 3) and from what I remember, they are entirely dynamic DNS based and thus had to make major changes to the bridge to even exist. The changes they made work just fine, BTW... Back then we were entirely dynamic and our network had a full mesh topology. Now we have both static and dynamic addresses and the network has a full mesh core plus some "forward legs" speaking only to the nearest core node. We had and we still have some bandwith and latency issues, especially on leaf nodes. Because of that, our standard setup has a 90 seconds hello timer (instead of the default 15 seconds). The same for the multicast LAT timer. We also had some UDP fragmentation issues with some ISPs, probably due to their sloppy IP router configurations, or something similar. That is, some ISPs had (and maybe have) problems transporting UDP payloads that cause the full UDP packet to exceed the standard Ethernet frame size. We absolutely do not know why, but we discovered it during long and boring trial-and-error sessions. Our solution was to reduce the DECnet buffer size from 1498 bytes down to 1456 or even 1428, so that a full DECnet frame plus the UDP packet overhead totals to something less than 1500 bytes. It's a tradeoff that pays very well on the side of DECnet reliability and robustness. HTH, G.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by gerry77＠mail.com

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.

13 years, 7 months

1
0
0 0

Integrating with the Italian network.

by gerry77＠mail.com

On Sat, 26 Nov 2011 06:37:02 -0800, you wrote: P.S. Does anybody have a list of the nodes on the Italian network? You may want to check http://decnet.ipv7.net In particular http://decnet.ipv7.net/nodetab-en.html for the node list and http://decnet.ipv7.net/soft-en.html for our modified bridge software. There is also http://decnet.ipv7.net/gatetab-en.html for Internet gateways to our network, complete with guest user names :) Note also that some other nodes may have guest access, even if not directly reachable from the Internet, such as the VAX/VMS V4.7 and the TOPS-10 nodes. G.

13 years, 7 months

1
0
0 0

Jump to page: