# IETF 118 RTGWG Minutes {#ietf-118-rtgwg-minutes} Chairs: Jeff Tantsura (jefftant.ietf@gmail.com) Yingzhen Qu (yingzhen.ietf@gmail.com) WG Page: https://datatracker.ietf.org/group/rtgwg/about/ Materials: https://datatracker.ietf.org/meeting/118/session/rtgwg 9:30-11:30 - Tuesday Session I, November 7, 2023 9:30 Meeting Administrivia and WG Update Chairs (10 mins) 9:40 **Discussion of draft-ietf-rtgwg-segment-routing-ti-lfa** Stewart Byrant (15 mins) * Ahmed Bashandy: I don't see reasons we should combine the two drafts. * Stewart: We should not suggest any deployment of FRR without micro loop avoidance. * Ahmed: This has been deployed for years. This is not a consensus. * Bruno: I agree with Ahmed. There are 2 different problems and request 2 different solutions. I don't understand why you mix them together. * Stewart: In TI-LFA, they are together. It requests further clarification. We need strong words for micro-loop avoidance mechanisms. * Bruno: We have a document about the uloop and it has been sent to the list. Please give comments to the document. I disagree many points. Especially we have deployed FRR methods many years and I don't think this is not safe. And uloop is not caused by Ti-LFA * Stewart: I have personal concerns since I see how easy to see microloops, such as in ring network. But we should give more explanations. * Bruno: how about the text we proposed? * Stewart: I'll look again. * Bruno: I disagree that it's unsafe to deploy ti-lfa. * Stewart: there are people worrying about the label stack size. * Bruno: for a link failure, it's guaranteed to be less than 2 labels. * Stewart: indeed. We should provide more guidance. * Peter: I agree with Bruno. Micro loop is not caused by fast reroute. It is caused by IGP convergence. There are many mechanisms for micro loop avoidance. * Stewart: we should consider adding a operation consideration section. * Jeff T: suggest to cooperate, especially with the shepherd. * Yingzhen: There will be a side meeting to discuss further. **Multi-segment SD-WAN via Cloud DCs** https://datatracker.ietf.org/doc/draft-dmk-rtgwg-multisegment-sdwan/ Linda Dunbar (5 mins) * Jeff T: Happy to see the progress and will start to review the document (considering WG adoption) * From the chat: Daniel Bernier09:58 @Linda why is this draft standards track and not informational ? Linda: Because there are IANA registration needed for the proposed TLVs and subTLVs. Please see the IANA Section in the draft. Antoine Fressancourt @Linda Dunbar when and where will the draft be discussed from security perspective ? I didn't get it **Security Considerations for Tenant ID and Similar Fields** https://datatracker.ietf.org/doc/draft-eastlake-secdispatch-tenantid-consid/ Donald Eastlake (10 mins) * Jeff: what's your goal of this document? * Donald: Other documents could refer to this document for security consideration, and make it easy for other documents. * Jeff: That will make it a Normative rather than informal reference? * Donald: that depends. * Jeff: If you want to make a normative reference, it needs to be a standards track document. * Donald: the way it's written it means to be informational. **Problem Statement, Use Cases, and Requirements of Hierarchical SFC with Segment Routing** https://datatracker.ietf.org/doc/draft-nh-sr-hsfc-usecases-requirements/ Kangkang Ni. (10 mins) * Greg Mirsky: The document states that segment routing based SFC has advantage over NSH based SFC. how do you vision packet will go to service function? will your proposal work with the test packet? * Kangkang: Let's communicate more on the list. * Greg: Which identity for Service function forwarder? * Kangkang: Maybe discuss in the list. * Greg: suggest to refer to the document of SFC architecture to go align with the terminologies. * Jeff T: Please send the comments to the list. * Robin: OAM should be considered when discussing SFC **Reliability Framework for SRv6 Service Function Chaining** https://datatracker.ietf.org/doc/draft-yang-rtgwg-srv6-sfc-reliability-framework/ Feng Yang / Changwang Lin (10 mins) * Greg: Dual-homing SF case, what mechanism you envision to detect failure? * Feng: BFD will be fine. * Greg: How to differ 2 types of failures? * Feng: Treat these 2 the same * Greg: one of the cases may cause routing loop * Feng: that's right. there should be some syncup mechanism to let the two SF get the same behavior. * Greg: so your schema gets more complex. * Dongyu Yuan: there are two methods of protection. is it possible to combine them together? * Feng: Good idea. We should consider in later version **Kademlia-directed ID-based Routing Architecture (KIRA)** https://www.ietf.org/archive/id/draft-bless-rtgwg-kira-00.txt Roland Bless (10 mins) * Tony Przygienda: Are you proposing a new dataplane? * Roland: you can use normal IP forwarding, you can use existing data plane forwarding mechanisms like longest prefix match. It was designed for forwarding control plane traffic, so data plane routing is separate. * Antoine Fressancourt: Difference to Babel? * Roland: It's IP based. It is more scalable and was designed mainly for the control plane, because it does not always use the shortest path routes. * Juliusz Chroboczek: Ad-hoc community has been doing this for many years. DHT-based routing mechanisms did not work very well there, leading to loops. You should come. * Roland: Kira was not designed for Ad-Hoc environment. I am aware of the ad-hoc work. * Jeff Tantsura: KIRA paper is behind a paywall. * Roland: (fixed at https://s.kit.edu/KIRA) you can download a preprint version here https://publikationen.bibliothek.kit.edu/1000148953 **Service ID for Addressing and Networking** https://datatracker.ietf.org/doc/draft-huang-rtgwg-sid-for-networking/ Daniel Huang (10 mins) * Gao Fang: On slide #7, who publish the service id? About the control system, is it the one for the network or cloud? for multicloud, how to maintain sync among multiple clouds? * Daniel: Service ID is not solution. The service ID will be governed by centralized control system. * Jeff T: please send your questions to the list. * XueSong: confusing what is the relationship between service ID and APN ID or ROSA? * Daniel: Service ID is lightweight label on data plane. It is an unified identification among terminal, network and cloud. APN ID is only for limited domain inside the network. * Linda: is the service ID an address? * Daniel: No, the Service ID is an ID carried in the packets, such as FlowID in IPv6 header. * Linda: why don't you use flow id? * Daniel: it might be. I don't want to focus on the specific solution yet. * Xuesong: The assumption that APN ID is limited inside the domain is based the previous community discussion, it is not the limitation of APN itself. We have presentation about application side APN work in this session. * Daniel: Have read the document and could have further discussion **Reliability in AI Networks Gap Analysis, Problem Statement, and Requirements** https://datatracker.ietf.org/doc/draft-cheng-rtgwg-ai-network-reliability-problem/ Chengweiqiang / Changwang Lin (10 mins) * Jeff T: are you calling for solutions? * ChengWeiQiang: we are just giving problem statements without solutions. hope people can propose solutions for the identified problems. * Jeff T: Over the years, there have been many solutions to address the problems you have identified. Please go back to select those solutions. For the numbers you mentioned, it will be helpful to provide some references. * Juliusz: why do you need submilsec convergence time? * WeiQiang: If you can control switch over time under 100ms, the AI training can continue rather than go back to some check point even restart the training. * Juliusz: I will take it off line. * Victor: Agree to Jeff and would like to see more discussion about requirement and the analysis why it is, especially those numbers. * Jeff: We will have a side meeting. * Yunping: Different solutions for different topologies, like fat tree/dragonfly? * Weiqiang: Unified solution for all the topologies **Coordinated Congestion Management** https://datatracker.ietf.org/doc/draft-lyu-rtgwg-coordinated-cm/ Yunping(Lily) Lyu (15 mins) * Jeff T: you are assuming there are flows. With adaptive routing, there might not be flows, but packets. many assumptions in the draft are not valid. * Lily: we can have more discussions online. * DongYu Yuan: similar to infiniband. should inherit some from there? Any differences between IP layer ECN and L4 congestion control? * Lily: yes. The key point is that we need to coordinate congestion control and adaptive routing. * Linda D: can you use ECN RFC6040 to achieve what you want to do? * Yily: we can use ECN. but we need to coordinate when to trigger congestion control and when to use Adaptive routing.