# IETF 109 SPRING WG Chairs: Bruno Decraene James Guichard Joel Halpern Secretary: Shuping Peng ========================================================== # Session I * Wednesday, 12:00-14:00, November 18, 2020 (ICT (UTC+7)) ## 1 SPRING Status [ 10 minutes ] Chairs No comments on the Agenda. For the egress protection, we have about 5 or 6 drafts related to this subject. It is better to align between the RTGWG and the SPRING WG. It could be an interim meeting. ## 2 Segment Routing Policy Architecture [ 15 minutes ] draft-ietf-spring-segment-routing-policy-09 Ketan Talaulikar Tarek Saad: Slide 7 please, it is about the block allocation for dynamic SR policies, we had email exchanges. In favor of a separate block of colors for those dynamically created policies by a controller. I am not sure about letting operators manage the color blocks. It will be cumbersome. Evetually it has to be learned dynamically from PCEP and other protocols. Ketan Talaulikar: Please clarify your concerns if we dont do that. Tarek Saad: For the hiarachical SR Policy just presented. Ketan Talaulikar: The operators may not use them for steering? Tarek Saad: Yes. Ketan Talaulikar: There are the cases like BSIDs that do not use colors. We look for more inputs and take it forwards. Shraddha Hedge: Composite candidate path introduces one more level of weighted ECMP. It is possible for some platforms may not support this. It would be good if we could add some text to address what should happen in this case. Ketan Talaulikar: Agree with you. This hierarchy is more from conceptual and framework perspective. Not forwarding plane as it is implementation specific. Please provide some text and discuss. Cheng Li: It is hard to understand the composite candidate path. More text would be good. Do we really need to specify that the endpoint of the composite candidate path must be identical? Ketan Talaulikar: Yes, otherwise, it will be odd to have them go to different destinations. It won't fit the hierarchy. We can discuss more in the list. Please suggest the text for clarification and then we should add. Boris Khasanov: Separate color block for non-BGP case may bring additional complexity because we will require color negotiation etc. It could be more helpful but also more complexity. Ketan Talaulikar: Opinions on both sides. We can further work it out on the mailing list. Bruno Decraene: WGLC? Ketan Talaulikar: We should wait to reach consensus on these conversions today. ## 3 An MPLS SR OAM option reducing the number of end-to-end path validations [ 5 minutes ] draft-geib-spring-oam-opt-00 Ruediger Geib Bruno Decraene: Any questions can go to the mailing list or private. ## 4 Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/Traceroute [ 10 minutes ] draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-04 Nagendra Kumar Nainar Srihari Sangli: How do you handle the anycast sid? Is there any procedure you would recommend? Nagendra Kumar Nainar: In case of anycast, we are not going to replicate. We will not be expecting multiple responses. Xiang Ji: Only one bottom FEC is needed to be validated at the far end or a stack of FECs for each segment? Nagendra Kumar Nainar: It depends on what you want to validate. If it is multiple FECs that need to be validated then you need more. If it is the bottom most in case of PING, then you just need to include the bottom most. ## 5 Seamless Segment Routing [ 10 minutes ] draft-hegde-spring-mpls-seamless-sr-03 Shraddha Hegde Ketan Talaulikar: The draft has three parts: use cases, requirements, and proposal based on BGP-CT. There are several solutions available, e.g. H-PCE. Would it be better for the WG to first look at the use cases and the requirements? Shraddha Hegde: We can look at the use cases and requirements and discuss. The proposal is different than the existing one. It is using BGP-based mechanism to interconnect multiple domains. The existing solutions are mostly using label stacking and not using BGP. This architecture is extension to the existing seamless MPLS, trying to bring the capability to create multiple colored paths end to end. Ketan Talaulikar: Use cases and requirements are all Informational. Seamless MPLS is actually informational. The WG is better to tackle the use cases and requirements to capture what is there. We should document all the solutions not just one. Shraddha Hegde: Fair point. Ketan Talaulikar: We can collaborate and discuss further offline. Boris Khasanov: More comparison with BGP-LU is needed. Currently it is just one sentence. Shraddha Hegde: Add more text to the draft. BGP-LU could give you one single best path. Here we add capability to create multiple paths. I agree to add more text. Ron Bonica: Reply to Ketan. Two distinct requirements. One is for coarse-grained TE between networks and the other is for fine-grained TE for the network that is much more tightly coupled. This draft should go forward to satisfy the first requirement. Shraddha Hegde: Very valid point. Ketan Talaulikar: Exactly my point that the WG needs to have a better understanding of these requirements. Kireeti Kompella: To ketan. If it targets as a standards draft then it needs a requirement draft. Now it targets as informational, better set out the goals and how to achieve them. Requirement draft will create overhead. Whether we should have hierarchy or not? Hierarchy has trade off, losing granularity and e2e visibility. Should be fine to document both solutions. Uma Chunduri: Read the draft, strong believe to adopt it. Support. Ketan Talaulikar: Agree with Kireeti. But the draft is standards currently. We want to present all the various solutions if it is an informational. So operators can make their choices. Still believe it would be valuable to have a separate doc to record the use cases and requirements. Ron Bonica: It is good to have a requirement document. We should not have solution document block the informational one. We had that in the past and we should not repeat that. * Chairs polling: If you have read the document, do you think that it provides a good start? - hand raised: 14 - hand explicitely not raised: 13 - read the draft (computed): 13+14=27 - total participants: 121 Bruno Decraene: We will welcome more discussions on the list. Please focus on the subject. We can discuss later whether to split the draft into two, by requirements and solutions. ## 6 Segment Routing Header encapsulation for In-situ OAM Data [ 10 minutes ] draft-ali-spring-ioam-srv6-02 Zafar Ali Greg Mirsky: It is about how to use IOAM trace option. That is only one way. In IPPM WG, there is a working group draft, direct export, does not require any information to be added to the packet. It has a number of advantages. In IPPM Monday's session, the proposed hybrid-two-step method is a combination of the IOAM trace option and direct export. It creates a follow-up packet which is out of band. Have you consider this out-of-band collection? Zafar Ali: Agree that out-of-band collection would be needed in some cases. O-bit is defined. It does not effect the in-band solution. Both have their own space. We collect the data from only the capable endpoints. Greg Mirsky: MTU is more concern for the IOAM trace option. It may reach limit. For the direct export and hybrid there is no limit. It will need corelation. There are tradeoffs. Zafar Ali: Segment list is deterministic. The MTU is also deterministic. We need the in-band solution. Ron Bonica: Agree with Greg's comments. It will work with the SRH. How will it work with the micro SID? Zafar Ali: The decision is based on the local configuration. Ron Bonica: Even though you route through micro-sid you will still look at the SRH. Zafar Ali: Yes. SRH TLV is equally applicable to micro-sid. Ron Bonica: ok Bruno: With micro-sid you don't use SL (Segment Left). Not sure how the IOAM encoding would work. We can follow up. Giuseppe Fioccola: The relationship between this draft and the IPv6 IOAM draft? It can be achieved using DOH+SRH. Zafar Ali: We can take it offline. When using HBH, you can collect hop by hop. The difference is that we collect from the endpoints. Giuseppe Fioccola: Similar discussions in 6man. You can use DOH+SRH to have the same effect. Bruno: Have you presented in 6man? Zafar Ali: Yes, have presented a few times. I leave Chairs to discuss. Bruno: Need to discuss with the 6man Chairs to coordinate. Andrew Alston: Multiple methods to do it. Would it be helpful to have a fully-defined requirement document? Zafar Ali: There are already a lot of drafts in IPPM. We only use the IPPM encoding for the SRv6 network. We can discuss offline. Xiang Ji: Is there a TLV to allow us skip some segments? Zafar Ali: TLV processing is only based on local configration on the segment endpoint. Xiang Ji: The headend control is that the headend can decide which nodes to measure. Zafar Ali: We can discuss the headend control offline. Bruno: Discuss in the mailing list both on in-band and out-band. ## 7 Point-to-Multipoint Transport Using Chain Replication in Segment Routing [ 10 minutes ] draft-shen-spring-p2mp-transport-chain-03 Yimin Shen Adrian Farrel: No forking anywhere else apart from at the source? Yimin Shen: Right Adrian Farrel: For some topology it does not work well. The Letter Y topology, normally a P2MP fork. It does not work in other topologies. Yimin Shen: Works better in ring topology and linear topology. Not in all the topologies. In general, in certain type of topology with certain constraints it works. Adrian Farrel: It makes it a useful tool rather than a global solution. Jeff Tantsura: Why don't you use the BSID? Use BSID as the Bug SID. Yimin Shen: The idea is the same. We want it to be routable. Please refer to example 1. Jeff Tantsura: Computation should be addressed in the PCE. Interested to see what type of computation you could do. Xiang Ji: Large number of destinations, how to do the TTL manipulation in a uniform mode to allow the chain do not terminate earlier? Any considerations on the label stack depth? Yimin Shen: If a large number of leaves, you will use a large number of chains. Specify the maximum hop count when you do the path calculation to limit the maximum delay, which should be derived per chain based. Bruno Decraene: There are a set of trade-offs involved. It would be good to discuss more. ## 8 Segment Routing for Redundancy Protection [ 10 minutes ] draft-geng-spring-sr-redundancy-protection-00 Fan Yang Ron Bonica: Slide 8, is it possible that SRH2 or SRH3 is longer than SRH 1. Fan Yang: Between these two nodes (Redundancy and Merging) this is a redundancy protection. Ron Bonica: So SRH may be longer when it leaves from redundancy node, right? Fan Yang: Yes, any concern? Ron Bonica: The same concern as the head delete and insertion. You might have MTU problem. Fan Yang: It is a generic problem, not in the scope. Reply to you later. Ron Bonica: You have the same problem to make the header longer. Fan Yang: I will reply to you later to understand it better and see how we can solve the problem. Cheng: That can be solved with compression, which would be another topic on Friday. Bruno Decraene: Running late. For Egess protection, there are several drafts, need coordination, we are going to have an interim meeting for it. We are going to skip the slides. ## 9 SRv6 Path Egress Protection [ 10 minutes ] draft-ietf-rtgwg-srv6-egress-protection-01 Huaimo Chen Skipped ## 10 SR-TE Path Midpoint Protection [ 10 minutes ] draft-hu-spring-segment-routing-proxy-forwarding-12 Huaimo Chen Skipped. Bruno: We'll setup a dedicated session for the subject of segment endpoint/egress failure. ## 11 YANG Data Model for SR Service Programming [ 5 minutes ] draft-jags-spring-sr-service-programming-yang-00 Jaganbabu Rajamanickam Bruno: No time to review the draft in details. It can be reviewed in the draft. No comments to the mic. Thank Huaimo for understanding. Meeting on Friday dedicated to Compression. Please read the requirement draft and have an effective discussion. * Speaker Shuffling Time/Buffer: 10 minutes * Total Presentation Time: 115 minutes ============================================================== # Session II * Friday, 14:30-15:30, November 20, 2020 (ICT (UTC+7)) ## SPRING Status Chairs The design team was created on 7th July. ## Design Team: status update and future plan Weiqiang Cheng The github for minutes and documents of the design team: https://github.com/IETF-srcomp Jim Guichard: Please be aware that there is another presentation. So please only comment on this one rather than the output. Ron Bonica: One thing to add. The current draft still don't include all the requirements. A lot of them have not been worked on yet. Do you agree, Weiqiang? Weiqiang Cheng: Yes, roughly agree. Andrew Alston: You said the design doc is done, but then said the design doc will be ready in Dec. The current doc only states the obvious. Questions to the Chair, do you believe that this DT will produce a proper design doc in a reasonable timeframe? It is already over the timeframe which was promised. Do you believe that there will ever be consensus in the DT? What is the chairs' opinion on where is the DT to go? Jim Guichard: It has not been 6 months but 4 months. It is a requirement doc not a design document. Weiqiang Cheng: Agree with Chairs. Hope to help the WG to get to the right direction about the technology. Don't know when we can get agreement in the WG. Make the plan to guide the DT to reach the target. So far the submitted draft is still an individual draft. We still need strict review, comments and modifications to reach rough consensus. I won't say we have consensus in the DT then the WG should accept our output. Andrew Alston: Zero responses from the DT to the comments submitted to the mailing list. Weiqiang Cheng: Would like the WG Chairs to give some comments. Joel Halpern: DT will be the one to take care of the comments. Please engage with people and reflect the comments in the next version. We need to move on. Ahmed Bashandy: Better to lay out the requirements and let the WG to decide. There is no consensus on what the requirements are within the DT after a long time. Existing standards should be included in the Appendix and taken into account when we choose the design. Weiqiang Cheng: Thank you. Greg Mirsky: Sent comments recently, looking forward to discussions. One general concern is that the DT was chartered to set requirements for compressed sid in IPv6 networks. From the title and the abstract, it seems that it only focus on SRv6. The charter is broader than the scopt of the current doc. Appreciate comments from Weiqiang or the Chairs. Jim Guichard: From Chairs' perspective, DT can make their own decision. If the assigned task (SR compression over IPv6) and the results don't match, then the DT needs to explain. We would like the DT to look at all the possible solutions and make those requirements. Greg Mirsky: The DT should follow the Charter. If they decide that there is something might stay out of the Charter, they need to provide good reasons based on technical discussions. Joel Halpern: Chair cannot say more at this time. Darren Dukes: To Greg, it will be answered in the next presentation. Cheng li: The DT is hardworking. If people are not happy about the progress please contribute. The title of the draft is the consensus of the DT. Joel Halpern: The scope of the doc should be coming out from the next presentation. Chongfeng Xie: SRv6 has been defined in a series of RFCs and WG drafts and deployed in operator's networks. From the point of migration, the future compression solution should be SRv6 based. It should be taken as a basic requirement. Luay Jalil: Appreciated the work. I see general requirements in the current doc. A lot of work in the past were use case driven. Per use case may be more beneficial. The consensus is the most important, and should be thought about up front. Keyur Patel: Thank to the DT, but hoping to see consensus. Please get the draft in shape. Looked at the Appendix and requirements, if there is no consensus, please be aware that we Arrcus have running code and solution based on SRv6. We like to see consensus soon. ## SR over IPv6 Compression Requirements draft-srcompdt-spring-compression-requirement-02 Weiqiang Cheng Greg Mirsky: What is marked as "full consensus"? Got a impression that the requirements are centered for the brown field scenarios. Recommend to consider the green field scenario. John Scudder: Surprised to see that the forwarding efficiency requirement listing the number of headers parsed as metric, which is wrong to me. I would rather parse three very simple headers instead of one very complicated header. Satoru Matsushima: All the requirements are good. Especially impressed by the requirements in the Appendix. As the operator who has deployed SRv6 in a while, these SRv6 based, SRv6 functional TE and heterogeneous SID-list are really important requirements to us. Please make sure these requirements to be the normative part of the requirements. Bob Hinden: Talking about the slide "SRv6 Base Coexistence". Although I read the draft, but still could not understand what does this mean " The compression solution MUST support deployment in existing (RFC8402) SRv6 networks." Please elaborate. Weiqiang Cheng: This figure is provided by Ron Bonica. Please answer, Ron. Ron Bonica: Two SR paths in the figure. One path is using SRH, and the other is using compression mechanism whatever it is. The Node 3 should support both but not in the same packet. Bob Hinden: Okay, good, thank you! That helps. Darren Dukes: Bob, we also called it the ship in the night at one point. Reminder on timeline: There is pandemic. People took vacation in the summer and design team really started in September. Design team worked very hard and long hours. It is a good start. The requirements come from operators and the people we have contacted. The design team agreed that SRv6 SID list is what needs compressing. The document considers both SRv6-based and non-SRv6 solutions. Please read past the first page of the draft. Ron Bonica: Agree with Greg. What is the charter of the DT? Compression of SR over IPv6 or compression of SRH? Should we also consider the green field? Jim: It is important that the DT identifies what needs to be compressed. If the DT decides that it is the SRH that needs to be compressed then that is what we need to focus. Figure out what needs to be compressed and work from there. Wim Henderickx: I am part of the DT. DT is working on both green and brown fields. We have not done analysis yet. Currently building requirements draft general enough to cover both fields. Different people want different things. We want to remain open at this stage. The way we want to do the analysis which we havenot discussed. For some of the requirements we want to build a set of use cases and then anaylze the solutions that are out there. To John on performance, we had consensus on how to do it. The DT has agreed that the lookup will determine the performance and efficiency of how the implementation will scale. So we keep the requirement in the doc and believe that it is valuable. Cheng Li: We include both green and brown fields. The draft is not ready yet, still a lot to do. The compression requirement comes from the overhead of the SRv6 SID. So the name of the draft is appropriate. Yet the draft does not limit the solutions to SRH-based only. Right now we focus on very general requirements. The text is fine right now. Tom Hill: I have a concern around the mix of compressed and uncompressed SIDs in the same header. It is not efficient from the forwarding plane perspective. Suggest the DT to look at all the requirements in a broad perspective instead of isolation. Make sure there is no contradictory element there. Andrew Alston: Agree with Tom. It is really efficient. Anything outside of SRv6 should be outside of the consideration? There are already other solutions with running code and being shipped. People will not stop developing. The delay here is harming the whole eco-system. Joel Halpern: Allow Weiqiang to answer. The time left is very limited. Weiqiang Cheng: Good question. The first goal is to get the right direction for the WG. There are a lot of solutions but we should give a clear suggestion to the industry which one should be adopted by the WG. The DT team will do its best but the decision should be made by the WG. Yisong Liu: As an operator, I think that the compression solution should be compatible with classic SRv6 standards, so the requirements and the compression solution should be SRv6-based. Please progress solution very fast, because CMCC needs to deploy SRv6 with compression soon. Thank the DT for their work. Martin Horneffer: The requirements listed so far are good if you are in a green field approach with a single network domain or a small number of network domains. But missing one requirement for a brown field in large multi-domain environments. To manage the SID number space, it would be much painful to do so for many network domains that you might want to consolidate in a large organization. Would like to see it to be added. Huaimo Chen: Can you explain the reason for mixing compressed and non-compressed SIDs? Jim Guichard: Take to the list. Long explaination. No time now. Ketan Talaulikar: Thank the DT. We are in the requirement stage, and approaches come later. The requirements should not look at only what have been deployed with SRv6. Building on existing standards and introducing things is how the IETF works. Joel Halpern: Continue on the list. We need to know what is the most important for the DT to consider. Encourage the DT to work towards the goal and finish within the timeline that has been laid out. Daniel Voyer: Thank the DT. Scalability is important and should be considered in the requirements. Joel Halpern: Thank you all! * Speaker Shuffling Time/Buffer: 5 minutes * Total Presentation Time: 60 minutes