Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Raymond Burkholder <ray@oneunified.net> Wed, 23 February 2022 03:07 UTC

Return-Path: <ray@oneunified.net>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF563A0E13 for <etosat@ietfa.amsl.com>; Tue, 22 Feb 2022 19:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SHnyuYGhJBwJ for <etosat@ietfa.amsl.com>; Tue, 22 Feb 2022 19:07:30 -0800 (PST)
Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6D03A0B45 for <etosat@ietf.org>; Tue, 22 Feb 2022 19:07:29 -0800 (PST)
X-One-Unified-MailScanner-Watermark: 1646190445.38968@wiP+Fl6+MMycoWChFL4dWA
X-One-Unified-MailScanner-From: ray@oneunified.net
X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net
X-One-Unified-MailScanner-ID: 21N37NwZ005352
X-OneUnified-MailScanner-Information: Please contact the ISP for more information
Received: from [10.55.90.10] (host96-45-2-121-eidnet.org [96.45.2.121] (may be forged)) (authenticated bits=0) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id 21N37NwZ005352 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for <etosat@ietf.org>; Wed, 23 Feb 2022 03:07:25 GMT
To: etosat@ietf.org
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com>
From: Raymond Burkholder <ray@oneunified.net>
Organization: One Unified Net Limited
Message-ID: <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net>
Date: Tue, 22 Feb 2022 20:07:22 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E3327FA20BF044F98C0ACA50"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/lJoK8sZz41fns5eC-Kf89PULXZU>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2022 03:07:34 -0000

On 2022-02-22 1:27 p.m., Arashmid Akhavain wrote:
> I agree that existing IP routing protocols can face convergence issues 
> when it comes to satellite networks. IP and existing routing protocols 
> rely on hierarchy to minimise the impact of link events. 
> Establishing hierarchy in satellite networks can be very complex due 
> to various movements especially when it comes to massive constellations.
>
> In polar constellations, the movement at the poles, and the seam plane 
> will be problematic for existing routing protocols. The issue of 
> course gets exacerbated in the Walker Delta constellation as the 
> seam effect exists between every other orbit.
>
> A new method of routing might be required to address this issue. What 
> are your plans w.r.t to this draft? Have you discussed some of these 
> issues with any of the working groups?
Using standard routing protocols are problematic as they are reactive.  
And due to inter-satellite delays, can take time to re-converge.  I was 
working with a company to come up with an SDN solution where we used TLE 
(Two Line Elements) to compute satellite nearness and then pre-populate 
neighbor entries for installation at pre-arranged times.

In addition, to do this properly, these neighbor entries and routing 
table entries need to be populated based upon distributed path 
computation capabilities (due to the fact that the same ground stations 
are not always in view, and paths need to be adjusted as necessary).

>
> Best regards,
> Arashmid
>
>
> _______________________________________________
> EToSat mailing list
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat