On Fri, 2013-09-06 at 16:11 -0700, K7VE - John spake:
I see a lot more use for 44-Net then routing to 1200 baud AX.25 endpoints.
I agree, and I also wasn't using 1200 baud either. AX.25, like with IP is a protocol... and like water, protocols will travel at any path you wish to provide them. If not we wouldn't have AXIP.
Puget Sound (area around Seattle) is building a 150 mbit WiFi network for amateur radio called Hamwan (Hamwan.Org) they will be managing a /22 or better LAN with direct BGP.
While that may work for your region, it isn't practical here. Too many hilltops blocking line-of-sight.
Repeater linking of digital voice (D-STAR, EchoLink, IRLP, AllStar) -- these need minimized jitter (easier on minimized hops and encapsulation).
correct.
How about MPEG encoded amateur digital TV? Or file servers / Websites that can deliver content for Amateur Radio.
That's all well and good.
Cross linking HSMM-Mesh via net-44?
Real time monitoring and control systems... and so on.
This I do with the FlexNet network as well.
I think we need to think of all of the various IP based amateur radio related services that can be delivered and encapsulation besides AX.25, like D-STAR Digital Data, and one that mimics Ethernet on RF Lans.
... AND needs to be -cost effective- for the average ham. This too has been a battle for years; convincing the average joe-ham to invest a few hundred dollars for packet.
I have been coordinator for Utah (now for Western Washington), there are 3 main population centers with significant miles in between and large (1000s of square miles) areas to be covered. RF linking isn't always possible.
That's why someone in one geographical location can't speak for those in other geographical locations, so a generic solution isn't always possible.
Also, I want it to be trivial for a new station/LAN to configure and join. Using my model, end routers have two entries to support net-44. We could have pretty simple Linux or Router (like Mikrotik) setup scripts.
Again, what may be practical in your region isn't necessarily the proper solution for another.
The BGP requirements for Net-44 require a formal agreement with an ISP/Datacenter not just some engineer slipping the BGP in on the side.
Again, this requires the "human element", and convincing a data center owner/operator that you wish to broadcast a network via BGP tied down directly to them that they don't own. The key words here are: legal liability.
If successful in building the net, we could end up with 10s of thousands of entries in the munge text files.
Actually no. Perhaps in the dns files but not a munge text. In a large high-speed "hamwan", just the gateway entry point needs to be in the encap.txt - reference your earlier design draft. Ex: if I needed to route to your /22, then there should be *1* point of entry in your area I should need to pass my encapsulated traffic to. I see no need for such a high speed wan to require individual encap.txt entries.
I just think we can do better using modern methods.
I totally agree with you on this one.
I think the BGP router would largely reach out to LANs via easy to establish and secure VPN protocols.
In a perfect world - yes. This is not a perfect world. Even datacenters go bankrupt; ex: us datacenters in boston. Large datacenter, went dark overnight. Then what's the solution when BGP for that region no longer exists?