6 Jun
2012
6 Jun
'12
1:44 a.m.
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
<http://k7ve.org/blog> <http://twitter.com/#%21/john_hays>
<http://www.facebook.com/john.d.hays>
On Tue, Jun 5, 2012 at 1:44 PM, Bjorn Pehrson <bpehrson(a)kth.se
<mailto: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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net