Thanks John for this structuring.

1. Your first hand question concerns interdomain routing, i.e. connectivity between AMPRNet and the rest of the address space.
I totally agree that AMPRNet should be multihomed, i.e. peering at more than one location.
My answer to your question mark is that, technically anything goes but from a strict policy point of view, leading to substantial advantages in terms of relations both with the global  Internet community (ICANN/IANA and all regional registries) and the gobal ham community (IARU and all regional and national leaues), AMPRNET will need an ASN. Splitting up will lead to disaster.

2. Your second hand question concerns intradomain routing, i.e. connectivity inside AMPRnet, in the 44/8 address space, including backbone links, access links and last (or rather first) mile links between AMPRnet nodes.

This question is at the core of what amprnet is and what yall(:-)/we would like it to be. Going back to www.ampr.org/amprnet.html the question is how we would like to edit the second sentence on that page.

My take on that is that I may be prepared to support changing the word "entirely" to "essentially" or just delete it, but changing anything else will take away not only our originality but also our challenge. This will also lead to disaster.

So. like 44/8 addresses, intradomain links should be under ham control, be it backbone, access or first mile links. A last mile link is a commercial concept, not a volunteer hobbyist ham operator concept. Consequently, you are per definition outside AMPRnet, or at least in an enclave, if you use a last mile link. This should be fine even without tunneling as long as you can reach AMPRNet destinations via intermediate operators not restricting the services that you want to carry on top of IP. If you end up in such trouble, you can try to change your path, advocate a change of operator policies calling on support from the entire community, or set up a first mile link, either directly to AMPRnet or to a more positive intermediate operators.

Any other takers of this view? The lynchpin is what we want AMPRnet to be. Technically, we can do anything, even with armchair operators and a good FAQ-support. There is a lot of professional experience in the community.

Bjorn

On 2012-06-05 23:24, K7VE - John wrote: 
(Please trim inclusions from previous messages)
_______________________________________________


I think there is a separation of concerns here.

On the one hand, I think people want to eliminate the bottle-neck/single point of failure that a single net 44.x.x.x routing point provides (UCSD).  This is where the discussion of delegation with or without a ASN is rooted. Can all of 44.x.x.x be multi-homed using multiple ASNs (owned by the providers) or do we need an ASN with multiple homes?

On the other hand, the "last mile" of net 44 might be a variety of transports including everything from 1200-baud AX.25 transports to multi-megabyte HSMM LANs.  Since this is Amateur Radio, often these last mile points of presence might include tunneling to upstream routers through "consumer" Internet connections.   For example, I have 25/25MB fiber to the house ISP service, but would likely be unable to get a BGP agreement from my ISP, though I already tunnel a Class-C network from a data center whose ASN is associated with my network.   This is the more likely scenario for LANs whether wired or over RF.   Also the network deployment may be temporary and ad-hoc, for example, an emergency response team might create a temporary LAN at a refugee camp and use RF to get back to the rest of Net-44, having a pre-provisioned tunnel that a router could open would facilitate connectivity.  At Hamvention® and SEAPAC the last couple of weeks, I brought a /27 subnet (off my Class-C) to the NW Digital Radio booth through a L2TP tunnel, one weekend in Dayton, OH and one weekend in Seaside, OR (over 2000 miles distance) -- before, between, and after that same router was at my house in Edmonds, WA providing connectivity to a D-STAR gateway and other services.  In each location the tunnel uses a dynamically allocated IP address for the remote to a static address at a data center for transport.

Also, a LAN manager may want to restrict routing by a firewall, allow outbound connections to the Internet, while restricting inbound connections to certain ports where the source address is in 44.x.x.x -- to limit traffic on RF for bandwidth management or content concerns.

So let's keep the two concepts in mind.  Major routing infrastructure (strategic) vs last mile (tactical).  One size does not fit all.

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Tue, Jun 5, 2012 at 1:44 PM, Bjorn Pehrson <bpehrson@kth.se> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
It seems as if  I misinterpreted your earlier message summarizing the offline discussions Brian.

Splitting up the address space by delegations of smaller chunks to commercial service providers with different AS-numbers and policies will lead to a historical mistake. Is that what you propose in your latest message ? or am I missing something now?

The way to create the trust and support for a radio amateur policy is to keep it together by keeping the delegations inside the community under an amprnet as-number facilitating multi-homing  without tunnels  connecting the delegations to the outside world anywhere via peering and transit agreements and keeping the challenge of internal connectivity between delegations as the driver of innovation that will take radio amateurism to the next level.

Managing interdomain peering and transit via bgp, announcing delegated pieces of the 44/8 via different border routers is not difficult and can be done with low cost solutions and open source routing software, much cheaper than most rigs.

In what way will the ham community benefit from splitting up the resource? In no way that I can see, but there is a lot to loose.

Bjorn 



_________________________________________
44Net mailing list
44Net@hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net