Re: [44net] My view to 44net's future

On Sat, Jul 11, 2020 at 3:06 AM Clive Blackledge via 44Net <44net(a)mailman.ampr.org> wrote: Hello, If another non-AMPRnet site/host on the internet insists on speaking HTTPS/SSL there's no way around this - unless of course one proposes proxying on the edge. But if we were to do proxying on the edge then what's the point of using/assigning public IPs within AMPRnet to begin with? This *could* be done, in theory. In fact a number of people are currently running such overlay networks and some (such as myself) are announcing/routing 44/9,44.128/10 prefixes on their overlay networks. However, there are a few things that need to be kept in mind when it comes to such a proposal. 1. It would require AMPRnet to operate its own AS. While this is *may* be possible to convince different peers in different upstreams to announce 44/9,44.128/10 prefixes on AMPRnet's behalf, this would ultimately end up causing more trouble than it's worth (from a network management standpoint). That's why for multihomed networks, such as the one being proposed here, the only realistic approach would be for AMPRnet to become its own AS rather than relying on other ASes to announce AMPRnet space. 2. The edge routers on this overlay network would most likely need to be configured as a iBGP full mesh so that they would all share the same view of the internet. Now, there may be ways around this. I myself spent two years trying various alternatives in order to run an overlay network of the sort being proposed here without doing iBGP. However, iBGP proved to be the lowest maintenance/least time consuming approach (which is probably why iBGP is the preferred approach for sharing routes between multiple border routers within a multihomed AS/AS with multiple peers). 3. It would require that AMPRnet establish/maintain a 24/7 NOC rather than relying on USCD's NOC as is currently the case. After all, peers wouldn't like it if there was no one there to pick up the phone/respond promptly to the email should there be some routing issue (such as flapping or worse). Nor would they tolerate this for long before simply depeering. In a related note, there really is no "grandfathering" when it comes to peering on the Internet. If a network decides to take a stricter policy when it comes to ROAs, for example, they usually do not simply exempt existing peers from these requirements just because they are existing peers. 4. Considering that this new AMPRnet would be worldwide in scope and considering that AMPRnet's prefixes are already assigned along regional lines (i.e.44/9 for US, 44.76/16 for US/TX etc.), converting AMPRnet into one big overlay network without at the same time creating a whole lot of inefficient routing would entail creating a fairly sophisticated routing policy on the edge. It would need to be a bit more sophisticated than simply advertising 44/9 and 44.128/10 at every border router. In short, what is being proposed here would entail a whole lot more BGP, not less. And it would require a great deal more maintenance and upkeep than is currently the case. It would mean less time for experimental activities and more time focused on upkeeping a massive global network. I think there is a bit of confusion here as to what an "SD-WAN" is. An "SD-WAN" generally refers to services that centralize and rationalize the management of network connections (including tunnels, LTE, MPLS - depending on the service being offered). They are usually provided by Tier 1s/larger Tier 2s who, IMHO, tend to use SD-WAN as a catch-all marketing term for all of their "modern" enterprise connectivity services which are not MPLS/DWDM/etc. and which can complement and/or serve as a replacement. SD-WANs are generally not substitutes for layer 3 routing protocols. They certainly are not a replacement for BGP. If AMPRnet prefixes are to be visible on the public internet then a BGP speaker somewhere will have to be advertising these prefixes. Right now AMPRnet's 44/9 and 44.128/10 prefixes are being advertised by UCSD's border router(s) (AS7377). If AMPRnet were to move in the direction proposed above, then as already noted, this would require a lot more BGP (and most likely an IGP as well to complement it). SD-WANs would not be a substitute for this. Rather than trying to turn AMPRnet into one big overlay ISP, I think the better approach would be to continue to assign /24+ prefixes to HAMs that have the resources to announce them and keep them on them on the internet - *but* to make these assignments with the clear understanding that these "BGP HAMs" will provide tunneling services to other regional/local HAMs (who are not doing BGP + far away from San Diego) - including carving out pieces (i.e. /27s, /28s etc) of their own /24+ prefixes and assigning them to "non-BGP HAMs", so to speak. This I think would meet the goal as proposed above, but without needing to create a massive/high maintenance overlay network/ISP. It would also maintain the experimental ethos of AMPRnet. The big overlay net/ISP thing would take away from this as we spent more and more of our time on all the "housekeeping" that would be required to maintain ISPs and walled gardens. - Erik KE5SAI