Hi Adrian, > First: I think this is good work.
Thanks, much appreciated. > I don't know how we document this to > experiment with it. I suspect it needs some pretty sophisticated simulation > because the rate of deployment is going to be such that the operators will > not want to experiment in live networks. It seems (to me) to be in scope for > RTGWG and is something that we should seek to stablise. We would really need some realistic basis from one of the satellite operators, otherwise, we’re just making up garbage. > Have you thought about how well the TE mechanisms will scale? Although the > orbits are well-known (plus or minus meteor strikes), and although (as you > say) a ground station only needs to know about its overhead stripes, and > although you are not considering transit in this architecture, it seems to > me that the computations will be more complicated being time-based, and I'm > not sure that they are easily stable when pre-computed. One approach might be to compute the TE on an abstraction of the topology. For example, suppose that the topology can be roughly characterized as a grid. Flows can then be optimized onto an abstract grid and then satellites can be assigned process through grid positions. This saves total ground-zero recomputation. > I also wonder, given how constrained ISLs may be, about the need for > "centralised" computation to ensure that load is properly balanced. I don’t see much alternative. The gateway has the topology and the traffic demand. While the gateway doesn’t need to be a single CPU, distributing the data much more widely doesn’t seem advantageous. Doing path computation in the satellites itself seems like it would require some very expensive resources. T _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
