SPRING WG - Source Packet Routing in Networking Friday, March 23, 2018 11:50-13:20 Friday Afternoon session I Room: Viscount ====================================================== Chairs Bruno Decraene Rob Shakir o Administrativia Chairs - Document Status 6 minutes 11:50 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=30 o SPRING re-chartering discussion Chairs 14 minutes 11:56 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=276 Items for rechartering: * No disagreement that we should have OAM and SR policy items working on. * Zafar Ali: This WG should work on Service chaining. On the agenda today. * Jim Guichard: Integration of service chaining in NSH and SPRING * Zafar Ali: Agreed. But service chaing with SR should be done in the SPRING WG because segment routing expertise is here. * Linda Dunbar: SD-WAN integration with SR should be worked on. It'd be interested in working in this domain. * Martin V (Individual): Understood from Jim that Service Chaining - SR interworking should be done. Jim: yes. No preference on where the work should be done. * John Leddy: I'm interested in both Service chaining and joint path selection- SPRING should work on this (rather than breaking the work in two different WG.) * Zafar Ali: +1 SD-WAN work * Jie Dong: Virtualisation and partitioning of network ressources - draft related to this item. * Ketan: Ingress replication is extension of the policy work. Need to analyze the use case and work on it in spring. * Zafar: DMM work should be reviewed here * Uma: Mobility management should be in DMM, since this work should be agnostic to the dataplane. Only SRv6 work should be reviewed here Some protocol work in spring (to avoid some coordination issue) * Zafar Ali: Likes the approach of taking the protoocl work here in a cohesive fashion, and other WGs should review. Faciliate the process and accelerate the work. * Jeff Tantasura: Protocol extensions should be done in protocol working group. Architectural documents here. Good co-ordination will solve the problem. * Acee Lindem: (as co-chair of LSR) Would be a mistake to take this into SPRING. Coupled with the core protocol machinery. SPRING has had only 1 RFCs. * Jim Guichard: Stifles innovation if there is one WG, SFC has had this experience. Protocol work should be done in protocol WGs. * Stefane Litowski: Having protocol extensions in SPRING allows use-case synchronisation across different approaches. IS-IS/OSPF merge gives better sync. Only remaining work is BGP-LS. * : Why does this overlap with BIER? * Rob: It doesn't overlap, it's about the model of working accross the routing area. * Alvaro: I am not the responsible AD. There still needs to be some co-ordination. Problem that goes beyond SPRING - we need to better figure this out. Doesn't mean authors presenting across all WGs. * Jeff T: TEAS is not taking work on. Rather SR work needs to work with underlying approach. * Chris Bowers: Would lean towards opt 2 (some protocol work in SPRING). Delay was useful for cleaning up the architecture work. Bringing the work together is something that would have benefited iteration. Flex Algo would have benefited. * Zafar Ali: Bringing all SR responsibility to SPRING, WG/chairs get responsibility for SR. * Wim Hendrickx: SPRING should be the architectural work. SR-TE policy has elements across multiple WGs - should be done here, and something that should be done. * Zafar Ali: Agree SR-TE belonfs in SPRING. o Segment Routing with MPLS data plane draft-ietf-spring-segment-routing-mpls-12 Ahmed Bashandy 15 minutes 12:10 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=1588 * Alvaro (as routing AD): What do you want me to do with this information? Draft has been revised and is now double the size. Draft was returned to the working group. Now this work is part of the WG again - resolve comments, but have fundamentally different document. WG has to go through last call, and has to review. * Ahmed: Purpose of this presentation is an update on this version. * Chris Bowers: Have done 3 IPR declarations, will you do more? * Ahmed: Yes, if required. * Chris B: We're not in a position to be able to evaluate this right now. * Alvaro: Going to be blunt, originally thought the draft said nothing. Everything that the draft says is said somewhere else. IPR question -- this one has IPR against it, when the architecture does not. Question was whether this is the right place to file the IPR? Maybe it was on something that has already been addressed. * Greg Mirsky: Are you suggesting to create another FEC on top of the LSP ping ones? * Ahmed: Not sure what FECs this refers to. * Greg M: LSP ping does this. * Kamran Raza: Does not define any new form of FEC. * Rob: Call for WG review, we need to stabilise this and publish. o Segment Routing Policy for Traffic Engineering draft-filsfils-spring-segment-routing-policy-05 Ketan 10 minutes 12:25 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=2317 * Robin (Huawei): Routing area discussion of policy - ends up complex. For SR policy, not only the steering policy, but has concerns about the scope. There is another draft relating to BFD relating to policy. There are other drafts in this area. * Ketan: Notion of a stack of labels in SR, but how does the node know what that means? Trying to define the notion of policies, and what this means. BFD is covered in other docs. * Zafar Ali: This document is a baseline. * Rob: We need to understand what the set of documents that we would like are. * Bruno: Policy is a wide term, you can scope it at the start of the doc. o Segment Routing for Service Chaining draft-xuclad-spring-sr-service-chaining Francois 10 minutes 12:35 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=2892 * Greg Mirsky: Characterised as stateless. Do you expect to program the whole service chain from the head-end? Are you sure that this will scale, NSH idea means that the SFF forwards based on the chain ID. * Francois: The head-end will applies all of them, if the next-hop cannot be resolved, then on-demand next-hop can be used (defined in SR policy). * Greg: How/where are the classifiers? * Francois: Just at the head-end. * Ahmed: Expect that this approach is more scalable, because there is nothing in the core. * Jim Guichard: Clarification of the proxy function. Clarification - proxy function has an interface/subinterface per segment path? * Francois: Yes, this is the current requirement - but may extend this in the future. * Jim Guichard: Do you take care of multiple instances hanging off the same port of a SF - some of the diagrams are too simplistic. If have large scale, then there are scalability concerns. Integrating this work with NSH using the path ID would mean that this scalability concern could be addressed. * Francois: If you use the approach in the draft with a proxy, then there may be scalability concerns with this. Only applies with a proxy, otherwise can just be specified from the head-end where the head-end specifies an instance. * Jim: Spent 4 years for the NSH, and we're asking for another one here. In 4 years then there will be another one, can we re-use things. * : If there is something that re-classifies and modifies the header then classification may break. * Francois: Depends on the proxy o SRv6 YANG: Base/Static draft-raza-spring-srv6-yang-01 Kamran 5 minutes 12:45 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=3663 o OAM in SRv6 Networks draft-ali-spring-srv6-oam-00 Zafar Ali 5 minutes 12:50 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=3955 Sam Aldrin: Can you do MTU? Is there a case whereby there is a non-SR network? Zafar: Scope is non-SR, will take MTU offline. o BFD in SR Networks using MPLS draft-mirsky-spring-bfd Greg Mirsky 5 minutes 12:55 https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4280 Sam Aldrin: Is anycast SID in scope for this? If so, please document it. o BFD for SR Policies draft-ali-spring-bfd-sr-policy-00 Zafar Ali 5 minutes 13:00 https://www.youtube.com/watch?v=x6LjdKSwZj8&feature=youtu.be&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4500 Greg Mirsky: Traffic engineered SR means that there is no guarantee of the reverse path. Tried to bring a draft discussion of the suitability for bi-dir SR paths - S-BGP is not suited well to bidir. Zafar: We should discuss offline. o Segment Routing for Enhanced VPN Service draft-dong-spring-sr-for-enhanced-vpn-00 Jie 10 minutes 13:05 https://www.youtube.com/watch?v=x6LjdKSwZj8&feature=youtu.be&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4810 Jeff Tantsura: Clarification question - same as rtgwg. When talking about resource reservation - the controller is doing the resource reservation, not in SR? Jie: Has to be done in the control plane and the data plane, Jeff T: Please add some clarification. Jie: Each SID in the diagram has a portion of the resource - have to allocate each. Isolated in both control and data plane. Bruno: Jeff's point is that this should be in the PCE - can we clarify this, nothing for SPRING here is? Ketan: There are a few points of clarification that are not in the draft. Currently, reservations are not clear as to what SPRING should review. Jie: Will add more details in next version. Zafar Ali: We should talk offline, these problems can be solved in other ways. Discuss on the list. Robin: Clarification, resource reservation refers to admission control in the PCE, but no actual bandwidth guarantee in the data plane. There is also a requirement here for bandwidth reservation in the forwarding plane. RSVP-TE can do resource reservation, but it is not explained how to do data plane reservation today. Speaker Shuffling Time 5 minutes 13:15 Total 90 minutes 13:20