Time Variant Routing (tvr) WG

IETF 118, Prague
2023-10-09, 09:30-11:30 CET, Prague

Area Director: Andrew Alston
Chairs: Edward Birrane, Tony Li
Secretary: Adam Wiethuechter

YouTube Recording:
https://www.youtube.com/watch?v=ej0OPPcA2IM&pp=ygULaWV0ZjExOCB0dnI%3D

Introduction, Note Well & Milestones (5 mins)

Speaker: Chairs
Document: N/A

Standard admin fare, no agenda bash

Requirements (20 mins)

Speaker: Daniel King
Document: https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/

Note of the new contributors and authors, due to merging of documents
ID core requirements for solution work
Distill specific scenarios from use-cases
How do we document requirements in this draft?
Assume network where lost link/node is expected
Based on state changes that are intrinstic
Full/partial updates to topology - time or resource variant
LEO, deepspace, terresterial use cases - trying to not lose focus
Expand and detail terms with tvr
Expand routing section; control plane
find short term use-cases, many at scale and implications on control
plane
will cleanup conformance language
start to think about operational/security considerations
Best Practice for req I-D? (info)
Tooling = GitHub

cEB: chairs fine with a github group for tvr

interest in control plane stuff, maybe an interim sometime?
verification and identity management discussion?

cEB: two chat points; if use SDN language do not reinvent. lots of
discussion of management plane (centralized vs. distributed)
No discussion on the management plane stuff. great for discussion but
maybe should focus on near term and be aware of future stuff

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

AB: mentioned not specify sync mechanism. we depend on time sync
especially on distributed
yes we need ensure a devices clock is accurate to apply schedule. actual
mechanism (NTP) is not something we didnt need to specify, maybe should
list examples?
AB: nice if we mention to specify mechanism for protocol
cTL(chat): require nodes be time synced and mechanism out of scope

AA: need to backoff on schedule
comes back to NETCONF (?). very welcome to propose text.
AA: resolution of schedule, variability

JW: change of entity properties may need topology change, can discuss in
future.
great way to attack the network

LZ: In the intrinsic mode, is there a need for the managed device to
advertise schedules to the managing devices? Can device get schedule
from neighbor or need management node?
DK: based on specific scenarios.

Use Cases (20 mins)

Speaker: Yingzhen Qu
Document: https://datatracker.ietf.org/doc/draft-ietf-tvr-use-cases/

currently 3 categories, lots of comments to change from Mobile Devices
to Dynamic Reachability
lots of editorial to make text clear
add Tidal as example for Operating Efficient category
add Predictable Moving Vessels (trains, cruise ships) to Dynamic
Reachability
add problem statement - original from Rick Taylor

• define, distrubte and execute schedule
  question to wg: are we ready for last call?

cEB: due this month according to original schedule, so not bad idea.
show of hands for recent reading of draft: y=12/n=14/29
cEB: if we dont hear any significant concerns we can start wglc, so
please raise on list!

YANG Model (15 mins)

Speaker: Yingzhen Qu
Document:
https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/

merge of two models together from 117 discussions
common model for schedule
node model for device

• config node/router with schedule attributes
  topology model for service

• choose not to augment rfc8030 model
  do not wish to augment models to help implementation and deployment

  example in appendix to augment, but protocol dependent
  open to wg for if this is right approach?

RT: report power useful, should be if can route, not why? semantic
from routing protocol point of view, yes.
RT: list power schedule is function, why its not functional is
irrelevant
do not want to go to far for approach if wrong

AA: see point RT, maybe have error codes as option to augment and be
more expressive?
AA: realtionship bnetween this and operation?
this is to define schedule, second step is distribution of schedule.

LB: do yo uwant whole new module to provide schedule or augment? what
elements, if standalone, do you want to include?
LB: ... (need to relisten to YT for this)

AL: responding to RT, wanted to example simple case. we can look at
groupings

RT: what is the scope of the topology yang? is purpose to say when you
can/cannot transit or to talk about function of devices that make
topology?
AL: ????
RT: is this is the correct attribute to be talking about in a topology
change schedule? excample: blinking green light always 7am to 9am, means
nothing to routing but can be in schedule.
...
RT: understand approach. think augmentation way forward.
more about physical link property.
RT: what is the nature of things as part of the schedule for a node?
we will be able to describe if link is functioning or not, then if
interface is or not
level of abstraction, depends on ???

AA: point case, another use case here. augment or immediatly deployable
model

EB: we have req document, expect that what model here can trace into
reqs. does that help answer the question of modeling things that matter
to tvr?
EB: what is an immediatly deployable model and what is the timeline?
cTL: RT->look at charter for routing, not LEDS. if someone wants to
schedule LEDs go ahead and should be reusable.
no LEDs at this time

LB: interest in paired down module focused on schedule, but shows clear
use case for groupings to be used in other modules.
LB: should grouping be in own module?
whats your preference?
LB: leaning towards own module as more reusable, but can if not just
ugly. can argue for either at this time.

VB: repeat what LB said. many models(modules?) out there. define
grouping that can be inserted.

no objection for standalone? make use of exsiting grouping defintions

TL: object, augmention not standalone.
other models will have dependencies
TL: need TE model to follow
AA: did not consider I2RS only the full TE

cEB: will try to capture in notes, but even better on list!

Using ALTO for exposing Time-Variant Routing information (10 mins)

Speaker: Luis M. Contreras
Document:
https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/

assess alto on req-00
ask for wg adoption as off-path solution

cEB: anyone who has read, any concerns?
JW: using alto expose tvr info meet ??-requiement?
cEB: put in chat, will respond

ZL: figure 1 in draft,
this is just example, be tools
tool to anticipate changes to gen new topology and calc
metrics/characterics
ZL: might need continous updates?
maybe.
ZL: do you have quantitive results for these advantages?
not at this time. two points are quality consideration.

LB: can we support the grouping+augmentation approach discussed in the
previous slot with this document?
yes very alto specific

LB: consider both approachs or select?
cEB: great question! need to see document form and scoping would inform

LB: no issues adopting this, unless we plan to use other
cEB: not an either or
cTL: augment or not, up to authors. this is valid if group has interest
in it.
cEB: adoption call can answer that interest question

YQ(chat): we want to keep the schedule independent, and define the
augmentation in a separate module. Some of the augmentations can be
included in the same document. I think we're in sync LB

IS-IS and OSPF extensions for TVR (10 mins)

Speaker: Sandy Zhang
Draft: https://datatracker.ietf.org/doc/draft-zw-tvr-igp-extensions/

schedule treated as constraints
cTL: no need for two separate documents, point to LSR and outside
charter
TL: not how we want to do this. schedule should not be in routing
protocol. this is not how management information is distributed. if do
generally will be flex? not needed on flexalgo can just be direct on
interface
wants comment from TVR wg and do work in LSR group

AA: LSR co-chair. there was someone who came forward with temporal link
with 8 authors. tried to address when goes in routing protocol. disagree
and it should be in flex protocol, gives backwards compat. if we get
past putting in routing protocol

TL: so does that mean we must use flexalgo? seems counter-intuitive?
AA: why not?
TL: well not everyone supports, so comproise do both native and flex?
AA: can agree with that. but brings up clock sync

JD: agree with TL, out of charter with TVR. may have interims to discuss
(e.g. under LSR or RTGWG）?

Open Mic

cEB: anything?
thanks and adjouned 6 mins early.