| Internet-Draft | tvr-prb-stmt | October 2022 |
| Taylor | Expires 27 April 2023 | [Page] |
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.¶
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/.¶
Source for this draft and an issue tracker can be found at https://github.com/ricktaylor/tvr-prb-stmt.¶
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 (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.¶
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.¶
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.¶
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.¶
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:¶
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:¶
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.¶
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.¶
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:¶
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.¶
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:¶
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.¶
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.¶
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.¶
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 execution of those actions, in the scope of each routing protocol.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