Time-Variant Routing
charter-ietf-tvr-01

“Solutions are expected to satisfy the non-terrestrial
networks' requirements as their main driver. Still, they should be general
enough to encompass other types of networks and use cases. They should also be
applicable to routing and other protocols.”

I don’t understand what it means for a solution to be “applicable to routing”. Surely, routing is an enabling technology, not a use case requiring a solution in and of itself? Related, I don’t know what it means to be “applicable to… other protocols”. Would it be reasonable to remove this sentence?

Thanks for addressing my suggestions.

I'm not sure that I have a good feeling what the shape of the solution will look like and what impact it will have on the routing protocols (hence there is a bit of me that wonders whether this is really more IRTF than IETF).  The key to it seems to be wanting to calculate a likely new topology that will happen at a future time and to be able to move from current topology to the new topology whilst minimizing traffic interruptions (e.g., presumably along the lines of gracefully draining links and moving traffic off them before they known to become unavailable).

One question that I have is whether this WG is only tasked with looking at solutions in the routing protocols themselves?  E.g., presumably there are also possible solutions here either making use of a controller that directly orchestrates the network changes via modifying the configuration across the network (e.g., draining links, changing metrics, etc., although I can appreciate that won't work with deep space satellites), or the use of time dependent configuration.  E.g., regular configuration that is annotated with metadata such that parts of the configuration are only active (i.e., only applied) at particular times of day.  I think that some vendors (Juniper?) support some form of time dependent configuration, although I've not aware of any efforts to standardize it.  One potential benefit of trying to solve this in the configuration layer could be that the same broad common solution may work for all protocols.

I'm also somewhat struggling to really see whether TVR can really have meaningful environment benefits, or specifically, whether the additional complexity will be worth the gain.

Having said all of that, I don't think that this proposal will do any harm, possibly except the increase in complexity in the protocols, so, no formal objection to this WG being started.

Regards,
Rob