Skip to main content

Minutes IETF113: rtgwg
minutes-113-rtgwg-00

Meeting Minutes Routing Area Working Group (rtgwg) WG
Date and time 2022-03-21 13:30
Title Minutes IETF113: rtgwg
State Active
Other versions plain text
Last updated 2022-03-26

minutes-113-rtgwg-00
IETF 113 RTGWG

Chairs: Jeff Tantsura (jefftant.ietf@gmail.com)
Yingzhen Qu (yingzhen.ietf@gmail.com)

WG Page: http://tools.ietf.org/wg/rtgwg/
Materials: https://datatracker.ietf.org/meeting/113/session/rtgwg

Meeting Administrivia and WG Update
Chairs (10 mins)
=============================================
WG document Update

YANG Models for Quality of Service (QoS)
Aseem Choudhary (10 mins)
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-qos-model/
No questions at the end of the presentation

=============================================
3. BIS on RFC 5798
Acee Lindem (10 mins)
https://datatracker.ietf.org/doc/draft-addogra-rtgwg-vrrp-rfc5798bis/
[Keyur Patel] Are you planning to do the same for the YANG model?
[Acee] yes, once the RFC5798 BIS is further along
[Grey Mirsky]I support the draft
[Keyur Patel] We support this work. Would love to do interoperability
[Acee]

[Christian Hopps]I think it can run together
[Acee]Yes
[Jeff Tantsura]We will discuss with AD on where is the right place for the work.
[Alvaro Retana]why not ask the group if RTGwg is the right place.
[Jeff Tantsura]Please raise your hands: 58 raised hands

=============================================
A BoF on APN was held at IETF 111, and update was presented at IETF 112. The
team would like to present an update of their work and address open issues. 4.
Update of APN (20 mins)

APN Problem Statement and Use Cases, Framework and Gap Analysis
Gyan Mishra/Shuping Peng
https://datatracker.ietf.org/doc/draft-li-apn-framework/
https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/
https://datatracker.ietf.org/doc/draft-li-apn-problem-statement-usecases/

[Lar Eggert] I asked a Fundamental issue: when App makes request that Network
can’t accomondate? It wasn’t addressed. So I am not sure of the statement of
all issues being addressed.

so what happens when a hop can’t satisfy the reqs? does the flow get rejected
(and how), or do we fall back to best-effort, and how would an app then even
benefit from apn?

[Gyan Mishra] we will follow up with the answer.

[Jeff Tantsura]This is the 3rd time this being presented. After discussing with
AD, we felt routing is not the right place. So the option is to create another
working group with clear milestone to work on it, and how we proceed after.
[Alvaro] Just to clarify the request is for adoption of the framework, not the
solution. if there are interests to work on those, it won’t be appropriate for
RTG, but for another place to take the discussion. [Jeff Tantsura] Next step is
for us to send email to the WG.

[Jari Arkko]In general, I am quite interested in this Application related
networking. but feel it is too ambitious to specify the user & application char
into the network. If I remember right there were two major issues from the BoF,
one was whetehr we need new encap or use existing ones? The other was several
members felt that the mechanisms might be used for user identity or location
identity etc., this may cause privacy issue. I’ll check the github whether
these are solved. [Jari]IAB is working a document of collaboration between
application and network. it would be a good exercise. I’d be happy to work on
it with the community. The IAB document:
https://datatracker.ietf.org/doc/ht…raft-iab-path-signals-collaboration

[Joel Halpern]The assumption of how application to work with network seems not
the right, especially taking the privacy into consideration. Doesn’t seem to be
the routing problem. Not just about fixing this framework.

[Shuping from the Chat Panel]
All the issues have been recorded in the Github and posted in the apn mailing
list. They are open for review and comments.
https://github.com/APN-Community/Issues/issues
https://mailarchive.ietf.org/arch/browse/apn/?gbt=1&index=#

===============================================
Presentation 5-8 are new individual drafts, looking for community feedbacks for
future work.

Semantic Address Based Instructive Routing for Satellite Network
Lin Han (10 mins)
https://datatracker.ietf.org/doc/draft-lhan-satellite-instructive-routing/

