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

Sharon Barkai <sharon.barkai@getnexar.com> Mon, 04 April 2022 19:10 UTC

Return-Path: <sharon.barkai@getnexar.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F076E3A12B7 for <lisp@ietfa.amsl.com>; Mon, 4 Apr 2022 12:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=getnexar.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LyNtwt0Em57 for <lisp@ietfa.amsl.com>; Mon, 4 Apr 2022 12:10:50 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3586B3A128F for <lisp@ietf.org>; Mon, 4 Apr 2022 12:10:49 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id 123-20020a1c1981000000b0038b3616a71aso158154wmz.4 for <lisp@ietf.org>; Mon, 04 Apr 2022 12:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=KAQmeq/fWeE64I3HM9iNfLgO15gQfZzrebpt00wqbBE=; b=aALn+65t7LstrF1uDav+HCJBwd5dCEhsDLDnevnuGJ6JxXnrpxHoD8/4v9bpzZVxCX ZvINJDQjYPDDVCBkykAFjkF8p9/NZVmjxb2jvaMe8yuozuTnQ4KC2SAYNf42Q8lxGPrW FMNLNpQAo0WUxig3eEfgSyBsqfE/LCMwjTf1c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=KAQmeq/fWeE64I3HM9iNfLgO15gQfZzrebpt00wqbBE=; b=Zl7eNrdCq9W12Hq4XhH7Lys/Vi7snRZ2AvSbX0R75M7NIgUPxHBf6X4rUavOuzZ3xQ 3wozVrVGVZHvZ1Xxm5dd9jiKxBMyWT+U/qNLXaCOU6r4PypzkU4LYs5W9rciivRiiDrp SgQNzAmIkW932OXr3OvebEnNLlpdd9qyfODJr3NVnQIVcWYwjfA62JwNSdvmlRLyal6t aWTxl1SsmEnK5ayKXWzr1AJRznejpus7xFtI+ymTg53qDfPjX7WtxdCd5vvP17KmesZT y4fQJ2Dw9iAjhErqx6uaV90c5WYFV1WizOH7/HwwaM1HCCK5+hEIP5DrojYyLtfQDQQe 7Bcw==
X-Gm-Message-State: AOAM532RbRbDyS3f36t8k5o5pX7v1gJxQfmGWCzR+jspC53sXW9/5Qjm D9cLd2a61s3WvQWJ1nHs3/EBz53Ml2EEO77Xb+o+qj8rS2GE0nyJgBSOZvCZRvBA0kdOTw2/PQZ 4SWCocDBXcwjw0jcwouuEEZ4/GdqyXhW3QKejIu5y1YVlk+qoTlV42k/Qn2nsxLfnqtU=
X-Google-Smtp-Source: ABdhPJxqCEOY+XFTXRrOm+itXxYur7vMHSKrT7W2kysF8rjx/dUg0uBVavMSNALLIBXYdp8ss2o9EQ==
X-Received: by 2002:a7b:c844:0:b0:37b:b986:7726 with SMTP id c4-20020a7bc844000000b0037bb9867726mr532287wml.160.1649099446659; Mon, 04 Apr 2022 12:10:46 -0700 (PDT)
Received: from smtpclient.apple ([2a0d:6fc2:4a90:f00:18a2:8e06:32f6:ba94]) by smtp.gmail.com with ESMTPSA id i4-20020a1c5404000000b0038e7dc5e469sm314840wmb.25.2022.04.04.12.10.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 12:10:45 -0700 (PDT)
Content-Type: multipart/mixed; boundary="Apple-Mail-D95712A7-AE0A-4018-9530-47471DDA49AF"
Content-Transfer-Encoding: 7bit
From: Sharon Barkai <sharon.barkai@getnexar.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 04 Apr 2022 22:10:44 +0300
Message-Id: <8E8EC87E-F2E4-4BD5-BB27-D0C989226009@getnexar.com>
References: <1DFC4834-CB4E-4D83-9928-9A856E84C8E3@gmail.com>
Cc: "lisp@ietf.org list" <lisp@ietf.org>
In-Reply-To: <1DFC4834-CB4E-4D83-9928-9A856E84C8E3@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (19D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/KQNYU5BM0h7-BrMOOf32Jkk3gJA>
Subject: Re: [lisp] New Version Notification for draft-farinacci-lisp-satellite-network-00.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2022 19:11:03 -0000

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
WhatsApp: +1.650.492.0794

> On Apr 4, 2022, at 20:38, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> 
>> 
>> 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. 
> 
> 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
> 
> 
>