> Ok fixed. Thanks, looks good. Cached for reference.
> Tiles have dimensions so better then GPS, but if these 1000s of new sats move > in completely different general tiers around the earth, we can enumerate them > and add to the H3IP. Theres spare bits cause smaller the city size tiles are > irrelevant for this app - unlike the vehicle lisp app. In any case H3ID is > just 64bits. Okay. Did you want to algorithically imply the IP address from the H3ID and vice versa? That could avoid another lookup. And requires IPv6, but that is okay. So another issue. The IP address will change as the sat moves. That's okay becuase those H3IP addresses are not RLOCs and don't go in the mapping system. So we don't have sat mobility entropy. But now comes the questions is why does an xTR need to know the IP address of a satellite node? A GS-xTR can just send on RF-link and whatever satellite up there that receives signal can forward packet. If there are multiple satellites receiving the packet, we only need one to forward. This could look like a stub LAN where VRRP decides who is default router allowing multiple GS-xTRs to use the same satellite if they are in the same field of view. > I don't know how the RF works, but if we know at each given moment which > sat-mac is in which H3IP we can have the GSxTR source plot the segments. > Overlay can be a good way to drive a dynamic underlay, connecting the ground > IPs through the sky IPs. Anyway interesting domain if its not already solved. I think if you do the plot at head-end, you aren't going to get reachability if the path changes in packet mid-flight. You can get away with source-routing in an ISP network because the topology doesn't change that much and there aren't as many path options like there will be with satellite networks. So I think we should just send an encapsuluate packet up and let the satellite network routing (many approaches exist and are being used) do its job. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
