Subject: [lisp] Fwd: New Version Notification for draft-farinacci-lisp-satellite-network-00.txt

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Apr 2022 10:51:18 -0700

Your comments are welcome.

Dino

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-farinacci-lisp-satellite-network-00.txt
> Date: April 1, 2022 at 10:49:20 AM PDT
> To: "Dino Farinacci" <[email-masked]>, "Padma Pillay-Esnault" <[email-masked]>, "Victor Moreno" <[email-masked]>
> 
> 
> A new version of I-D, draft-farinacci-lisp-satellite-network-00.txt
> has been successfully submitted by Dino Farinacci and posted to the
> IETF repository.
> 
> Name:		draft-farinacci-lisp-satellite-network
> Revision:	00
> Title:		LISP for Satellite Networks
> Document date:	2022-04-01
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/archive/id/draft-farinacci-lisp-satellite-network-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-farinacci-lisp-satellite-network/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-satellite-network
> 
> 
> Abstract:
>   This specification describes how the LISP architecture and protocols
>   can be used over satellite network systems.  The LISP overlay runs on
>   earth using the satellite network system in space as the underlay.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: Sharon Barkai <[email-masked]>
Date: Sat, 2 Apr 2022 16:29:14 +0300

Hi Dino,

Im not sure if it makes sense, but when we were in the satellite IP session in IETF, 
it was explained that:

- as satellite routers move around in orbit
- each assumes RLOC of sky sector its in

So it can be simple for a ground station XTR, 
to source plot the shortest sky grid path.

Each such path is good for a short while,
as these satellites keep moving.

But its relatively simple to track and predict -
if a sector is occupied and reachable from neighbor grid sector.

So naturally hierarchical hexagonal grid comes to mind :) hierarchy reflecting transceiver range.

Just a thought.        

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Apr 1, 2022, at 20:52, Dino Farinacci <[email-masked]> wrote:
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Apr 2022 08:43:45 -0700

> Hi Dino,

Thanks for the comment Sharon.

> - each assumes RLOC of sky sector its in

Yes, those are addresses for the satellite nodes. They are not RLOCs stored in the mapping system. The ground-station xTRs are the ones with the RLOCs that are stored in the mapping system and what the satellite underlay delivers packets to.

The spec does not propose to have LISP encapsulate to satellite nodes. The satellite network is a pure underlay.

Potentially a satellite node could be an RTR (but quite likely not reachable from a GS-xTR). But that is for future study.

> to source plot the shortest sky grid path.

Well a GS-xTR prepends an outer header with a destination-GS-xTR RLOC. That is the instruction for where the satellite nodes should deliver the packet. This is no different than a terrestrial underlay.

> as these satellites keep moving.

The source-route references in the spec requires a lot more design and thought. And IMO, is complex. I would say lets get the satellite network to deliver packets hop-by-hop at first pass.

> if a sector is occupied and reachable from neighbor grid sector.

If you say so. ;-)

> So naturally hierarchical hexagonal grid comes to mind :) hierarchy reflecting transceiver range.

The problem with using a source route of satellite node hops, is by the time you find the path, the links or sats are gone. There can be a lot of entropy in the system if you try to manage this on the ground-stations (head-end).

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Apr 2022 09:51:34 -0700

Resent correcting int-area. 

Dino

> On Apr 2, 2022, at 8:43 AM, Dino Farinacci <[email-masked]> wrote:
> 
> 
>> 
>> Hi Dino,
>

---

From: Sharon Barkai <[email-masked]>
Date: Sun, 3 Apr 2022 12:48:44 +0300

Tnx Dino, understood.

Just curious what you think, if XTR could know at any given moment which IP addressable (sky) grid cell has a satellite, could the overlay source such underlay segment routing path, or it will be just way to many headers? 

--szb
Cell: +972.53.2470068

> On Apr 2, 2022, at 18:44, Dino Farinacci <[email-masked]> wrote:
> 
> 
>> 
>> Hi Dino,
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Apr 2022 12:36:57 -0700

> Just curious what you think, if XTR could know at any given moment which IP addressable (sky) grid cell has a satellite, could the overlay source such underlay segment routing path, or it will be j…

