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) {#introduction-note-well--milestones-5-mins} Speaker: Chairs Document: N/A Standard admin fare, no agenda bash # Requirements (20 mins) {#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) {#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) {#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) {#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) {#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 {#open-mic} cEB: anything? thanks and adjouned 6 mins early.