This topic was presented at IETF 112:
Problems and Requirements of Satellite Constellation for Internet
Satellite Semantic Addressing for Satellite Constellation
https://datatracker.ietf.org/doc/draft-lhan-problems-requirements-satellite-net/
https://datatracker.ietf.org/doc/draft-lhan-satellite-semantic-addressing/
[John Scudder] this is very interesting. To my knowledge, SAT network is
proprierity network, doesn’t seem to need interoperability [Lin] We have
identified the reasons for why need interoparability

[Jeff]why RTGwg?
[Lin]There is no WG . We just want to solicit feedbacks.

Considerations for Protection of SRv6 Networks
Yisong Liu (10 mins)
https://datatracker.ietf.org/doc/draft-liu-rtgwg-srv6-protection-considerations/
[Jeffrey Haas]how you provision your BFD
[Yisong]we have another draft in BFD WG to describe the BFD path provision

[Terek Saad] what happens when the egress PE to CE link fails?
BFD session won’t tell you the fault. Protection at the service level (e.g.
BGP) will allow you to propagate such faul back to ingress and allow flip from
primary service path to backup protection path. Such protection at transport
layer is not sat service level.

[Jeff Tantsura]Tarek: please send your question to the list.

[Cheng Li] Thanks to the operator for presenting their issue.

[Jeffrey Zhang] what is the difference from SR?
[Jeff Tantsura] response is not there. Please send the question to the list.

===============================================
7. HPCC++: Enhanced High Precision Congestion Control
Rui Miao (10 mins)
https://datatracker.ietf.org/doc/draft-miao-rtgwg-hpccplus/
Presentation by Bakah on congestion control
[lars Eggert] The congestion control part should be standardized, but in
Transport area. The problem is that you can’t get congestion conditions, and
it’s good if the network can provide such info.

[Jeff Tantsura]This work is important for Data Center networks, and others.

[Dean Bogdanovic]by the time congestion go to the source, it is alreay too old.
Maybe we should have a mechanism to do pulling.

Impact of DLTs on Provider Networks
Dirk Trossen (10 mins)
https://datatracker.ietf.org/doc/draft-trossen-rtgwg-impact-of-dlts/
[Nicola Rustignoli]how about security implication?

===============================================
9. Continuing to Evolve Internet Routing Beyond ‘Mere’ Reachability
Dirk Trossen (10 mins)
https://datatracker.ietf.org/doc/draft-trossen-rtgwg-routing-beyond-reachability/

[Jeff Tantsura]this work is probably more suitable for IRTF.

The following presentation is research focused, but considered relevant to
RTGWG: 10. Things researchers should think about when making proposals to
introduce new approaches in Internet routing Adrian Farrel (15 mins)

https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/
https://datatracker.ietf.org/doc/draft-farrel-irtf-introduction-to-semantic-routing/
https://datatracker.ietf.org/doc/draft-king-irtf-semantic-routing-survey/
https://datatracker.ietf.org/doc/draft-boucadair-irtf-sdn-and-semantic-routing/

[Peng Liu]has this been discussed in COINrg?
[Adrian] we have discussed with IRTF chair, was told that the work doesn’t
belong to COINrg.

[Jeffrey Hass] this is a useful work, wish you can continue.

[Tarek Saad]I see resemblance with another work. I think it is useful.

[Colin Perkins] The feedback I gave to Adrian is not to take the work to
COINrg. maybe icnrg.

[Jeff Tantsura] the work is really interesting, the name might be different.
There are several presentations on this topic. We will talk with our AD to see
what to do next and there might be interims.

##############################################################################
##          Chat History
##############################################################################

