Time Variant Routing (tvr) WG

IETF 117, San Francisco
2023-07-27, 13:00-15:00 America, Pacific Time

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

Agenda:

Introduction, Note Well & Milestones (5 mins)

Speaker: Chairs
Document: N/A

cEB: intros
cTL: notewell, don't be jerks, we don't want to be jerks
cTL: please use tools
cTL: agenda, lots of talks very full. no raise on agenda bash
cEB: please note taking, sec online but please help

Update of TVR Use Cases (15 mins)

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

Resource preservation, operating efficiency, mobile devices
in-depth presentation @ 116, please see old presentation/slides for gory
details
List comments on Tidal, satellites other than LEO
Mobile Devices --> Dynamic Reachability
cEB: one more slide then questions from queue
will not list all possible use-cases, want to cover impacts (node, link,
neighbors, traffic patters)
predictable traffic patterns not yet covered

Arashmid Akhavain: distinction between mobile nodes and terimnals, node
is router/sat is moving, agree on last point with predicatbility of
traffic
topology change not by ... but by ...
may want to move things around

Lou Berger: unplanned not covered by tvr, the document say this happens
and handled elsewhere
cTI: as wg produce problem statement adn it should be part of this
document. as sheppard please add.
RT: problem statement written for BOF, will donate it all
please email us!
Arashmid: once we predict something and we make a mistake what do we do?

we need to discuss more on this. if you tell me fake schedule
Arashmid: no its not fake. what happens when predications are no longer
valid we need a mechanism to back it off
we can discuss more offline
cTL: is that a usecase or solution
Arashmid: consideration that this can happen
cTL: seems like a requirement
Gargi Adhav: why should unplanned topology changes not covered and where
will it be covered?
charter is about planned changes with a schedule
Gargi: may be a link/node failure
handlded by FRR today
Gargi: so should be handled outside tvr in frr
cEB: scopes initial charter is to focus on planned, other groups for
adhoc changes. if there is area not covered by other groups we can
recharter. so start at planned and see what we can do later.
Acee Lindem: unplanned changes will be covered in solutions but not part
of charter

Requirements (10 mins)

Speaker: Jing Wang
Document:
https://datatracker.ietf.org/doc/draft-wang-tvr-requirements-consideration/

requirement 1: discovery and resolving identification of time-variant
and non-tv nodes
requirement 2: different advert strategies
requirement 3: classification of time-variant nodes

RT: what is a time variant node? might be wrong approach to classify
nodes, rather than existing nodes and their behaviors. it may just be a
config option.
example: some network nodes power are contant, in this case green energy
powered node is time-variant
RT: thanks, i do understand where coming from. that propery itself is
time-variant, phone can be plugged into AC or be on battery. very strict
taxonomy may be a mistake.
TL: agree completely. nodes have pending schedule items and nodes that
dont and you can swap between the two
Arashmid: can add text ...

Requirements (20 mins)

Speaker: Brian Sipos
Document: https://datatracker.ietf.org/doc/draft-kcs-tvr-requirements/

Recently published, lots of TBDs and a good starting point
Achieve charter item of what tvr is
What protocols should and should not do
Link to use-case draft for rational
Its the network that is time variant not individual element
basic terms and notion on how we can model
distinct between schedule timeline adn wallclock timeline, must consider
both indepent but related
try to predict things in schedule time but there can be differences
want feed back on definitions of terms, major effect on capability of
the system (time precision, periodicity as examples)
cEB: description of terms intent to relative to requirements or
normative defintions for the WG?
goal to make common among docs in WG
illustrative example AIXM temporality model, reference of how difficult
model can be to capture nuance from reality
intended as point of reference only
open call to other models that we can point to and view with the aspects
we are defining
Acee Lindem: different schedules and one based on wallclock time,
wouldnt ...
proper system should follow schedule timeline and real implemention in
wallclock would be mirrored. its a distinct of where its changing.
Acee: schedule change dynamically
model has state, schedule inside that. state of model changes over
wallclock time.
Acee: schedule can allow to change
Lou Berger: where define ...
agumenting existing models and add schedule info into it. schedule
augment model should have the same as the non-augmented model. up to
specification. carry over from axim is identities should not change over
time but other attributes can change. axim everythng can change, tvr
maybe only subset of things can change
Lou Berger: common units, precision, encoding, do we need an information
model?
could inform an info model but existing stuff consolidating to an
information model could be hard
Lou Berger: we need commonality to inform individual solutions
value to do it, but probably not in this document
Tianji Jiang: calrification, how ... model?
draw analogy with existing systems
Tianji: ???
Arashmid: when talk about params, they could be variable as well
Yes, between schedule and wallclock
Arashmid: /???
good point, time precision works in both directions
Gargi Adhav: related to Arashmid, the scope of this ..., will model
detect actual end of schedule window?
good point. the scope of model is bounded by information known at time,
not getting into feedback learning, could be outside model and feed it
in. only what it looks like
Gargi Adhav: ...
cEB: make those notations on mailing list for record

