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