Why wouldn't they make it completely IPv6??? Steve On Thu, Oct 28, 2021 at 9:12 PM Dave Taht wrote: > I spent some time today looking over the job listings for clues ( > https://www.spacex.com/careers/index.html?search=linux ) BGP/ISIS > keeps cropping up. It really also looks like they are inventing their > own SDN along the way. And: their public BGP table has gained a bunch > of ipv4/21s lately with a few users reporting a routable IP for a few > days or weeks. I do hope they find a ipv4/12 somewhere or better, as I > think they've discovered CGNs are not particularly fun, and their > projected growth for the next year or two would be within that, (and > one fantasy I harbor is they peer with a bunch of outback BGP AS > holders with a "pro" service) > > I've been trying for a few years to get some industry interested in > leveraging 240/4 (at least within their CGN for dishy to dishy comms), > there's a preso on it at the upcoming ietf intarea: > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > I know that's kind of a blue sky thing, but all the code has been > working for years in both bsd and linux, as well as in multiple big > iron routers, amazon, and in openwrt (where we tested it first). Just > someone with balls and $s needs to step up to become a space RIR and > try to make those addrs more routable than we already have.... > > Anyway, good discussion on this thread!!! but all of you failed to > answer my humdinger question - *when* will they be able to route a > packet from new york to tokyo over the laser links? That kind of event > would be a world network latency record - right up there in > significance with the first inter-imp comms oct 29 1969: > > > https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg > > On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol wrote: > > > > I cannot add more than the real experts on the networking / topology > side, but on the lasers themselves, a question was raised about multiple > links. The only way to do it economically is to use a single optical train > per link (includes laser TX and photon detector, mirrors, power control, > attenuators, etc.). > > > > I raised the idea of an FSOC “flashlight” to what could be counted as > people in the top 10 worldwide list of experts in the field. Here, a beam > would be made wide enough to have multiple “clients”, as for radio sector > antennas. The idea was quickly discarded for a number of reasons, the > principal being that you are spreading the photons so much that not enough > would reach the other side, at least at any meaningful distance. > > > > Photon detectors that could work are in the scientific instrument > category, thus really expensive. > > > > From photos, we know that each satellite has at least two lasers, so we > can assume at least in-plane communications. > > > > Best, > > > > Mike > > On Oct 28, 2021, 11:01 +0300, Ulrich Speidel , > wrote: > > > > On 28/10/2021 7:29 am, Michael Richardson wrote: > > > > I guess the real question is: have you written the Hollywood Security > > Theatre > > script based upon this issues, and can I play the geek that explains > > this? :-) > > > > Sure! > > > > > > - Tell satellites where to send packets (in something along the > > > > lines of a > > > > long header, as in AX.25 for example). Then a sending ground station > > > > would > > > > need a complete almanach of the constellation and an idea as to > > > > where the > > > > receiving ground station is, and which satellite it would use for the > > downlink. Pros: The sending ground station can do all the number > > > > crunching on > > > > ground rather than space power. Cons: Header size costs bandwidth. > > > > > > From what I understood, Starlink shipped some kind of comodity SDN > capable > > chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes > > interpreted in hardware, and a path computation element on the ground > > should > > be able to deal with the calculation. > > > > It's a challenging situation perhaps because the network effectively gets > > rewired every few minutes, but ground based computation should be able to > > deal with the problem. > > > > > > That presumes that the ground station has complete topology information > > for the constellation, though. That includes knowing about defective > > satellites and lasers etc., birds deviating from assigned orbit. > > > > But in principle, I can see how that could work, yes. > > > > > > - Get the satellites to work out where stuff needs to be sent. If > > > > they were > > > > to use something like Bellman-Ford here, that would require an enormous > > amount of update traffic. Dijkstra would require complete topology > > information, which should in principle be computable from an > > > > almanach on the > > > > satellites. > > > > > > I think, but I might be wrong, that there is a pattern which repeats > > over and > > over again. Just need to update the mapping of which satellite is in > which > > position in the precomputed mesh. No need to send the entire mesh. > > > > > > Of course. Bellman-Ford & Co. all assume a network without such > > regularities. But you need to make use of those patterns in order to > > make things possible - whether you do source or hop-to-hop routing. And > > while the configuration of the network is indeed predictable at least > > for the near future, it's not simply repeating over and over again. The > > current constellation (if viewed in isolation) more or less runs in 95 > > minute cycles. Earth rotates under the constellation, so the teleports > > only return to the same position with respect to the constellation when > > multiples of the length of a sidereal day coincide with multiples of 95 > > minutes. Plus you may find that the Starlink constellation isn't > > perfectly regular either in its pattern. > > > > > > > > -- > > **************************************************************** > > Dr. Ulrich Speidel > > > > School of Computer Science > > > > Room 303S.594 (City Campus) > > Ph: (+64-9)-373-7599 ext. 85282 > > > > The University of Auckland > > ulrich@cs.auckland.ac.nz > > http://www.cs.auckland.ac.nz/~ulrich/ > > **************************************************************** > > > > > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw > > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink >