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

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

Your comments are welcome. 

Thanks,
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: 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,
> 
> Thanks for the comment Sharon.
> 
>> 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
> 
> 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.
> 
>> So it can be simple for a ground station XTR, 
>> 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.
> 
>> Each such path is good for a short while,
>> 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.
> 
>> But its relatively simple to track and predict -
>> 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.
>> 
>> Just a thought.        
> 
> 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