IETF 112 RTGWG Agenda 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/112/session/rtgwg *************************************************************************** 1. Meeting Administrivia and WG Update Chairs (10 mins) Jeff presented the RTGWG summary. -------------------------------------------- Update of WG document: 2. SRv6 Path Egress Protection Huaimo Chen (10 mins) https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/ [Greg Mirsky] with regard to the SPRING SID compression. There is a decision to adopt the CSID proposal, but it's just beginning. I think it would be good to discuss how it is related to the SRv6 SID compression. [Huaimo] I think SID compression is general to all SIDs. [Greg] it is true, since this document is asking for WGLC, it would be good to address how it is used for this work. It's for the WG to decide. [Acee] I am against it to hold this document until the SPRING SID compression is finalized. The SID compression won't be completed by next IETF. [Loa] Agree with Acee. When we start WGLC, we should point out the compressions SID draft and mention the relationship. [Acee]: fine with me. I just don't think we should hold the work unless it's on SID compression. [Loa] I agree. [Ron Bonica] Pointing to SID compression is like pointing to an unstable reference. [Acee] You point to the compression draft in your email, not as a normative reference. [Loa] yes, in the email of WGLC. It's like a downref, but should not hold up the WGLC. [YingZhen] For all protection related drafts, we will sync up with the SPRIN chairs. ============================================= Presentation 3-6 are new individual drafts, looking for community feedbacks for future work: 3. Problems and Requirements of Satellite Constellation for Internet Satellite Semantic Addressing for Satellite Constellation Lin Han (20 mins) https://datatracker.ietf.org/doc/draft-lhan-problems-requirements-satellite-net/ https://datatracker.ietf.org/doc/draft-lhan-satellite-semantic-addressing/ Maybe we can watch the video offline, https://www.youtube.com/watch?v=M49yyJ0o5YU [Stewart Bryant] you made an assertion that normal link state style convergence wouldn't be adequate for this. Mark Handley did simulation on Satellite and showed it worked really well. Can you explain the difference of the opinions? https://youtu.be/QEIUdMiColU https://youtu.be/m05abdGSOxY Mark Handley's early work on this simulations [Han Lin] I know his research and simulation. Image a network with a couple of thousands nodes, and there are link flags every couple of minutes, it will be unstable. [Stewart] He actually simulated the actual StarLink cluster. we need to be clear with real parameters, Mark was very convincing he thought he could do it. [Zhenbin Li] is using semantic address, what is the forwarding table? [Han Lin] if it's IPv6, it's the same as before. The question is whether we should use the same? we might not use the traditional routing, so we might use the forwarding table. [Zhenbin Li]If not using forwarding table, what would you use for forwarding? [Han Lin] We are looking for community input, to be aware of this challenge. If like Stewart said traditional routing works well, the we can just use that. But I'm doubtful about it. We may need new technology. [Zhenbin Li] Is it research work or the work in RTGwg? [Han Li]I don't know. I'll let the community decide. I've seen a lot of companies doing this, so we may need to provide a solution quickly. [Rick Taylor] It is classic work in MANET, although nodes don't get added or removed often, but they do move in a predictable way. I agree with you classic routing may not work, but you don't have to throw the forwarding away. Discarding it is a big step. You may add some context info. I think it is a good topic to be discussed in Manet. [Lin Han] We can discuss off line. It's very interesting topic. [Rick Taylor] I would think of a hybrid solution, but this is something MANET deals with. [Jeff T] I'd like to focus on Stewart's comments, look at the work done. Please review them and provide some discussion. 4. Accessing Cloud via Optical Network Problem Statement Sheng Liu (10 mins) https://datatracker.ietf.org/doc/draft-liu-rtgwg-optical2cloud-problem-statement/ [JEff] What is your intention for this draft? Are you saying to merge? [Sheng Liu] find common ground and open to merge with the existing work about cloud access. [Deborah] I noticed this is also presented in CCAMP. Just want to say that this is really the work in CCAMP addressing OTN work. VPN work has been on for many decades. They have done layer one VPN already. RFC 4974 adds more sophistication. As for the requirement for lower switching granularity, it is not in IETF; you should go to ITU-T SG15, quite active discussion there. [Sheng Liu] we could evaluate GMPLS, and see whether there are some research work needed, such as multi-cloud. I agree LSU related work should be in ITU-T SG15. [Cheng Li ] I am very happy to see the draft. We had a similar draft on IPv6 posted a year agon. Want to collaborate more. [Haomian Zheng] A question to the WG, we see the two net2cloud WG documents expired and need to check with the WG if there is chances to further integration if there are common objectives and requirements. [Jeff] : Deborah suggested this work may belong to CCAMP, we'll discuss with CCAMP. 5. Cloud-network integration Minxue Wang (10 mins) https://datatracker.ietf.org/doc/draft-wang-rtgwg-cloud-network-integration/ [Cheng Li] We have a Cloud oriented network drafts with requirement and solution. Want to collaborate more. [Jeff T]: do you mean the authors of the draft? [Cheng Li] Yes. both drafts are informational, the scenario and requirements are similar. 6. Preferred Path Routing Framework Stewart Bryant (10 mins) https://datatracker.ietf.org/doc/draft-chunduri-rtgwg-preferred-path-routing/01/ [Peter Psenak] I have a question on scaling. You tried to say the overhead in the packet, not mention the price of putting overhead into the IGPs. If you have many paths, how do you scale if you put this into IGPs? [Stewart] We are not talking about entire Internet. it is might be the edge. There are more work on reducing the flooding. [Peter Psenak] You mention flex-algo can do 128, so I assume you'd need more than paths. [Stewart] We haven't talked about flooding reduction much about this work yet. You know where the info will be used. [Peter] That is my the concern of putting too much in IGP. [Terek Saad] There is a per path state stored or maintained on every node in the IGP domain, right? [Stewart] we haven't talked about flood reduction. It definitely need to be store on the nodes that need to know about it, but that's reasonable. [Tarek Saad] We have a draft of similar approach. The IP/TE path is programmed and present *only* on the nodes along the path by elying on RSVP protocol. As opposed to flooding in IGP and storing per-path state information in IGP on all nodes. reference: https://datatracker.ietf.org/doc/draft-saad-teas-rsvpte-ip-tunnels/ [Stewart] The current philosophy is to get rid of RSVP. using IGP can work with any network, like IPv4,. But replying on TE only works with MPLS network. [Tarek Saad]: RSVP with extensions reference can program native IP paths. Just want to make sure there is per-path state maintained in IGP. [Andrew Alston] I really like the this draft. We do have a need for lower cost technology. This is really useful for us. [Stewart] really interested in knowing the use cases. =============================================== A BoF on APN was held at IETF 111, and there were questions to be answered, for example whether existing IETF solutions could be used (Detnet was specifically mentioned). The team would like to present an update of their work and address open issues. 7. APN. (25 mins) APN Framework and Gap Analysis updates Gyan Mishra/Shuping Peng https://datatracker.ietf.org/doc/draft-li-apn-framework/ https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/ [Jeff] Please focus on the changes. We've seen the material multiple times. [Terek Saad]Are you looking for per flow ID? or per group of flows ID? [Gyan] one Flow ID can aggregate multiple flows. it's up to the operator. [Terek] per Flow ID can be carried today in packets - and load balancing can work on that flow ID. [Rick Taylor] I am glad you mention the QoS as the de facto for labeling applications. One property of QoS is When you traverse a tunnel, the QoS can be preserved. Do you consider the similar model? From the inside layer to the encapsulation? [Gyan]Yes. The ID will be throughout the APN domain and removed after the domain. [Rick Taylor] I really like this work. We have been searching for this for a long time. It is very useful. Totally support it. APN Header and IPv6 Encapsulation Robin Li https://datatracker.ietf.org/doc/draft-li-apn-header/ https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/ No time available for questions. APN FlowSpec and YANG Shuping Peng https://datatracker.ietf.org/doc/draft-peng-apn-bgp-flowspec/ https://datatracker.ietf.org/doc/draft-peng-apn-yang/ [Greg Mirsky] what information in the profile to indicate the jitter, to be added in the IPv6 encap or APN, how they are used, for Forwarder? or local path selections? Let's discuss it on the list. =============================================== The following draft is from ICCRG but considered relevant to RTGWG: 8. HPCC++: Enhanced High Precision Congestion Control Rui Miao (15 mins) https://www.ietf.org/archive/id/draft-miao-iccrg-hpccplus-00.txt [Robin Li] what is the intention of the draft? is it to ask for more work? we have TEAS WG and IPPM WG. [RuiMiao] IPPM only specifies the format on packets. Our proposed work also include framework, logic, and path selection. We are hoping to create a framework, how to choose a route based on the the condition of a route. [Jeff] This work is very interesting. we will be working in this area. This presentation didn't happen due to time limitation. The following is a BFD draft, since there is no BFD session it will be presented if time allows: 9. Signal Degrade Indication in BFD Liuyan Han (5 mins) https://datatracker.ietf.org/doc/draft-hwy-bfd-sdi/ ***************************************************** Chat History ***************************************************** Lorenzo Miniero Jeff: did you mean to use the preloaded slides? You're sharing the screen instead 07:57:07 Andrew Alston did we lose audio? or just me - or no one saying anything 08:00:27 Aahh there we go :) 08:00:56 Stewart Bryant Are the chairs going to share the slides or do speakers need to share their own? 08:05:16 Yingzhen Qu all slides have been preloaded. so if you want to present yourself, use the "share preloaded slides" icon 08:06:20 BEHCET SARIKAYA I read Lin Han's draft-lhan-problems-requirements-satellite-net I think it is very informative :) 08:06:27 Jeffrey Haas old rtgwg wiki: https://trac.ietf.org/trac/rtgwg/wiki 08:06:37 ~dhruv~dhody~ @chairs - Wiki for your reference https://trac.ietf.org/trac/pce/wiki (also looking for ideas to improve it) 08:06:48 BEHCET SARIKAYA who is this lady talking in the background? 08:08:24 Jeff Tantsura Thanks Dhruv! 08:09:55 Yingzhen Qu thanks, Dhruv 08:10:44 Jeff Tantsura my audio went away 08:11:32 BEHCET SARIKAYA SRv6 is kind of source routing with all these SIDs, right? 08:12:11 I see that lady was Qu 08:13:02 Yingzhen Qu didn't realize you meant me. :) 08:13:44 Stewart Bryant Yes it is a re-introduction of IP source routing 08:13:48 BEHCET SARIKAYA Thanks @Stewart 08:14:58 Boris Khasanov Agree with Acee 08:16:00 Cheng Li Good to hear this topic, and happy to see more people are interested in this scenarios. We posted an IPv6-based Cloud-oriented Networking draft one year ago, which describes the same thing with IPv6 layer solution, https://datatracker.ietf.org/doc/html/draft-li-rtgwg-ipv6-based-con-01 08:25:39 again! Good to see the draft @sheng liu @haomian zheng 08:26:10 Haomian Zheng Thank you Cheng, looking forward to have more common approaches for network-cloud. 08:27:26 Acee Lindem I don't see the need for a specific cloud requirements for optical networks. 08:35:29 Wim Henderickx there was a lot some work to update the net2cloud drafts. So they are in dormant mode afais. 08:35:58 John Scudder +1 acee 08:36:15 Wim Henderickx i also agree with acee net2cloud should be agnostic to the technology we use 08:36:24 Acee Lindem The only thing unique I heard required was more granularity and that is an ITU requirement (as Deborah indicated). 08:36:39 Haomian Zheng just because net2cloud should be tech-agnostic, we bring the optical consideration here to check if this is useful input. 08:38:44 the objective is just to check if there are common objectives, and the potential solution extension would belong to ccamp (as indicated by Deborah, thanks) 08:40:39 Andrew Alston For me - either of those 2 that aren't trying to inject even more stuff into the ipv6 address and further pollute its semantics would be just fine 08:48:25 Steven Hartley Maybe we can watch the video offline, https://www.youtube.com/watch?v=M49yyJ0o5YU 08:50:10 around 4 min, is where you see the good stuff :-) 08:50:43 BEHCET SARIKAYA my Q would be: do we need ground stations when we have ISL? The draft is not clear on that 08:53:00 Doug Montgomery Using ground relays for low-latency wide-area routing in megaconstellations https://dl.acm.org/doi/10.1145/3365609.3365859 08:55:31 Stewart Bryant https://youtu.be/QEIUdMiColU 08:56:06 https://youtu.be/m05abdGSOxY 08:57:15 Mark Handley's early work on this 08:57:30 - the simulations 08:57:42 Alexander Clemm Why Manet? I don't think there is any ad-hoc-ness in satellite networks 08:57:46 Stewart Bryant Yes, it is the antithesis of ad-hoc 08:58:06 Jeffrey Haas I believe for the relaying technology. 08:58:19 Stewart Bryant Rather it is rightly predictable 08:58:21 Jeffrey Haas There were some nice rtgwg/rtgarea presentations on manet over the years. 08:58:37 perhaps the manet chairs will re-share to rtgwg so people can review them 08:58:58 Stewart Bryant Even the ground station is highly predictable 08:59:24 John Scudder It's largely a fixed network IN THAT you can predict its state at any given time using an ephemeris. 09:00:01 Although granted the uplinks are subject to atmospheric conditions. I thought Rick's comment was right on. 09:00:39 Rick Taylor I say MANET because there is movement - it may be predictable, but once per-complete orbit of the entire network the topology changes. It might no be "Ad-hoc" but it is definitely 'constantly dynamic' - there are MANET protocols that work in this space, and the WG contributors have experience in this field 09:00:40 Stewart Bryant What no one discusses is that to get licences LI will need to be supportd 09:00:42 That means a pure space autonomous network is unlikley to get licensed 09:01:34 Alvaro Retana +1 Rick 09:01:38 Russ White MANET is largely just focused on autonomic operation with little operator input ... the protocols there should work fine for this application, or even BABEL 09:01:59 Alexander Clemm The movement is entirely algorithmically predictable. There is nothing ad hoc to account for. You can use very different mechanisms to exploit this. 09:02:21 Stewart Bryant I agree with Alex you can use an IPFRR method for when you get purturbayions 09:03:05 purtabations 09:03:12 Rick Taylor +1 Russ. The trick here is to avoid waiting for consensus because of the high rate of topological change. The solution might (should) be reasonably simple, but constantly running a LSP to maintain the routing table is not an elegant approach (even if it has been shown possible) 09:03:27 Jeff Tantsura +1 Russ - I'd think so too 09:03:50 BEHCET SARIKAYA Manet may make sense because Manet comes into operation when the infrastructure does not work like earthquakes, fires, etc. so we need satellite infrastructure 09:04:06 I don't know if what I wrote makes sense 09:04:30 Rick Taylor @Behcet - for that I suggest DTN.. 09:04:58 Stewart Bryant ... but do not forget this will be a licensed service and in addition to connectivity you will need to support interception. The constraints on global radio networks tend to be different from the constraints we are used to in the Internet 09:05:52 Rick Taylor @Stewart - I'm focussing on L3. That might be aspirational, and the flown solutions might well be entirely proprietary, but if the IETF wishes to spend cycles on this problem, I think MANET has the correct density of expertise 09:07:07 Stewart Bryant Equally there will be politically embargoes paths of the sort that the operator community address, but the protocol engineers tend to ignore. 09:07:19 Rick Taylor Above the Karmen line (100km) is the same as International Waters under a UN resolution from 1970s. Most states with an issue with that resolution do not have the launch capability to go against it. 09:09:19 Cheng Li BSID is only a SID, it will be forwarded following the SFP. 09:15:34 Lin Han @Rick I have check the MANET to see how much overlapped area of the problems and possible solution. 09:16:42 Cheng Li But PPR ID will indicate to forward the packet follow a TE path, since the forwarding actions will be configured all the nodes along the path. Like RSVP-TE. Get the per-path state back to the intermedia nodes 09:16:51 BEHCET SARIKAYA @Stewart: good work, good presentation 09:17:15 Cheng Li if I get it right 09:17:17 Andrew Stone @Cheng bsid is attached to a tunnel, and the path of that underlying tunnel can be traffic engineered, not just shortest path 09:18:42 Shunwan Zhuang It introduces the state per ppr-id per node ? 09:19:19 Cheng Li that TE path will be specified by the SID list after the BSID is processed by the node which allocates the BSID. 09:19:34 Tony Przygienda link-state ethernet? I'm "trill"'ed ;-) 09:20:10 Ketan Talaulikar So get rid of RSVP-TE and put more state that it did into IGPs? Doesn't seem scalable to me. 09:20:14 Jeffrey Haas seems a state trade-off. link state gets more noise. doesn't mean state in the nodes themselves in quite the same way as rsvp 09:21:12 Tony Przygienda paper tigers scale indefinitely, are infinitely cheap and really, really simple ... 09:21:17 Tarek Saad related to PPR https://datatracker.ietf.org/doc/draft-saad-teas-rsvpte-ip-tunnels/ 09:21:22 Tony Przygienda the moment you garbage can your IGP the results tend to be mediocre since IGPs are stressed eough as they are just to make sure you can get from A to B and not loose traffic when the network hick-ups ;-) 09:22:07 BEHCET SARIKAYA Don't understand how my chat message gets into the meeting minutes? 09:22:57 Jeff Tantsura @jie - you could ask your question here 09:23:25 Yingzhen Qu @BEHCET SARIKAYA, we copy the chat history into minutes. any comments? 09:24:02 Ketan Talaulikar Flooding reduction does not reduce LSDB. 09:24:12 John Scudder @behcet you want your chat comment in the meeting minutes? Best way to be sure is go put it there, it is a shared docuemnt. 09:24:15 (note taking tool is accessible using the icons in the upper right of the meetecho screen -- third icon, box-with-pencil) 09:25:53 Adrian Farrel The chat is archived, and it is not the same as the minutes. If we all go and write random stuff in the etherpad it loses all value as a record of the decisions made in the meeting 09:26:26 Jeffrey Haas IMO, important comments are worth repeating on the WG mail list. That is archived, and provides a way for others to respond. 09:27:33 John Scudder Well, different groups have different approaches to substantive comments made in chat. It's hardly unknown for them to be included in the minutes, nor is it inappropriate. Nor is it either unknown or inappropriate for people to make sure their comments are reflected accurately in the minutes (regardless of medium the comments were made in). 09:27:40 Yingzhen Qu Usually I copy the chat history and put in the minutes as a special section 09:27:49 John Scudder nice 09:27:58 Adrian Farrel exactly 09:28:04 Jie Dong @Jeff, ok,, I was to ask about the relationship with network slicing, but now it is ok. Rick Taylor @gyan - this is really important work. You're right about QoS being the de-facto alternative 09:33:08 Shuping Peng @Rick, thank you for your interest and support of the work! You can find more information in this wiki https://datatracker.ietf.org/wg/apn/about/ 09:39:52 more archived materials can be found here: https://github.com/APN-Community BEHCET SARIKAYA @Qu you may do anything you like, you are the chair 09:42:17 Linda Dunbar @John Scudder: I have incorporated many comments into the Etherpad notes under their discussion topics 09:47:44 Gyan Mishra @Rick, Thank you. Yes QOS has been the defacto standard for decades and it will be around I think forever for IP SLA. What APN does is quite unique as it takes QOS and Diff-Serv TE etc to the next level being able to classify traffic with flow based granularity which fits perfect into SR intent based stateless architecture where micro and macro steering can now occur at the APN head end mapping flows to discrete SR-TE instantiated paths. This avoids any hardware DPI and would provide more efficient use of hardware resources as the APN ID is in the outer payload encapsulation so don't have to go deep into the payload for classification / path instantiation as well as for IOAM for example classification / path instantiation. Thank you 09:47:51 Eduard V HPCC draft expired. 09:50:35 Jeff Tantsura @EV - this is IRTF draft 09:51:08 Rick Taylor @Gyan - thanks - I do understand. Annoyingly I have had to use custom IP option headers within my private networks to achieve the same thing for years. It will be great to see this standardised and then I can drop my hacks. 09:51:34 Gyan Mishra @Rick, Excellent and many thanks for your support on this work. 09:52:33 Rick Taylor @chairs - really good agenda this time - lot's of interesting subjects. Thank you! 09:54:26 Jeff Tantsura @rick - doing our best ;-) Eduard V HPCC is the science - it is not possible to understand in the format of I-D presentation. Deep dive is needed.