Time-Variant Routing
charter-ietf-tvr-01

[Ballot comment]
No actual comment on the content charter - it looks fine to me.  As a minor nit, the text was too wide when reviewing this on my tablet and the text didn't fold well.  Perhaps worth reflowing the charter text to make the lines slightly shorter.

[Ballot comment]
While I would love to ballot a strong supportive YES ballot, I am afraid that there are still some points that could be improved...

"The models are expected" please qualify "the models" as in "The information model is expected" (I do not think that YANG will be useful for IS-IR or OSPFv3).

"with other groups working on non-terrestrial networks", unsure whether "non-terrestrial" has a strict definition, moreover some use cases appear to rely on physical links.

"based on the Information Model", while fully correct from the academic point of view, also establishes a chronological sequence that may put heavy constraints on the WG.

Hope this helps,

-éric

[Ballot comment]
# GEN AD review of charter-ietf-tvr-00-03

CC @larseggert

## Comments

### Paragraph 18
```
  Milestones
```
It would be good to indicate the intended standards level of these documents.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
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

[Ballot comment]
“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?

[Ballot block]
I would like to discuss the relationship towards DTN working group. This working group certainly focusing on the routing aspects. However, one of the major usecase it has actually associates with DTN usecases. There could be a relation between the delay tolerances in the DTN protocols and predicted path/route unavailability. Hence, I would like to understand if there is a clear distinction in scope of the DTN and to be formed TVR or not. Has there been discussion around it?

[Ballot comment]
A fascinating WG... Some comments below:

From a non-English speaker.. Should there be an hyphen between 'time' and 'variant' as in 'Time-Variant Routing' ?

`The TVR WG will provide its outputs for consideration by other Routing Area Working Groups`, why only within RTG ? I could see link to TSV and INT at least (and of course OPS/SEC). Suggest to simply say "other IETF WGs".

Information model: will the information cover the 'forwarding' even if the WG name (and charter) is only about routing ?

Information model: usually an information goes beyond a set of attributes as it should/must at least include relationships among those attributes.

`YANG Data Model(s)`, it should probably be either "YANG data model" (singular) or "YANG data modules" (plural).

Applicability: "models" ? as in data/information models ? Or is it something else ?

[Ballot comment]
A few nits:
"This document may not necessarily be published as an IETF Stream RFC but may be
maintained in draft form to support the efforts of the Working Group and help
newcomers."

Personally I think that this document should be published as an RFC - if it is written to "support the efforts of the WG and help newcomers" it will also be useful for newcomers to the technology once the primary work product is published. When the point-haired-boss walks into your office and says "Oi, Dilbert! Go deploy 'RFCxxx - Time Variant Aware OSPFv10'", a problem statement which explains what actual *issue* RFCxxx is supposed to solve is really helpful....


If we do keep this, can we at least appease Warren's OCD? Every time I'm on an plane and hear: "Cover your nose and mouth with the mask. The bag may not inflate. Put on your own mask first before you help others." I get annoyed; I picture an oxygen mask falling from the ceiling, someone putting it on, watching the bag inflate and then squishing all of the oxygen out, because of the implied imperative "The bag may not inflate"... I get that this says: "may not necessarily", but still, could it be reworded to something like:
"This document exists to support the efforts of the Working Group and help newcomers, and might not become an RFC"?

Note that I still think that it should be dropped -- I personally thing that Use Case, Architecture, Applicability Statement, Deployment Guides, etc are all very useful documents...

[Ballot block]
# GEN AD review of charter-ietf-tvr-00-00

CC @larseggert

## Discuss

### Paragraph 4
```
  The Time Variant Routing Working Group (TVR WG) is chartered to define
  solutions that address time-based, scheduled changes to a network. Time-based
  changes may include changes to links, adjacencies, traffic volumes, and cost.
```
"Traffic volumes" is a different beast from the others, because traffic volumes
are generally not known a priori (since traffic is end-system generated).

[Ballot comment]
## Comments

### Paragraph 2
```
  Existing routing protocols expect to maintain contemporaneous, end-to-end
  connected paths across a network. Changes to that connectivity, such as the
  loss of an adjacent peer, need the routing protocols to react to reduce the
  impact on the network traffic.
```
Really, all "existing routing protocols"? There's a lot or routing research out
there. Maybe better "Existing IETF routing protocols"? (Assuming that is
accurate, c.f., RPL?)

### "YANG", paragraph 7
```
  ## Milestones

  Jul/2023 - Problem Statement and Use cases

  Nov/2023 - Requirements
```
Results in 2023 seem optimistic.

### Chairs

Who are the chairs going to be?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool