Multi-Domain Considerations

[danielkinguk]

Need to add assumptions section, and then highlight which requirements might be affected by a multi-domain network. Therefore, consideration of domain boundaries and what information is exchanged, how, when, and what, will need to be discussed.

[danielkinguk]

Please also check Minutes from IETF 118, specifically:

ZL: routing based on address, do you think addressing a challenge especially if mobile node? paticular scenario for some use cases but not directly in document. part of control plane discussion. maybe have a discussion? ZL: new problems due to network? maybe a little early to determine gaps in tooling, new dimension being added here. can see new threat vectors - ex: modify physical clock

[danielkinguk]

Another topic to be added to "Scope". Why there is mobility and time changes, should not be considered in scope. From a TVR perspective it is out of scope.

[luismcontreras]

I have prepared the following text for covering this issue:

8< --

Assumptions

The requirements described in this document have been identified as applicable for Time-Variant Routing scenarios under the following assumptions.

• The TVR information is generated and distributed within a single domain, where both the routing and the scheduling information is under control of the same administrative entity. In consequence, multi-domain scenarios are out of scope.

• The TVR changes are not due to random mobility events of end-users or nodes. While TVR considers scenarios where topological changes occur motivated by a mobility pattern (as in the case of non-terrestrial networks, where the mobiity pattern can be predicted anf follows a clear pattern), generic random mobility events are not considerd as part of the scope of this document.

• The potential implications of topological changes on the addressing of nodes is considered out of scope for the requirements analysis.

8< --

Please, note the following:

• The TVR charter states: "For example, in networks with mobile nodes, such as aerial vehicles and some orbiting spacecraft constellations, links can be lost and re-established, or neighbors may change as a function of their mobility. " So probably we need to reconsider the mobility part, taking it as part of the scope as well. As you can see I refer to "random" mobility events instead of predictable patterns, but not sure if that can overcome the charter text.
• Should I add the text on the XML file? Maybe we could ocnsider to migrate to markdown. Anyway, the xml file seems to be old. What is the exact file for creating the pull request?