Time Variant Routing R. Taylor Internet-Draft Ori Industries Intended status: Informational 24 October 2022 Expires: 27 April 2023 Time Variant Routing Problem Statement draft-taylor-tvr-prb-stmt-00 Abstract 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, are considered to be exceptional circumstances that must be corrected prior to the resumption of data transmission. Corrections may include attempting to re-establish lost adjacencies and recalculating or rediscovering a functional topology. However, there are a growing number of use-cases where changes to the routing topology are an expected part of network operations. In these cases the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as a non- disruptive event. This document attempts to describe the problems perceived with existing routing protocols and act as a "Problem Statement" to be addressed by the proposed Time-Variant Routing (TVR) working group. Readers are recommended to read this document alongside the TVR (Time-Variant Routing) Use Cases (https://datatracker.ietf.org/doc/ draft-birrane-tvr-use-cases/). About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ricktaylor.github.io/tvr-prb-stmt/draft-taylor-tvr-prb- stmt.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-taylor-tvr-prb-stmt/. Discussion of this document takes place on the Time Variant Routing Working Group mailing list (mailto:tvr@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tvr/. Subscribe at https://www.ietf.org/mailman/listinfo/tvr/. Taylor Expires 27 April 2023 [Page 1] Internet-Draft tvr-prb-stmt October 2022 Source for this draft and an issue tracker can be found at https://github.com/ricktaylor/tvr-prb-stmt. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Behaviour of existing Routing Protocols . . . . . . . . . . . 4 4.1. Connectivity Loss . . . . . . . . . . . . . . . . . . . . 5 4.2. Connectivity Gain . . . . . . . . . . . . . . . . . . . . 5 5. Problems to Solve . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Adjacency Schedules . . . . . . . . . . . . . . . . . . . 6 5.2. Distributing Adjacency Schedules . . . . . . . . . . . . 6 5.3. Executing Adjacency Schedules . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 Taylor Expires 27 April 2023 [Page 2] Internet-Draft tvr-prb-stmt October 2022 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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, are considered to be exceptional circumstances that must be corrected prior to the resumption of data transmission. Corrections may include attempting to re-establish lost adjacencies and recalculating or rediscovering a functional topology. However, there are a growing number of use-cases where changes to the routing topology are an expected part of network operations. In these cases the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as a non- disruptive event. The expected loss (and planned resumption) of links can occur for a variety of reasons. In networks with mobile nodes, such as unmanned aerial vehicles and some orbiting spacecraft constellations, links are lost and re-established as a function of the mobility of the platforms. In networks without reliable access to power, such as networks harvesting energy from wind and solar, link activity might be restricted to certain times of day. Similarly in networks prioritizing green computing and energy efficiency over data rate, network traffic might be planned around energy costs or expected user data volumes. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Disclaimer This document has been written rapidly, and a draft published prior to any serious peer-review; it therefore may be factually incorrect in its assumptions. However, the author feels it is important to begin this conversation in order to discover if there is merit in examining the perceived issues detailed. Taylor Expires 27 April 2023 [Page 3] Internet-Draft tvr-prb-stmt October 2022 4. Behaviour of existing Routing Protocols Since the dawn of the Internet, existing routing protocols have been developed to ensure that end-to-end paths can be established for the transmission of datagrams. As the Internet began on academic and research networks, the routing protocol designs have developed based on assumptions about the characteristics of these early networks, namely: * The individual nodes in a network do not move around. * The individual nodes are expected to be permanently available once they join the network. Issues with the first assumption have long been known, and have been the subject of much research under the umbrella term Mobile Ad-hoc Networks (MANET). The IETF has had an active Working Group attempting to standardise routing protocols specifically designed for that use-case for many years, however the second assumption has been largely ignored, and the result of this has been two-fold: * A number of routing protocols, such as BGP [RFC4271] and OSPF [RFC2328], have been standardised for use in extremely stable networks, where the loss of reachability to a node in the network is considered an exceptional circumstance that requires some kind of recovery mechanism, sometimes requiring some kind of global recalculation of the topology. * A number of specialised MANET routing protocols, such as OLSR [RFC7181] and AODV [RFC3561], have been standardised for use in high-churn environments, where nodes move and disappear from the network in unpredictable ways. These protocols have novel approaches to mitigate against the disruption caused by these rapid unscheduled changes to the network topology. However, the author believes there is a third issue with the underlying assumptions that have driven routing protocol design to date: There are use-cases where one or more nodes in the network may become unreachable, or relocate within the current topology, at a time known in advance of it happening. The belief is that these use- cases are not adequately satisfied by the current suite of routing protocols. Taylor Expires 27 April 2023 [Page 4] Internet-Draft tvr-prb-stmt October 2022 4.1. Connectivity Loss In both stable and MANET routing protocols, the loss of connectivity to one or more nodes is seen by their peers as an erroneous condition, and this has driven the focus of research into increasingly sophisticated connectivity monitoring techniques, ranging from simple timer-based "Hello" mechanisms, to rich interaction with the link-layer, for example DLEP [RFC8175]. In all cases these methods are designed to enable a router to promptly detect an adjacency failure, completely ignoring the use-cases where the timing of the failure is well-known in advance. A second effect of treating peer-connectivity failures as exceptions to the correct operation of a network is that mitigation for the loss of the peer only begins once the adjacency failure has occurred. If the loss of connectivity is predictable, then the (possibly expensive) route recalculations can have occurred well in advance of the loss happening, and executed at the exact moment they are needed, reducing disruption to the network as a whole. 4.2. Connectivity Gain In the use-cases where loss of connectivity with a peer is a predicted event, then often the start or resumption of connectivity is also known in advance of it happening. As with loss of connectivity, existing protocols fall back to one or all of a set of common mechanisms: * Timer-based polling of a previous adjacency, in case it came back. * Reliance on some link-layer notification mechanism. * Multicast-based discovery of unexpected new peers. None of these mechanisms is particularly timely, as the expected arrival or return of a peer is seen as an unexpected event. When connectivity with a potential peer is (re)established, generally a full re-introduction to the routing topology is conducted, which can be an expensive and potentially disruptive process. 5. Problems to Solve What is not being proposed is the development of a new alternative routing protocol to address the particular use case of expected failure, for a number of reasons: 1. Designing routing protocols is hard, and civilisation has many good ones to chose from already. Taylor Expires 27 April 2023 [Page 5] Internet-Draft tvr-prb-stmt October 2022 2. Even if some adjacency failures are predictable, others are not. Any new routing protocol must still handle the case of unexpected failure. Therefore the suggestion is to augment existing protocols with the capability to react to expected adjacency failure. The author believes that the work on Time Variant Routing should be focussed on solving the following problems. 5.1. Adjacency Schedules In order to react to the expected failure and resumption of connectivity to a peer, relevant nodes within the domain of a single routing protocol instance must be made aware of the time and nature of the expected change in connectivity. This information is referred to here as the Adjacency Schedule. Although few protocols share an on-the-wire binary representation of data, there are common constructs, such as an IP subnet, that all protocols share. We suggest that the same applies to an Adjacency Schedule. It should be perfectly possible to define in some generic manner the structure and content of the data that describes a schedule, and then map that content to the relevant wire format of existing routing protocols. A future IETF Time Variant Routing Working Group should define a common data model for an Adjacency Schedule, including the rules for correctly creating, updating and deleting the content. 5.2. Distributing Adjacency Schedules How an Adjacency Schedule is distributed amongst the peers of an individual routing protocol instance is dependant on many factors individual to each routing protocol, and a future IETF Time Variant Routing Working Group must work with the relevant subject matter experts, preferably a relevant IETF Working Group, in order to standardise the optimal distribution of an Adjacency Schedule to the correct peers for each routing protocol. 5.3. Executing Adjacency Schedules Of course, just knowing about an Adjacency Schedule is insufficient, changes in behaviour of routing protocols must be standardised such that advantage can be taken of having prior knowledge of expected changes in topology. To achieve this a future IETF Time Variant Routing Working Group should determine the set of actions that can be scheduled, and then work with the relevant subject matter experts, preferably a relevant IETF Working Group, in order to standardise the Taylor Expires 27 April 2023 [Page 6] Internet-Draft tvr-prb-stmt October 2022 execution of those actions, in the scope of each routing protocol. 6. Security Considerations TODO Security 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, . [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, . Taylor Expires 27 April 2023 [Page 7] Internet-Draft tvr-prb-stmt October 2022 Acknowledgments TODO acknowledge. Author's Address Rick Taylor Ori Industries Email: rick.taylor@ori.co Taylor Expires 27 April 2023 [Page 8]