<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Helvetica 75 Bold";
panose-1:2 11 8 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:windowtext;}
p.msipfootered91ed98, li.msipfootered91ed98, div.msipfootered91ed98
{mso-style-name:msipfootered91ed98;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="FR" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;mso-fareast-language:EN-US">+1, in fine these ones are a bit more terrestrial<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>De :</b> Sat-int <sat-int-bounces@ietf.org> <b>De la part de</b> Jorge Amodio<br>
<b>Envoyé :</b> mardi 19 septembre 2023 03:08<br>
<b>À :</b> David Lang <david@lang.hm><br>
<b>Cc :</b> Hesham ElBakoury <helbakoury@gmail.com>; Alexandre Petrescu <alexandre.petrescu@gmail.com>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; sat-int@ietf.org<br>
<b>Objet :</b> Re: [Sat-int] [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I believe that a better definition and characterization of "NTN" would be appropriate.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">NTN can represent a yuuuuuuuuge space... networking to Proxima Centauri could be considered NTN, but I bet you will have a completely different set of challenges than LEO, MEO, GEO, etc.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My .02<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Jorge<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 18, 2023 at 8:01 PM David Lang <<a href="mailto:david@lang.hm">david@lang.hm</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal">On Mon, 18 Sep 2023, Hesham ElBakoury wrote:<br>
<br>
> My understanding is that for integrated NTN and Terrestrial network we may<br>
> need new or enhanced routing protocols. There are many publications in this<br>
> area.<br>
<br>
I don't see how starlink hops have to be treated any differently than <br>
terrestrial tunnels (think frame relay networks that overlay a virtual network <br>
on top of the physical network, encrypted or not). There probably are new <br>
routing protocols that will handle these better than current ones, but I see <br>
that a matter of such links being more common, rather than being fundementally <br>
different.<br>
<br>
I do see that in the future, if/as information about the in-space routing <br>
becomes more open (and I strongly suspect, stabilizes more) that there will be <br>
more that can be done, and at some point it may even make sense to allow for <br>
'peering' between satellites from different providers (which would require <br>
standardization of the in-space signals and protocols)<br>
<br>
I may be missing something at this point (I don't claim to be a networking <br>
expert, but I'm seeing buzzwords here, but not an explination of why normal IP <br>
routing isn't sufficient.<br>
<br>
David Lang<br>
<br>
> I suggest that you discuss your view in int-sat email list (copied)<br>
><br>
> Thanks<br>
> Hesham<br>
><br>
> On Mon, Sep 18, 2023, 5:31 PM David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>> wrote:<br>
><br>
>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:<br>
>><br>
>>> Given the discussions in this email thread, what IETF should standardize<br>
>> in<br>
>>> priority order for the integrated NTN terrestrial networks?<br>
>><br>
>> I don't see why you need to do any particular standardization to integrate<br>
>> things like starlink into terrestrial networks.<br>
>><br>
>> Just like IETF didn't need to standardize ethernet/token<br>
>> ring/arcnet/modems to<br>
>> make them compatible with each other. They all talk IP, and a computer<br>
>> with a<br>
>> link to each of them can serve as a gateway (and this included proprietary<br>
>> modems that were not compatible with anything else, the network didn't<br>
>> care)<br>
>><br>
>> Starlink is just another IP path, all the tools that you use with any<br>
>> other ISP<br>
>> work on that path (or are restricted like many other consumer ISPs with<br>
>> dynamic<br>
>> addressing, no inbound connections, no BGP peering, etc. No reason that<br>
>> the<br>
>> those couldn't work, SpaceX just opts not to support them on consumer<br>
>> dishes)<br>
>><br>
>> I'll turn the question back to you, what is the problem that you think is<br>
>> there<br>
>> that needs to be solved?<br>
>><br>
>> David Lang<br>
>><br>
>>> Thanks,<br>
>>> Hesham<br>
>>><br>
>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <<br>
>>> <a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>> wrote:<br>
>>><br>
>>>> it's very clear that there is a computer in the dishy that you are<br>
>> talking<br>
>>>> to.<br>
>>>> You get the network connection while the dishy is not connected to the<br>
>>>> satellites (there's even a status page and controls, stowing and<br>
>> unstowing<br>
>>>> for<br>
>>>> example)<br>
>>>><br>
>>>> I think we've seen that the dishy is running linux (I know the routers<br>
>> run<br>
>>>> an<br>
>>>> old openwrt), but I don't remember the details of the dishy software.<br>
>>>><br>
>>>> David Lang<br>
>>>><br>
>>>> On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:<br>
>>>><br>
>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200<br>
>>>>> From: Alexandre Petrescu via Starlink <<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>><br>
>>>>> Reply-To: Alexandre Petrescu <<a href="mailto:alexandre.petrescu@gmail.com" target="_blank">alexandre.petrescu@gmail.com</a>><br>
>>>>> To: <a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a><br>
>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of<br>
>>>> Satellites and<br>
>>>>> Terrestial Networks<br>
>>>>><br>
>>>>><br>
>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :<br>
>>>>>> On 16/09/2023 5:52 am, David Lang wrote:<br>
>>>>>>><br>
>>>>>>> In addition to that Ulrich says, the dishy is a full computer, it's<br>
>>>>>>> output is ethernet/IP and with some adapters or cable changes, you<br>
>>>>>>> can plug it directly into a router.<br>
>>>>>><br>
>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged<br>
>>>>>> a DHCP client straight in - and it "works" but with a noticeably<br>
>>>>>> higher rate of disconnects.<br>
>>>>><br>
>>>>> It is good to know one can plug a DHCP client into the Ethernet of the<br>
>>>>> DISHY and receive DHCP replies.<br>
>>>>><br>
>>>>> But that would be only a lead into what kind of DHCPv4 is supported, or<br>
>>>> not.<br>
>>>>><br>
>>>>> I would ask to know whether the DHCP server runs on the DISHY, or<br>
>>>>> whether it is on the ground network of starlink, i.e. the reply to DHCP<br>
>>>>> request comes after 50ms, or after 500microseconds (timestamp<br>
>> difference<br>
>>>>> can be seen in the wireshark run on that Ethernet).<br>
>>>>><br>
>>>>> This (DHCP server daemon on dishy or on ground segment) has an impact<br>
>> of<br>
>>>>> how IPv6 can be, or is, made to work.<br>
>>>>><br>
>>>>> This kind of behaviour of DHCP - basically asking who allocates an<br>
>>>>> address - has seen a continous evolution in 3GPP cellular networks<br>
>> since<br>
>>>>> they appeared. Nowadays the DHCP behaviour is very complex in a 3GPP<br>
>>>>> network; even in a typical smartphone there are intricacies about where<br>
>>>>> and how the DHCP client and server works. With it comes the problem of<br>
>>>>> /64 in cellular networks (which some dont call a problem, but I do).<br>
>>>>><br>
>>>>> So, it would be interesting to see whether starlink has the same /64<br>
>>>>> problem as 3GPP has, or is free of it (simply put: can I connect<br>
>> several<br>
>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or<br>
>>>> not?).<br>
>>>>><br>
>>>>> Alex<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Starlink mailing list<br>
>>>>> <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
>>>>> <a href="https://lists.bufferbloat.net/listinfo/starlink" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
>>>>> _______________________________________________<br>
>>>> Starlink mailing list<br>
>>>> <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
>>>> <a href="https://lists.bufferbloat.net/listinfo/starlink" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
>>>><br>
>>><br>
>-- <br>
Sat-int mailing list<br>
<a href="mailto:Sat-int@ietf.org" target="_blank">Sat-int@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/sat-int" target="_blank">https://www.ietf.org/mailman/listinfo/sat-int</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="msipfootered91ed98" align="center" style="margin:0cm;text-align:center">
<span style="font-size:8.0pt;font-family:"Helvetica 75 Bold",sans-serif;color:#ED7D31">Orange Restricted</span><o:p></o:p></p>
</blockquote>
</div>
</div>
<pre>_________________<wbr>______________________________<wbr>______________________________<wbr>______________________________<wbr>_
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.</pre></body>
</html>