[Starlink] WG Action: Formed Time-Variant Routing (tvr) (fwd) The IESG: WG Action: Formed Time-Variant Routing (tvr)

* [Starlink] WG Action: Formed Time-Variant Routing (tvr) (fwd) The IESG: WG Action: Formed Time-Variant Routing (tvr)
@ 2023-02-17 18:40 Michael Richardson
  2023-02-17 20:33 ` Dave Taht
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Richardson @ 2023-02-17 18:40 UTC (permalink / raw)
  To: starlink

[-- Attachment #0: forwarded message --]
[-- Type: message/rfc822, Size: 8702 bytes --]

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: tvr@ietf.org, The IESG <iesg@ietf.org>, tvr-chairs@ietf.org
Subject: WG Action: Formed Time-Variant Routing (tvr)
Date: Fri, 17 Feb 2023 10:24:45 -0800
Message-ID: <167665828550.20350.8180153576099315786@ietfa.amsl.com>

A new IETF WG has been formed in the Routing Area. For additional
information, please contact the Area Directors or the WG Chairs.

Time-Variant Routing (tvr)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Edward Birrane <edward.birrane@jhuapl.edu>
  Tony Li <tony.li@tony.li>

Assigned Area Director:
  Alvaro Retana <aretana.ietf@gmail.com>

Routing Area Directors:
  Alvaro Retana <aretana.ietf@gmail.com>
  John Scudder <jgs@juniper.net>
  Andrew Alston <andrew-ietf@liquid.tech>

Mailing list:
  Address: tvr@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/tvr
  Archive: https://mailarchive.ietf.org/arch/browse/tvr/

Group page: https://datatracker.ietf.org/group/tvr/

Charter: https://datatracker.ietf.org/doc/charter-ietf-tvr/

Existing IETF 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.

However, a growing number of use cases exist where predicted variations
(restoration, activation, or loss) to the topology are an expected part of
normal network operations. 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. Similarly, network traffic might be routed based on energy costs or
expected user data volumes, which may vary predictably over time in networks
prioritizing green computing and energy efficiency. In these cases, the
predicted loss and restoration of an adjacency, or formation of an alternate
adjacency, should be seen as non-disruptive events. Support for such use
cases and expected changes in a routing system is called Time-Variant Routing
(TVR).

The Time-Variant Routing Working Group (TVR WG) is chartered to define
information and data models that address time-based, scheduled changes to a
network. Time-based changes may include changes to links, adjacencies, cost,
and - in some cases - traffic volumes. The models 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 agnostic with respect to other control plane elements.

The WG may also define terminology and concepts where needed, as well as
address the impacts of a continually changing topology on the hierarchical
structure of the network.

The TVR WG will collaborate with groups working on non-terrestrial networks,
including DTN, CCAMP, DETNET, RAW, and DRIP. In addition, the outputs from
the WG will be provided to other working groups for consideration, which may
use the material to incorporate time-variant attributes and behaviors into
individual protocols.

Specifically, the TVR WG will work on these items:

(1) Problem Statement and Use cases

This document (or set of documents) should include a description of the
problem statement and related use cases to guide the remaining work. It
exists to support the efforts of the Working Group and help newcomers, and it
might not be published as an IETF Stream RFC.

(2) Requirements

This document should include definitions, requirements, notes, rationales,
and examples.

(3) Information Model

This document (or set of documents) should describe the attributes needed,
and the relationship between them, to enable routing and forwarding decisions
in the presence of time-variant network parameters.

(4) Data Model

This document (or set of documents) should specify a YANG Data Model (or
multiple modules), based on the Information Model, for configuration and
monitoring.

(5) Applicability Statement

This document should provide an applicability statement on how the
information and data models may be used, along with required ancillary IETF
technology, to solve the use cases and requirements.

(6) Implementation and Operational Considerations

This document should provide advice and guidance to implementors and
operators.

Milestones:

  Nov 2023 - Problem Statement and Use cases

  Mar 2024 - Requirements

  Jul 2024 - Information Model

  Nov 2024 - Data Model

  Nov 2024 - Applicability Statement

  Nov 2024 - Implementation and Operational Considerations

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

^ permalink raw reply	[flat|nested] 3+ messages in thread