SPRING WG - Source Packet Routing in Networking Chairs: Bruno Decraene James Guichard Joel Halpern Secretary: Shuping Peng =============================================================================== Session I Monday, 12:00-14:00, July 26, 2021 (UTC-7) o SPRING Status [ 5 minutes ] Chairs No comments received. o SRCOMP Design Team update [ 15 minutes ] draft-srcompdt-spring-compression-requirement draft-srcompdt-spring-compression-analysis Weiqiang Cheng o SR Compression analysis discussion [ 15 minutes ] WG Jim Guichard: Trying to find the noise (rain?) from the presenter. Weiqiang Cheng: Not sure, the presentation is nearly finished Joel Halpern: Questions from Gyan? Gyan Mishra: Will wait till the Q&A. Gyan Mishra: what is the time line. Will there be multiple solutions or pick one? Joel Halpern: It is up to the WG. Chairs will do what the WG wants. Not up to the design. Andrew Alston: Congrats on the good work. Based on the presumption on SRv6. CRH is not related to SRv6. We have no need for SRv6 only CRH. May not be valid on everthing else rather than SRv6. Jim Guichard: Ron wants to join the Queue? Ron Bonica: Control plane drives the whole thing from the controller... Keyur Patel: CSID is alomst a superset. Looks like a solution going ahead. Issue a WG adoption soon? Weiqiang Cheng: The current CSID has combined several solutions. From the DT, we have analysed different solutions and presented the results. We hope the WG consider the adoption. It depends on the WG's decision for the adoption. Keyur Patel: Looks like good analysis and it looks solid. Joel Halpern: We want to know what is the WG thinking. Keyur Patel: Comes from individual. What is the agenda of the Chairs? Jim Guichard: The WG Chairs have not made decision. Looking for inputs from the WG. Keyur Patel: That helps. Thank you! Daniel Voyer: Goes back to the slide Conclusions summary 4/4. "All requirements are not equally important". It is kind of weird. Is it that we have the agreement on the requirements before the analysis? Talking to the DT whether it has been discussed among the team members before. Weiqiang Cheng: In the DT, maybe some reqiurments are MUST, and others are SHOULD. We provide all the possible requirements from the DT side. We listed this sentence because some members in the DT have some concerns that the requirement draft may cause some misunderstanding that the requirement items have been given different importance. I don't agree and it is not necessary either. Jim Guichard: Causing my confusion as well. To me the slide says that either the solution meet the requirement or not. When you choose solution, some requirements may not be considered about. The key point is that either the solution meeds the requirement or not, and it is not about whether this requirement is significant to a particular operator, right? Weiqiang Cheng: Yes. Do you have any suggestions to the DT? Jim Guichard: No, just to try to understand. Daniel Voyer: Should we go back to the requirements draft before we even look at the analysis document? It is quite obvious that SRv6-based is a MUST. But after a year, we found that CRH does not meet the requirement. It does not provide a fair assessment. We are confusing with SHOULD and MUST. Joel Halpern: A good topic for the mailing discussions. What the WG wants to do this. Weiqiang Cheng: OK, thank you. Daniel Voyer: OK, done. Wim Henderickx: What is the WG going to do for going forward? As a vendor we would like to select one soluiton out of these. This is heavily data plane impacting. Otherwise, we have to implement them all. How would we do that? Weiqiang: Questions to the WG Chairs? Joel Halpern: We want to see discussions on the contents of the two drafts on the list. We need that input. Jim Guichard: People please go to the mailing list and express your specific views. Chairs got their own opinions. We try not to influence. Mailing list is really encouraged. Darren Dukes: It will be great if the WG could pick one of the solutions. The DT has done a lot of work. Be great to get comments on the work produced by the WG. Cheng Li: Tough work in the past year. Please look at the text. Customers want the solutions. Joel Halpern: Close this section. o SR-TE Path Midpoint Restoration [ 10 minutes ] draft-hu-spring-segment-routing-proxy-forwarding Huaimo Chen Greg Mirsky: If understand correctly, you suggest that not all the nodes may support the timer, the convergence is going to be problematic. It seems that the same is applicable to this proposal. All nodes in the domain have to support this. Why do you think all the nodes will support this proposal rather than supporting the timer? Huaimo Chen: If the node does not support the timer it will drop the packets. In draft T, since proxy P advertises proxy capabilitiy so we can select the route that can support the capabilities. This proxy solution may be a bit better since it has more information in the network. Shraddha Hegde: The same question as Greg. If the receiving router doesnot support draft T, it is the same. The advantage of the draft T is that if certain PLR does not support local mechanism for protecting a node, then draft T has a better soluiton. So far whatever protection mechanisms have been built upon SR TI-LFA. They all follow the post-convergence path, and never diverge from the post-convergence path. If certain PLR is not created, you are diverting from the post-convergence path. We need to discuss how much importance is the use case. Huaimo Chen: For some nodes that don't support, we can provide some protection. Shraddha: We need that discussion. Peter Psenak: Small note on what Shraddha just mentioned. Regardless of this draft, the TI-LFA path may not follow the post-convergence path in the case of node protection or SLG protection. That scenario can happen. Huaimo Chen: Yes. Thank you. o SRv6 Midpoint Protection [ 10 minutes ] draft-chen-rtgwg-srv6-midpoint-protection Xuesong Geng Greg Mirsky: The node that provides protection is expected to have a state of the notion about its edges and their capabilities so it can select. Question is two folds. How is this node that switches to another egress knows that this alternative is still capable? If you switch to a node that is not working, so there would be no benefit. Why do you propose to use local protection for this rather than to have e2e protection so not to create states in the transit node and let the ingress node to do the switch over if something failed? Xuesong Geng: Another case, when the existing node find its neighor node not working and it is an endpoint, it will switch its destination address to the next endpoint. If the neighbor of the next endpoint finds that this endpoint is not working, it will switch to another endpoint. It will be similar till the last endpoint. Greg Mirsky: To some extent that answered my 1st question. Xuesong Geng: E2E protection may have their limitations such as BFD or other detection mechanisms. Local repair will be faster. The packets won't be lost for a long time. Greg Mirsky: Not agree that the local protection will not use BFD. Xuesong Geng: Right, it depends. Greg Mirsky: BFD must be used. Xuesong Geng: The detection will be still needed. But at least it will be faster. Greg Mirsky: Regardless of single hop or multi-hops, BFD can be used aggressively. Xuesong Geng: Like TI-LFA for the transit node, we can treat it as local repair. This work has its scenario. Greg Mirsky: Don't agree with the approach that harmonizes everything in a nail. Not necessarily the same mechanism works for all the scenarios. Bruno Decraene: As individual contributor, slide 4 please. Transit IPv6 node is changing the IPv6 header. It can be seen as a violation to RFC8200. Xuesong Geng: Similar to TI-LFA, we need to make the repair node to some extra capabilites to enable the protection. Bruno Decraene: For protection you may need to do something. Xuesong Geng: The transit will be required to change the SRv6 header. The transit node is also trusted in a limited domain. Bruno Decraene: It needs to be discussed in 6man since it changes RFC8200. Xuesong Geng: We can also bring it to 6man. Zhenbin Li: Explaination to Greg. When BFD is for local protection, one BFD session is needed for one link. If BFD is used for end-to-end failure detection, it will need 1 BFD per SR path, this will bring more deployment burden. And if BFD is for local detection, the detection period is shorter. If the BFD is for E2E, the timer will be longer. This is the case in practice. Jim Guichard: Please take the discussions to the mailing list. o BGP Extensions of SR Policy for Path Protection [ 5 minutes ] draft-lp-idr-sr-path-protection Yao Liu No comments received. o Segment Routing for Redundancy Protection [ 10 minutes ] draft-geng-spring-sr-redundancy-protection Gyan Mishra Jim Guichard: Going to allow only one question. Greg Mirsky: Suggest to analyse why this is more beneficial than just 1+1 protection when you select the working source and protection source and do the switchover not per packet but source. Jim Guichard: The line is cut. Please take your questions to the mailing list. Zhaohui Zhang, Balazs Varga, Janos Farkas were in the queue. Janos Farkas suggested in Jabber: Well, relationship with DetNet is not clear. Perhaps join the DetNet session. o SRH and IP header protection [ 10 minutes ] draft-chen-spring-srv6-srh-security Meiling Chen Ron Bonica: How this solution deal with the mutable fields in SRH since there are many of them? Why is this solution preferable to just using the the AH in just IPv6? Meiling Chen: It just covers several key fields in the SRH such as source address. Can you discuss the second questions in the mailing list? Ron Bonica: Sure, will do. o Segment Routing Header encapsulation for Alternate Marking Method [ 10 minutes ] draft-fz-spring-srv6-alt-mark Giuseppe Fioccola Ron Bonica: IETF has defined several routing headers. If you want this alternate marking to be available to all the routing headers, the right place would be the destination options header that proceeds the RH. Why do you choose the SRH instead of putting it into the DOH that proceeds any routing header types? Giuseppe Fioccola: In 6man, we have applied the DOH. For the case of SRv6, it may prefer to use SRH TLV where the DOH may not be supported. Ron Bonica: Since it is already allowed in the DOH at the end of the Extensions header chain, is it also allowed in the one that proceeds the routing headers? Giuseppe Fioccola: It will be the same behaviour. The concept has been expressed in our draft. You will have two options to choose. It will depend on how you deploy. o S-BFD over SRv6 [ 5 minutes ] draft-li-sbfd-over-srv6 Zhiqiang Li Greg Mirsky: The draft is tagged as informational. But looks like you are requesting a field in the flag. In that case, similar can be achieved with the binding sid if you concern with the length of the sid list. Then it will be appliable to both sr-mpls and srv6. Another concern is the sbfd is defined for multi-point network. So I wonder you will consider only point to point or point sr policies to multi-point sr policies as well. Zhiqiang: We just consdier point to point for the first draft. The next draft may consider p2mp scenario. We can talk in the mailing list. Jim: Thanks for attending. See you next time! ===== appendix: copy of the chat ==== Tony Li This member would like to see SRv6 be deprecated. 21:35:41 Andrew Alston my take on this is adopt all of them - they have different use cases as well - and you have people who are prepared to work on them 21:35:45 Joel Halpern @Tony - heard @Andrew - heard. Please send email. 21:36:10 Eduard V Too may solutions would fraction the market. Slow down overall adoption. Not all vendors would implement all solutions that would break interoperability. Hence, solution should be one. 21:43:38 Martin Vigoureux I'd be very concerned if the WG was to restart all the DT work. Yes, that's input to the WG, but valuable input, resulting from a lot of work from a diversity of individuals. 21:44:20 Éric Vyncke +1 21:44:33 Zafar Ali +1 21:44:57 Kamran Raza +1 21:46:53 Boris Khasanov If more than 1 solution they should be somehow compatible or support interop (additional complexity) 21:47:25 Zafar Ali I agreed with Martin. Especially because key author from each solution were part of the design team! 21:47:35 Jim Guichard @Martin the chairs would like to see mailing list discussion on the analysis so that we can take a decision on which document/s to progress 21:48:39 Cheng Li The result is a very valuable output for sure. It is hard to get all the people to agree all the text in the DT. So hope you guys can read the text if you have free time. 21:49:20 Ron Bonica Zafar, Actually, this is not true. The design team included 7 individuals. 5 were co-authors of CSID, 1 CRH, 1 UIDSR, 0 VSID 21:50:10 Cheng Li BTW, over 10 vendors have made their choices and finished the interop-test in the past year. This year, our customers around the world need the solution. 21:51:05 Stewart Bryant If node N1 advertises the N SIDat a hight cost wouldn't normal FRR fix this? 21:51:36 Jim Guichard @everyone please send your comments on analysis to the mailing list - if you believe only a single solution should be moved forward say so, if multiple then say that too - the chairs are looking for guidance from the WG rather than taking a decision without WG input 21:51:41 Darren Dukes @ron, I believe your accounting is not correct Ron. 21:51:46 daniel.bernier@bell.ca I agree with Martin, prior to the design team we were arguing in face to face meetings and perpetually on the the mailing list ... which triggered the creation of a design team if I remember correctly. If the end result of this effort is to again await ML discussions to come up with agreement, we might might end up with DT#2 @Jim will add my latest comment to the list thansk 21:52:44 Jim Guichard @daniel the chairs will make a decision one way or another but we would prefer to do that based upon WG input and feedback on the DT work outputs 21:53:24 Ron Bonica Maybe the solution is to let multiple solutions proceed and let the marketplace decide After all, the marketplace knows best what it wants 21:54:36 daniel.bernier@bell.ca 10-4 @Jim 21:55:56 Boris Khasanov so poor customers have to carry the burden of integration all 4 compression solutions if they don't want to have single vendor lock in. 21:58:04 Ron Bonica Or they force their vendors to implement the solution they want? 21:59:26 Tony Li And customers all want the same thing??? You end up with customers wanting all four and the vendors having to do all 4. No thank you. 22:00:59 Kireeti Kompella and can actually force their vendors to do anything meaningful? 22:01:12 Tony Li I propose that we just roll dice. 22:01:23 Daniam Henriques Boris, or the freedom to choose a solution that's optimized to their particular constraints and design philosophy. I don't feel that the proposed solutions are all created to address the exact same set of requirements, each makes their own trade-offs and some may need to be assessed as stand-alone solutions to specific requirements. 22:01:42 Boris Khasanov depends on the size of the customer and their budget to persuade a vendor 22:01:47 Kireeti Kompella @tony dice are loaded (by market cap) 22:02:14 Tony Li I mean that quite literally. 22:02:35 Kireeti Kompella as did i 22:03:10 Eduard V I do not remember any other IETF functionality that was duplicated in 4 solutions. Does anybody remember any? 22:03:53 Ron Bonica Four solutions is excessive. Maybe we can decide on a number of lanes (greater than 1) and allow one solution in each lane. 22:04:46 Martin Horneffer Maybe I'm with an operator (=customer) that is too small... but anyways: with all the options in IETF standards it already is a pain to get interoperability for any new functionality. I really don't need even more variety in new standards. 22:04:59 Bill Fenner Eduard, MANET basically declared failure after failing to pick among 4 protocols 22:05:47 Kireeti Kompella @eduard vpls bgp/vpls ldp/evpn = 3 22:05:55 all deployed, but evpn is "winning" 22:06:18 Eduard V no, EVPN is just the replacement. Hence 2. 22:06:43 Kireeti Kompella service is the same 22:06:55 Eduard V And I remember a lot of interoperability problem from these 2. 22:07:10 Boris Khasanov Kireeti, there were good old days when we just have to choose between ldp or bgp signaling :) 22:07:46 Kireeti Kompella keeps life interesting :) 22:07:47 Eduard V the last one is for sure 22:08:04 fang sheng You can detect the link fault of the directly connected neighbor to determine whether the neighbor is faulty. 22:09:46 Darren Dukes Why adopt >1? The design team was formed to inform the WG of requirements and analysis for compressing an SRv6 SID list. We have a clear collaboration with interoperable solutions around CSID, and it meets all requirements to the maximum. This isn't just my opinion. It is the unanimous consensus of the design team that spent 1 year working on this. I guess we can bring this to the list. 22:25:00 János Farkas Well, relationship with DetNet is not clear. Perhaps join the DetNet session for https://datatracker.ietf.org/meetin…ta-plane-preof-for-ip-00.pdf#page=3 22:37:57 Éric Vyncke Unsure why there is a need for a CA in this case 22:42:00 Eduard V Does it mean that SRH would be extended cross-domain? 22:42:37 Éric Vyncke In this case, a CA could become useful indeed 22:42:54 chenmeiling yes CA certificate used in the controller Éric Vyncke @Meiling: why not simply distributing the public keys per ingress node (as all is done via a controller) ? 22:51:29 About alt-mark, 3 different ways (SRH, HbH, dest options) of doing the same marking? 22:52:03 chenmeiling the range of signatures includes IPv6 Source address, SRH Last Entry, SRH Flags, SRH Segment List, AUTH TLV D, AUTH TLV Reserved, AUTH TLV Auth Key ID. 22:58:53 fang sheng If the sid list uses enc.x, can it still be swapped? end.x' chenmeiling we are not limited to ingress node, we can choose the key node to verify the signature. just key node need public key for verification.