Time Variant Routing (tvr) WG
IETF 119, Brisbane
2024-03-20, 13:00-14:30 ET, Australia
Area Director: Gunter Van de Velde
Chairs: Edward Birrane, Tony Li
Secretary: Adam Wiethuechter
Speaker: Chairs
Document: N/A
Thank you outgoing AD (Andrew Alston) welcome incoming AD (Gunter)
Working on past due milestones...
Use Cases now on RFC Editor Queue! YAY!
Requirments will have WGLC shortly...
YANG Schedule, ready to adopt?
Not tight on time this session, feel free to jump in and discuss things.
Speaker: Luis M. Contreras
Document: https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/
Based on use-case draft
3
4
5
EB: impact on routing protocols; not ... these are deployment impacts?
can you elaborate?
we introduce
EB: no requirements on other routing protocols, thanks!
6
7
8
9
10
11
Kinji CMCC: more general tvr case, terresterial network. my observation
should do also ask something like integration the t and this, the TBR,
non TBR and the TBR, something like that
Why going into multi-domain case to add to document. implications on
trust of where info from. different approaches.
Li: Add some description on the actions of a node when the predict
information is not consist with the actual state.
charter clear. accuracy and segregation of clock.
Rick Taylor: comment on multi-domain. gut doing right thing to do single
first. make that clear early in document.
EB: who has read this document? (poll, y/n/- -- 19/8/1)
Speaker: Luis M. Contreras
Document:
https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/
2
3
4
5
Ping: in arch, network digital twin? is necessary?
Not necessary, not focus. Need something to do prediction.
Implementing this use case - hoping to showcase next year.
cEB: call on mailing list, is there any comment while in person?
Kinji: not regarding adoption. propose to use alto for management.
limit? integrate alto with some other controller that can do management
work for other domain? consider general path solution?
ALTO already had cost-calender feature hence its integration seemed
straight forward along with other IETF integrations (such as YANG
model?).
Speaker: Tianji Jiang
Document:
https://datatracker.ietf.org/doc/draft-jiang-tvr-sat-routing-consideration/
2
3
4
5
7
Dean Bogdanovic: back to slide 3. IUPF can be used for local breakup.
That can be useful. How can you AAA when changing satellites? you have
no restart with new authenticator.
2 proposal. UDM/UDR onboard (being discussed). Integrate ?? and SM and
do one shot for RM and pause in a status TBD so when satellite moves.
Solution to handle host uplink and downlink of text message, has to be
stored somewhere.
DB: to put onboard increases security footprint
Tony Li: slide 5. speak to point 2 about bandwidth. Starlink ISL are 100
GB.
Ran Atkinson: Jeff Houston's Iepg measured data for starlink, lots of
bandwidth.
Dongyu Yuan: relatively high velocity to surface with LEOs.
Preload of information. Out of channel loading of information.
Jeff Tantsura: if you mention restriction say what won't work for you.
Express them in units, not handwaving.
Precalculation.
cEB: time variance, 3gpp is assumptions. document and discuss.
Jie Dong: page 6, two layer routing structure. iamgine using different
schemes in layers, need something from existing data plane?
General concept. Don't change protocols now.
Jenny Cao: Intenion; to keep this in mind for requirements or own
document?
No specific target. We believe sat is unique where TVR is unique.
Dean: asking about making correct rtg decisions between gNB and UPF with
tvr this can fit in wg.
cEB: nothing in charter for routing protocols. how we understand and
model time information.
Dean: no need for routing changes, can just apply TVR.
Li: fixing 3GPP is out of scope.
Disagree, this is use-case.
Dean: gNB and UPF are IP hosts
Jeff: RTG WG hat on, work happening in RTG WG.
Ran: Tmobile already demonstrated 4g/5g to starlink. no problem here?
cEB: there is liason.
Yingzhen: satellite use case in usecase document
Speaker: Yingzhen Qu
Document:
https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/
2
3
4
5
very general so some things might be complicated for us
trying to start from simple schedule to meet requirement
Erik Kline: sldie 5, timezones makes everything worse. datetime start is
bad name. call it "utc start time". interval vs duration?
possibly going to be removed, working with schedule authors for specific
grouping for tvr
Erik Kline: If you want to recurr make the control system do it if want
to make truly simple. so remove that from model.
Sandy Zheng: wondering with overlap, how do we know to do with
interface?
Up to management entity.
Brian Sipos: good starting point, feedback on ML. relate some behaviors
to aspects in section 3 of requirements. choices with terms trying to
define.
Vishnu Beeram: topology augmentation, schedules under links. Extending
to other metics?
Following TE model. We plan to expand, try to get schedule thing clear
than add more attributes.
VB: @node or link level?
Can be at component level.
Christian Hopps: duration an endtime for datetimestart?
Duration is how long schedule lasts.
CH: so end time to start time. ended up going with yang datetime type
for start and end. you want resolution of start and end to be same.
doesnt specify units, seconds with fraction after. just pointing out
what geolocation went with.
Number of seconds may get large if duration in days. We believe its on
right track.
cEB: will do on mailing list, any comments in person for adoption?
Supurb job everyone. Its been much appreciated.
On behalf of chairs thank you for your service. (appluse)
Speaker: N/A
Document: N/A
cEB: mic is open, anything?
Adjourned, 1 minute over!