[Space] Re: New Version Notification for draft-piraux-space-constellation-code-00.txt

[Maxime Piraux <[e-mail]>]

Hi Michael,

> I find that this specification is a bit outside what I think the IETF^WIRTF
> should be doing... but I understand why this is important to be able to do
> simulations of predicted routing outages.
>
> It seems that one does not really need to know the detailed positions of the
> various satellites, one needs to know which links are getting noisy/failing,
> have failed, and which ones are starting to get better, or are 100%.

I computed the distances between satellites in my experiments as I
wanted to set a lower bound on the one-way delay of the OISLs. I expect it to be
mostly influenced by the propagation time, hence the computation of the
distance. This is very specific to my routing experiments indeed but it still a
relevant part of these systems.

As I mentioned, I don't have enough expertise on the physical layer to propose a
credible model, i.e., a model that somewhat tightly fits the problem space and
doesn't cover too much surface that isn't relevant in reality.

> In the low-power IoT space, in ROLL, RFC6550 and friends deals with ETX
> metrics for links.   What I'd want:
>
> 1. a way to name links.   There is some recent work in OPSAWG to better
>   describe customer connections in YANG.
>           A Network YANG Data Model for Attachment Circuits
>              draft-ietf-opsawg-ntw-attachment-circuit-16
>   maybe this could be repurposed.

I'll take a look at these works. Where I want to go next with the constellation
code is defining how these links are established, given that for a satellite
with 4 OISLs in a Walker Delta constellation, there is only one sensible
assignment pattern that I am aware of.

> 2. a way to describe (to simulators) how ETX on links changes.
>   Yes, given the elements/data from space-constellations, one can generate
>   that, but I have two observations:
>   a. the routing experts aren't orbital experts (and vv).
>   b. craft away from the earth would need to be described differently

A goal of this document, written from my perspective coming from an Internet
protocols background into the aerospace industry, is precisely to educate
routing persons on the orbital dynamics of constellations. I think there isn't
so much needed to get there. Then, one or more implementations of the code could
compute interesting metrics of constellations in this perspective.

Indeed, currently the code only considers Walker constellations with circular
orbits around Earth, but it could be expanded to other types of orbits (for
instance elliptical orbits).

Cheers,
Maxime