Time Variant Routing (tvr) WG
IETF 121, Dublin
2024-11-05, 16:30-17:30 UTC
Area Director: Gunter Van de Velde
Chairs: Edward Birrane, Tony Li
Secretary: Adam Wiethuechter
Speaker: Chairs
Document: N/A
Standard admin, note well, note really well, meetecho and the tools
Milestone review
Use cases is now RFC9657, congrats.
Think of additional work and what comes next
No agenda changes.
Speaker: Li Zhang
Documents: https://datatracker.ietf.org/doc/draft-wqb-tvr-applicability/
How to use data model and information
Concrete use case of Tidal Network
Example based on the well known differences between light and heavy
traffic periods
Chair(Ed Birrane): When we consider the applicability I-D, do we need to
consider this single
Rick Taylor: if a single use case in document, then its more focused on
Tidal. General needs more than 1 use case.
Dan King: need at least a couple. In document is easily understandable
however. Force to think about messaging and communicate YANG models. WG
help identify the next use case.
Luis Contreras: other usecases should exercise differently to show
differences.
Rick Taylor: this is a great starting point. Danger to paint WG into
corner.
Chair(Ed Birrane): would there be different applicability documents for
other use cases?
Yingzhen Qu: The YANG model includes a device and service model, you
might want to define which you are using?
Li: Yes, I will make it clear.
Daniel King: Highlight as contributor there are options being discussed
on previous slides. What would be useful to remember that we want to
show instantiation of this work. Hackathon participation welcome.
cEB: yes, mailing list for scoping of the document before adoption and
call for hackathon
Speaker: Daniel King
Documents: https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/
We are reflecting what TVR would like to provide
Planned changes based on Tidal example from last presentation
Objective functions for resource use
Security side is about things to think about, not how to mitigate
cEB: clarify would we levy security requirements?
Dan: I do not know. Need to make clearer as these are requirements, not
just "nice to have" I will specifically look at them and see if anything
obvious has been missed. Try to be a bit more proactive. Also, the
section title "Security Considerations" was from tghe template we used,
maybe we need to change to "Security Requirements".
Rick Taylor: Constraint factors. No motion? Motion of the platform.
Occlusion from orbits.
Dan: Line of sight is consideration. These (on slide) are objectives
added to the document, we may already have [known/planned] occlusion
as a constraint, I will check and make sure we address is.
cEB: how many have read -04?
Dan: Looks like 4 (people), more reviews would be welcome. Ideally,
people should not wait until we Last Call the I-D. Review now and it
will make a better document for when we do enter Last Call.
Speaker: Luis Contreras
Documents:
https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/
We have aligned to the security consideration from -requirements
Arch has schedule requester, consumer, responder
Implications of the schedule
More use cases help exercise
Working on implementation, hoping for next IETF
Asking for adoption, feels stable and presented in previous meetings.
cEB: for those who have proposed updates, has anyone read most recent
and feels a comment has not been addressed?
No response.
cEB: does anyone have objection to off-path approach?
No response.
cEB: any other comments? who has read latest? request to read latest
cEB: If we are qasked to provide an adoption poll, we need to make sure
that enough people have read the document.
Luis: I will try to encourage engagment on the list, and have people
read the document.
Speaker: Yingzhen Qu
Documents:
https://datatracker.ietf.org/doc/draft-ietf-tvr-schedule-yang/
Device model now is consistent and uses URI for node-id
Believe that high level model is good and want community feedback. Leave
the augmentation space is open and easy to do later.
cEB: for delay variable, what is the unit of measure?
Yingzhen: It might be "ms", I need to look at the model. Seconds would
be too large, I will check.
Rick Taylor: I have uses where delays are in minutes. Other things apart
from UTC, as this caused some issues for the deep space use case?
Possible for extension point for a time baseline?
Yingzhen: Talked to Marc about this a bit. Originally time zones were
ruled out and everyone wanted UTC.
Marc(?): See next presentation.
Acee: The units are "ms"（micro seconds）.
Yingzhen: Yes, we did have a previous discussion.
[Bullet on slide "Request YANG Doctor Review"]
cEB: Yes, a YANG Dr review would be good.
Luis: For the device model, we have node and link. Do we need less
granularity? For instance, if the change applies to a card, going link
by link could be very annoying, specially for those cards with high
density ports. On the other hand, for the topology model, the links are
considered to be unidirectional. Not sure if at the time of execuring
the schedule this can create inconsistencies.
Yingzhen: Are you proposing to consider bidirectional links?
Luis: Not sure, just raising the point for discussion.
Speaker: Marc Blanchet
Documents: N/A
sAW: How do timezone work? Nobody knows...
Got some data from JPL for Earth to Mars schedules
For TVR use in this use case need local time on orbiter
SCET is not static mapping to UTC
Tony Li: UTC seems like an absolute reference? why cant SECT have
mapping?
Oneway light time changes.
cEB: when get down into smaller numbers, get relativistic effect.
spacecraft ages are different if younger
Tony Li: keep model in UTC and make device compensate.
Yingzhen: device on Mars should know how timezone works there.
Marc: punt to someone else.
Dan King: choose mars or spacecraft which will be different from earth
("UTC") depending on how far it is from the earth, or how fast it is
moving, they will be different time zones.
Marc: each has its own time mark(?)
cEB: understood resolution of that time. in the schedule itself what are
the error bars/fidelity
Marc: current feeling is maybe an augmentation.
EB: CCSDS, they have working group dedicated to time sync in astronautic
distances.
Back to Chair Slide "Document Status"
cEB: Any comments on these documents (including the ALTO I-D)?
No response.
cEB: meeting closed