Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers

Rob, I forgot to include you in my thanks, I appreciate your comments as well. - I'm not proposing that the Portal be ran on a 44 address. I'm stating that the Portal is not a necessary physical component for all possible networking solutions, albeit a logical one. In fact, the Portal is a Great help, but not NEEDED physically to ensure network connectivity (i.e. in comparison to a fiber cable extending to AMPRGW's NIC, or AMPRGW's CPU(s)). I also pose that if you consider the Portal in this manner, then both AMPRGW and the Portal must be online to maintain the AMPRNet "mesh." * - Solutions to simply make a hot-standby GW or a second RIP44 announcer could help here - Unless I don't understand the premise - I not grasping your premise that the Portal website somehow ensures [physical] connectivity of the nodes, AMPRGW (and our individual GWs) physically provide this, the Portal - their logical connection. Were AMPRGW or the Portal down/unavailable (or its email counterpart), no new nodes could join the 'AMPRNet mesh' dynamically. Likewise, in an IPENCAP tunnel mode using RIP44, AS Numbers don't apply (I agree). Again, I am proposing a test of another, second, routing schematic entirely (this would REQUIRE some ASN coordination amongst participants in the test or implementation, now or in the future - as there's many scenarios where the the Number couldn't be duplicated). * - Solutions include saving copies of the route table geographically local, this again is not 'real-time' nor dynamic. - Available DNS servers are listed on the Wiki, there are quite a few on AMPRNet. I'm not proposing that we not have 'some Internet tunnel.' I am proposing a TEST of something additional to IPENCAP tunnels w/ RIP44. - You stated: "I advise you to study the network topology before proposing to change it. Traffic to another amprnet node does NOT flow through AMPRGW." I'm aware of this; but you insist, that somehow, we're a full mesh (physically), despite not being able to send traffic in that manner without some master first bootstrapping the nodes (logically). Again, I'm just suggesting test of an alternative. - "This is not what defines a star versus a mesh...The pings I send to your gateway directly travel from my Internet connection to yours, NOT via AMPRGW." Correct again, I'm aware of this...so if we're a full mesh...I'm proposing a method where AMPRGW is not necessary (or not the single point of failure) for: a.) 'bootstrapping', b.) route announcements, c.) route updates, and d.) possibly even connection to the Internet AND e.) BGPed nodes. In fact, my proposal could eventually provide Internet without need for: i.) a single [point-of-failure] master GW and its logical 'network assembler' (the Portal), ii.) a multi-level subnet, or iii.) connection to Commercial Internet - "We use a multi-level subnet system here. We route the entire country subnet to a single gateway which has radio and VPN connectivity to users in the country. Those users can also have their own IPIP gateway when they like." That's really cool!!! This is also a very good solution!!! I don't think any regions in my area have a setup in that manner! - Lynwood KB3VWG