Ron Bonica
I know that it is a bit late for this comment, but doesn't this draft belong in
the INT Area? 06:37:00 Adrian Farrel I'd be interested to know how this work
could relate to service level YANG models especially related to "requesting
QoS" in VPN+ and network slicing 06:39:53 Aseem Choudhary Hi Adrian, I can
check service level YANG models and get back on this. 06:51:26 Jeffrey Haas
Acee, no need to carry to mic, but it might be worthwhile mentioning to
OpenConfig to update the small number of places they have similar terminology
in need of update. 06:51:37 Lada 06:52:24 Lou Berger yes 06:52:34 Jari Arkko +1
for making the language changes! 06:53:04 Christian Hopps yes 06:54:18 Peter
Hessler hum 06:54:23 Christian Hopps That was impressive number of hands
06:55:20 Jeff Tantsura thanks everyone for voting! 06:57:41 Jari Arkko Can
someone post the link to the issues? 07:01:17 Dhruv Dhody
https://github.com/APN-Community/Issues/issues 07:02:05 Jeff Tantsura thanks!
07:02:15 Shuping Peng hi Lars, your issue is the first one, and it was
responsed but not closed by you.
https://github.com/APN-Community/Issues/issues/1 07:06:38 it is open for you to
reply and comment any time 07:07:01 Lars Eggert thanks, then i misremembered.
so what happens when a hop can't satisfy the reqs? does the flow get rejected
(and how), or do we fall back to best-effort, and how would an app then even
benefit from apn? 07:09:29 Jari Arkko The IAB document:
https://datatracker.ietf.org/doc/ht…raft-iab-path-signals-collaboration
07:12:21 Shuping Peng @Jari, your questions on the two issues have been covered
in the issue list, please check and comment
https://github.com/APN-Community/Issues/issues 07:15:01 This is a generic
framework, and open for solutions 07:15:44 @Lars Eggert, here is the response
to your raised issue, if you have any comment please directly comment on it:
APN-Github commented on 6 Dec 2021 As described in
https://datatracker.ietf.org/doc/ht…draft-li-apn-framework-04#section-5, the
APN requirements include APN Attribute Conveying Requirements and APN attribute
Handling Requirements. In the APN attributes, the carrying of the APN
parameters is optional as stated in
https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-3. The
typical APN parameters are the network performance requirements such as
bandwidth, latency, etc. If a hop cannot meet the APN requirements, which would
mean that the hop cannot handle the APN attributes, then it will be up to the
local configuration. We can explore more on this topic, but generally the flow
needs to be forwarded without any interruption, probably in a default mode.
07:17:52 Lars Eggert thanks, i saw that. but saying "will be up to the local
configuration" is basically saying that apps will not be able to rely on a
predictable response from an apn network, i.e., they will need to be coded for
a best effort network anyway 07:19:17 Adrian Farrel @lars Isn't that exactly
the point. I think you are saying "This document doesn't work on the problem I
want to work on," and it is OK to say that, but not to say "...and therefore
this approach is not valid." 07:20:30 It's like DiffServ. You set the colour,
but you don't get a guaranty from the network 07:21:07 Jeff Tantsura
@Lars/Shuping - please take this to the RTGWG list, so there's a paper trail
and people can react/comment 07:21:50 John Scudder "paper", heh 07:22:04 Jeff
Tantsura :) muscle memory 07:22:23 Shuping Peng Thank you, Jeff. 07:25:50 The
issues and the responses to the issues have all been recorded in the Github and
posted in the apn mailing list apn@ietf.org, and separated emails have been
directly sent to the issue raisers. People can always review and comment.
07:25:59 https://mailarchive.ietf.org/arch/browse/apn/?gbt=1&index=# 07:26:12
https://github.com/APN-Community/Issues/issues 07:26:21 Yingzhen Qu The draft
is informational, is it intentional? 07:26:43 Lou Berger I think this is
interesting work and worth continuing to discuss @IETF 07:27:01 Stewart Bryant
+1 07:27:21 Lou Berger - no idea which WG though 07:27:25 Wesley Eddy I think
it's great to continue discussing; I don't think there is industry demand for a
standard (yet). 07:27:47 Stewart Bryant We have a big problem with advanced
work that does not naturally fit in IETF as it is not yet reread for deployment
but is rejected by IRTF who do not seem to like routing problems 07:28:48
Adrian Farrel Certainly seems like there should be a home for discussing the
engineering issues that come up with satellite networks. This is rapidly moving
beyond research. 07:29:10 Jeff Tantsura agree 07:29:26 Stewart Bryant However
to remain relevant and we need to be working to where the ball will be, not
just where it is today - this is a structural IETF problem that IESG and IAB
need to work on 07:30:13 Cheng Li agree,satellite network seems very
interesting, and we need a place for discussing it for sure 07:30:32 Boris
Khasanov like specific WG? 07:30:55 Cheng Li yes, a WG may be good, IMHO
07:31:18 Lou Berger or an existing one, e.g., MANET 07:31:34 Adrian Farrel The
standard/proprietary question is important, however. I think we have previous
examples of the benefits of standards-based approaches even in proprietary
networks. 07:31:48 Peter Hessler my previous job was working on designing a
satellite network constellation, and standardization would have helped us
address [redacted] issues 07:32:09 Stewart Bryant Not to minimise sat - there
are other advanced RTG problems that are too big for RTGWG yet we have no good
way to find a good venue for 07:32:14 Lou Berger the same point was raised when
talking about IGP extension back when multi-vendor IGPs weren't a reality
07:32:41 Tony Li Is there anyone from Starlink or Kuiper at IETF???? 07:32:44
Jeff Tantsura MANET might be a choice for the routing protocol 07:32:49 Jie
Dong +1 to Adrian's point 07:32:52 Adrian Farrel However, some of the proposed
re-purposing/overloading of addresses cuts into my slot at the end of this
session. 07:32:53 Jeff Tantsura @tony - very good question 07:33:42 Stewart
Bryant One of the difficulties with digital sat is that is is firmly in IATA
territory, especially given recent applications 07:34:46 Jeffrey Haas The draft
under discussion for bfd return path is
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-bfd-directed-19 07:39:40
Although as best I understand the draft, that's for lsping for mpls, not srv6.
07:40:13 Greg Mirsky Good point, Jeff. Thank you. Will work on multi-part ICMP
extension in support of directing the reverse direction of a BFD session
07:41:34 Jeffrey Haas Thanks, Greg. You've anticipated my suggestion for
followup. Even though the work probably needs to be done in spring, the mpls
chairs will probably want to be kept in the loop. 07:42:21 Cheng Li for
SRv6,you can see this draft, it mainly describes the mechanism of using BSID
for BFD.https://datatracker.ietf.org/doc/draft-chen-spring-sr-policy-for-ubfd/
07:42:59 Jeff Tantsura @greg, specific question for now of at the end? 07:44:19
Jeffrey Haas Thank you, Cheng Li. This draft wasn't in the BFD WG's list of
monitored drafts. I'd invite you to post to the rtg-bfd@ietf.org list to draw
additional attention to your work. 07:45:00 Cheng Li thank you @jeff 07:45:22
@Jeffrey, LOL 07:45:42 Boris Khasanov @Cheng Li - interesting and important
indeed! 07:46:00 Jeffrey Haas
https://trac.ietf.org/trac/bfd/wiki…%20Group%20BFD-related%20Activities
07:48:05 Cheng Li thank you @boris 07:52:20 :) 07:52:26 Yisong Liu @jeff, we
have submit the sbfd path consistency draft in BFD WG, Pls see
https://datatracker.ietf.org/doc/dr…in-sbfd-path-consistency-over-srv6/
07:54:44 Christian Hopps hnm just lost them 07:56:16 Jeffrey Haas Yisong,
thanks for that. Your draft had fallen into the wrong bit of my mailbox. I'll
comment on it later. 07:56:31 Christian Hopps or am i the one that's lost..
07:56:35 John Scudder what are you talking about, chris? 07:56:48 Christian
Hopps lost all audio and video from the room 07:57:05 John Scudder if you mean
the a/v feed, it LGTM 07:57:05 Christian Hopps it's me thne 07:57:12 Yisong Liu
@jeff, Thanks, very appreciate for your review and comments 07:58:43 Jeff
Tantsura @greg - you are still in queue, do you have a question? 08:02:32 Jim
Uttaro Is the pool bounded? 08:03:06 Jeffrey Haas Chairs should mute Greg.
08:06:56 Jeff Tantsura thanks jeff, done 08:07:48 @robin - please send your
question/comment to the list 08:20:33 Stewart Bryant Re IRTF - not handles well
at all

Stewart Bryant
Re IRTF - not handles well at all
08:32:29
IRTF needs to be more open to work in this area and more proactive
08:33:13
Thi sis not really ICN which has its own bagagge
08:33:46
Gyan Mishra
Adrian, I think this work is very useful and I think IETF may have a home here
RTGWG and maybe even TEAS 08:33:50 Haomian Zheng This work is useful, but may
need to be broke into a few pieces to evaluate the impact on various
protocols... Dhruv Dhody Thanks! Great presentations! 08:34:49 Stewart Bryant
The problem with breaking it up is loss of critical mass and cross polination