Re: [Sat-int] Fwd: New Version Notification for draft-li-arch-sat-00.txt

[ARBEZ GINDRE Jerome <[e-mail]>]

Hi Tony,

Thank you for your draft.

As it is shown in figures of page 9 of [Darwish], the access network
provides a connectivity between a satellite providing the Service Link
and the Access gateway (the gNB/5GCN in [Darwish]).

As it is shown in Figure 1 of page 4 of [Xu], the Access gateway (PoP
in [Xu]) may not be co-localized with a Gateway and may need
additional routing on Ground network (Backbone network in [Xu]).

In the same figure of [Xu], there are the description of the NCCs and
NMCs that need to Monitor and Control every satellites and may also
need to do it through the satellite networks. NCCs and NMCs may also
not be co-localized with a Gateway.

I believe that the IS-IS should include the ground network to provide
end to end (MPLS) tunneling between the Access gateway/NCCs/NMCs
(eventually without a direct mean to access the satellites) and all
satellites.

I would propose the following L1/L2/L1L2 scheme in order to maximize
L1 areas stability and to handle topology instability as much as
possible only at L2 level:

* Satellites: L1L2
   * intra-orbit ISLs interfaces: L2
   * inter-orbit ISLs interfaces: L1 if intra Stripes, L2 if inter
     Stripes
   * interfaces with Gateway: L2
* Gateways: L1L2
   * interfaces with Satellites : L2
   * interfaces on ground network : L1

* Access gateways/NCCs/NMCs (without direct mean to access
  satellites): L1
   * interfaces on ground network : L1

An alternative would be to put everything on ground in L2 as follow:
* Gateways: L2
   * interfaces with Satellites : L2
   * interfaces on ground network : L2
* Access gateways/NCCs/NMCs: L2
   * interfaces on ground network : L2

>    *  Local gateway: Each user station is associated with a single
>       gateway in its region.

I would replace "Local gateway" by "Access gateway" without "in its
region" because we could imagine (for any reason) to have user
stations associated with an Access gateway in a different geographic
region.

I think adding these scenarios would increase the genericity of
the proposed draft to cover various satellite constellation systems.

Regards,
Jérôme

   [Darwish]  Darwish, T., Kurt, G. K., Yanikomeroglu, H., and
              Bellemare, M., "LEO Satellites in 5G and Beyond
              Networks: A Review From a Standardization Perspective",
              DOI 10.1109/ACCESS.2022.3162243, March 2022,
              <https://doi.org/10.1109/ACCESS.2022.3162243>

   [Xu]       Xu, S., Wang, X., and Huang, M., "Software-Defined
              Next-Generation Satellite Networks: Architecture,
              Challenges, and Solutions", DOI
              10.1109/ACCESS.2018.2793237, January 2018,
              <https://doi.org/10.1109/ACCESS.2018.2793237>

De : Sat-int <[e-mail]> De la part de Tony Li
Envoyé : mardi 5 décembre 2023 19:14
À : [e-mail]; [e-mail]
Objet : [Sat-int] Fwd: New Version Notification for draft-li-arch-sat-00.txt


Hi all,

Thank you all for the comments that I’ve received.

It’s been determined that my draft is not appropriate for TVR, so I’ll be taking this via the ISE route.

In the meantime, I would welcome more comments.

Tony



Begin forwarded message:

From: [e-mail]<mailto:[e-mail]>
Subject: New Version Notification for draft-li-arch-sat-00.txt
Date: December 5, 2023 at 10:11:40 AM PST
To: "Tony Li" <[e-mail]<mailto:[e-mail]>>

A new version of Internet-Draft draft-li-arch-sat-00.txt has been successfully
submitted by Tony Li and posted to the
IETF repository.

Name:     draft-li-arch-sat
Revision: 00
Title:    A Routing Architecture for Satellite Networks
Date:     2023-12-05
Group:    Individual Submission
Pages:    14
URL:      https://www.ietf.org/archive/id/draft-li-arch-sat-00.txt
Status:   https://datatracker.ietf.org/doc/draft-li-arch-sat/
HTMLized: https://datatracker.ietf.org/doc/html/draft-li-arch-sat


Abstract:

  Satellite networks present some interesting challenges for packet
  networking.  The entire topology is continually in motion, with links
  that are far less reliable than what is common in terrestrial
  networks.  Some changes to link connectivity can be anticipated due
  to orbital mechanics.

  This document proposes a routing architecture for satellite networks
  based on existing routing protocols and mechanisms, enhanced with
  scheduled link connectivity change information.  This document
  proposes no protocol changes.



The IETF Secretariat