A YANG Data Model for Time Variant Link Availability (10 mins)

Speaker: Eric Kinzie
Document:
https://datatracker.ietf.org/doc/draft-kinzie-tvr-link-availability/

Provide way to descrie time variant links so that predictions can be
conveyed to system that can process it
distruted control plane
central control plane
Current draft has everything marked as readonly, will be fixed
YANG model for attributes when a link can be used
Have some feedback already from mailing list
Brian Sipos: would be helpful to follow exsiting yang network topology
model, no need to redefine nodes/links and augment the base model.
Zheng Zhang: think is good. also something to be fielded as schedule
info ...
Arashmid Arkhavain: question marks on leafs?
they mean they are optional
Arashmid: central/distrubted, how is the model used?
no assumptions made about that. subscription on updates would be a good
approach

YANG Model for Scheduled Attributes (10 mins)

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

Specify an attribute change on recurring schedule
very device centric, such as a router
grouping to augment existing models
not defining protocol extensions
schedule-lifetime group, always, start-end
augment rfc8343 with an scheduled-up-down event
augment rfc8530 with scheduled-power event
augment ospf interface with scheduled-cost (appendix in draft)
ambiguity of recurrence, when does a week start, how many days in month,
years? after schedule? open discussion and want feedback how to deal
with
Arashmid: based on time not location in some cases for a given interface

Brian Sipos: this model is a really good starting point. yang model any
data for more generable and usable. what is month/year feedback into tvr
requirements.
Zheng Zhang: very clear and that other information is not enough for the
node to do the calculation + eriks model can do the things. so merge
would be beneficial.
Marc Blanchet: chat said ... may want to look at this for calender stuff
this. we don't want to import everythng. there is a lot of devil in
details.
talked a lot of times before any previous discussion helpful

Merging Model Drafts (5 minutes)

Speaker: Acee Lindem
Document: https://datatracker.ietf.org/doc/draft-qu-tvr-schedule-yang/
and https://datatracker.ietf.org/doc/draft-kinzie-tvr-link-availability/

Most met yesterday about merge and going to show the path forward. Sandy
was plant to ask for this.
link-availilty: whole topo, scheulde: device model
do things to make more generalized and find a common ground to use
common model and other models using groupings from the common model
cE: thank you for the authors to find ways to merge

Contact Plan Update (5 mins)

Speaker: Marc Blanchet
Document:
https://datatracker.ietf.org/doc/draft-blanchet-tvr-contactplan/

presented in json last time
now a yang model and augment over the bp-yang-model
augment to CALA or neigbour?
should add BP stack properties? could go away or change with merge of
last documents
keep on side, wait merge and then apply results over bp
Brian Sipos: think cast the bp as a yang network topo both operate as
augment and not need to corrdinated.
should of been said in dtn wg
RT: 1 day delay, nature of dtn. almost wonder if there are two models.

ALTO Exposure (10 mins)

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

alto exposed anticipated changes in topology via cost calender feature
strats for adveriting predicted changes, ways of retrieving scheduled
changes
offload processing off the network elements, considerations of new
nodes, expose to applications/services changes
todo: parameterization of model compatability with alto cost calender
todo: document scenarios alto would be helpful providing this data
cTL: netconf for distribution of schedule changes?
yes for sure.
EB: contact graph, overlap with contact graph and alto?
need more info/reading

Routing Considerations (15 mins)

Speaker: Zhang Zheng (Sandy)
Document:
https://datatracker.ietf.org/doc/draft-zhang-tvr-routing-considerations/

motivate discussion on routing implementation
3: centralized, distributed modes
centralized mode:
distributed mode 1: viable node has yang model and adverties info
" " 2: cant advertise info by protocol so helper node is used
explicit scenarios to help yang model design and guide implementation
EB: anything in this work that should be flowed into reqirements?
will read requirements for this
Acee Lindem: at least for the igp the distrubte 2 idk if otherthan
redistrubtion there is a natural way to do that. seems like node itself
where they would update their own state what a proxy is doing. its new
and maybe misunderstood
...
Acee: wouldnt be on behalf for traditional case but in all cases, that
makes sense
Arash: not neighbor whole set of nodes

Open Mic (15 mins)

cTL: end of formal program, open mic time.
Acee Lindem: someone said somethign bout change of location, is that in
charter?
Rick Taylor: space is out of scope for charter due to timebased schedule

cTL: dont see a reason to preclude, ...
Rick Taylor: thank you, great stuff happening here.
cEB: thanks everyone stay active and we will see you at 118!