Well if it knew that and the satellite's RLOC, then it could just LISP encapsulate to it. But the GS-xTR may not have connectivity to it. 

The GS-xTR could spray packets to say a few number of satellite RLOCs like we do for draft-ietf-lisp-predictive-rlocs. But in the predictive-RLOCs case we prune the spray-list when packets come back from RLOCs. This is likely not to be the case since there could be thousands of satellite nodes.

Dino

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 4 Apr 2022 13:27:26 +0300

I thought the tiles have RLOCs and theres a live applet that can tell you at any given sec which tile is occupied by a sat and becomes its RLOC.
But maybe i misunderstood the preso. 

--szb
Cell: +972.53.2470068

> On Apr 3, 2022, at 22:37, Dino Farinacci <[email-masked]> wrote:
> 
> 
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Apr 2022 10:37:35 -0700

> But maybe i misunderstood the preso. 

Copying the really nicely drawn diagram below for reference.

So if you wanted to do geographical addressing and map it to RLOCs that you could have connectivity to, that could work. This is a new idea (your idea) and we should think about it. This is how I envision it could be implemented by the LISP protocol:

(1) The H3 index-id is stored in mapping system as a distinguished-name EID.
(2) The EID maps to a RLOC-set which is a list of routable IP addresses inside a particular tile (at any resolution).

The assumption is, if you are in a larger resolution tile, you may have reachability to the RLOCs for the tiles within your resolution. The path a packet may take could (obviously) leave the tile resoltuion area so you are not guaranteed a  shortest topological path. RLOC-probing could test one-way latency and RTT to determine if the packet is leaving the area. With more distributed and decentrailzied wireless networks out there, there is a possibility packets can stay "within tile resolution".

One comment on the diagram below. Its just a presentation commemnt. If you draw the word "RLOC" next to a satellite, it implies it could be registered in the mapping system and therefore runs as a LISP xTR. Theoretctically this can be the case but, again, we are not proposing this for the early work on draft-farinacci-lisp-satellite-network.

Also, if you change "GS RTR" below to "GS xTR" then you have drawn the same diagram as the draft has. Making the label "xTR" means it can be any of ITR, ETR, pITR, pETR, and RTR. So more general.

So another question, if the GS-xTR and a satellite are in the same H3 resolution does it mean the satellite have the field of view of the GS-xTR. If that is the case, we may be able to explore this idea.

One more comment, maybe using GPS is better because you have 3-dimensionality where H3 is 2D. Comments? With 3D you can imply that one sat is in a closer orbit to earth than another sat.

Thanks for the comments,
Dino

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 4 Apr 2022 22:10:44 +0300

Ok fixed.

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.

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. 

--szb
Cell: +972.53.2470068

> On Apr 4, 2022, at 20:38, Dino Farinacci <[email-masked]> wrote:
> 
> 
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Apr 2022 14:01:19 -0700

> 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 ca…

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 underl…

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

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 5 Apr 2022 06:56:54 +0300

The problem is that i don't know too much about these new sat networks. They are supposed to offer coverage for undeveloped areas. Connecting UE xTRs, to proper internet router xTR. Maybe the operator wants to keep them as simple as possible  or as IP relays.

So potentially yes, no lookups, just algorithmic mapping mac to tile, and tile to IP. If this algorithm takes a micro sec, it should be good for a few seconds - tile size vs sat speed.

The problem of source routing this “GTP” tunnel “UE to UPF” xTRs is the number of headers.   
Perhaps it should be established every few seconds by the UPF xTR and labeled in the route. 

--szb
Cell: +972.53.2470068

> On Apr 5, 2022, at 00:01, Dino Farinacci <[email-masked]> wrote:
> 
> 
>> 
>> Ok fixed.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Apr 2022 08:54:39 -0700

> So potentially yes, no lookups, just algorithmic mapping mac to tile, and tile to IP. If this algorithm takes a micro sec, it should be good for a few seconds - tile size vs sat speed.

So why do you say "mac to tile". Do you see the satellite network as one layer-2 domain? I hope not.

> Perhaps it should be established every few seconds by the UPF xTR and labeled in the route. 

Yes, that is another problem.

Dino