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

Meiling Chen <chenmeiling@chinamobile.com> Sat, 26 February 2022 00:26 UTC

Return-Path: <chenmeiling@chinamobile.com>
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 65F263A0C35 for <etosat@ietfa.amsl.com>; Fri, 25 Feb 2022 16:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 gwwtKQe62AzZ for <etosat@ietfa.amsl.com>; Fri, 25 Feb 2022 16:26:04 -0800 (PST)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id F0BC13A0C36 for <EToSat@ietf.org>; Fri, 25 Feb 2022 16:26:03 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee9621972e4939-05c00; Sat, 26 Feb 2022 08:23:01 +0800 (CST)
X-RM-TRANSID: 2ee9621972e4939-05c00
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[120.244.166.223]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee7621972e38bd-0246b; Sat, 26 Feb 2022 08:23:01 +0800 (CST)
X-RM-TRANSID: 2ee7621972e38bd-0246b
Date: Sat, 26 Feb 2022 08:23:12 +0800
From: Meiling Chen <chenmeiling@chinamobile.com>
To: Wesley Eddy <wes@mti-systems.com>
Cc: EToSat <EToSat@ietf.org>
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com>, <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net>, <85aa1a9d30c745c08598384bb68bdcf9@dlr.de>, <CAL0D2oRBmEF0J8=3OJ0UNi7TfLkKJudvhVVsGg9wAEw4H-V8RQ@mail.gmail.com>, <CAC4j5ET9988rpnq0GrrGspY9HEnc+YoLRP0-1DdQmdTSPsjZ3w@mail.gmail.com>, <BY5PR13MB314462E940D269AD6CBB74CAE93C9@BY5PR13MB3144.namprd13.prod.outlook.com>, <CAPjWiCS-eY9hsyxb+6iEOr-OK9fK_8Oqd7c44GvrkUwiAYDhmg@mail.gmail.com>, <BY5PR13MB31448E1CB932962E5E539302E93D9@BY5PR13MB3144.namprd13.prod.outlook.com>, <2022022511051209402716@chinamobile.com>, <CAC4j5ERvkG=+NVyO+tZT=vG67Sukz=9gc7ebW3KqOnjHdzN0tA@mail.gmail.com>, <BY5PR13MB3144C20419E7B933BB89F7CEE93E9@BY5PR13MB3144.namprd13.prod.outlook.com>, <c07d775d-3360-f012-2c90-e8423b1e2366@mti-systems.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.115[cn]
Mime-Version: 1.0
Message-ID: <2022022608231131759614@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart844667120186_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/adyLGy-jXtiVkdSh-6g72cgyyEA>
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: Sat, 26 Feb 2022 00:26:08 -0000

Hi Wesley,

3GPP has regarded satellite network as 5G NG-RAN infrastructure, Network Operators need and want to be able to use satellite networks to provide services, the owner of satellite network should use the technology provided by IETF instead of private technology which is used currently. To develop, we need to change the stateof privatization. From the perspective of economy, satellite networks will be shared in the future. It is impossible for each Service Provider to send a large satellite network, sure you know that.  Therefore, the technology of satellite network should be dominated by IETF and 3GPP like the current Internet and wireless technology.

Best,
Meiling
 
From: Wesley Eddy
Date: 2022-02-26 03:04
To: etosat
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
On 2/25/2022 1:26 PM, Lin Han wrote:
>>> But since in this scenario, the satellite network is treated as transport , 3GPP assumes that connectivity and routing  will be given and fully supported by the underlay transport.
 
Right, the basic IP connectivity for satellite network is not there yet even 3GPP assumes it in the architecture for satellite-based NG-RAN. Without IP connectivity, all 3GPP interfaces NG/Xn/F1/F2 will not work.
The issue is not that simple as few people assumed. We cannot use current routing or SDN solution to massive satellite constellation directly. Lots challenges and reworks are expected. The mobility of satellite network is unprecedented compared with the mobile scenarios in MIP, PMIP, DMM, etc. Basically, the difference is “infrastructure moving” vs “end device moving”.
So, IETF should work to provide technologies and solutions.
 

Unless constellation operators or vendors are asking for some new standard or interoperability spec for this, then I don't think this is valuable to pursue.  Who exactly wants it?
IMHO, the things you mention are understood and designed around already.