SPRING WG - Source Packet Routing in Networking Tuesday, March 28, 2017 13:00-14:30 Tuesday Afternoon session I Room: Grand Ballroom 3 ====================================================== Chairs: Bruno Decraene Martin Vigoureux Minutes taker: Jonathan Hardwick o WG status http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=75 Martin sr-conflict: an editorial revision needed. Then going for last call. Bruno: I've been involved in the discussion so will recurse. Discussion on recharter vs sleep vs close the WG: Stephane Litkowski(Orange): Very few deployments; no real operational feedback. There may be things to change in future. So closing now may be too early. Stefano Previdi(Cisco): Too soon to close. Maybe the SR-TE policy and SRv6 network programming drafts fit within the current charter? Alvaro Retana(AD): Don't close. Either recharter or sleep. At minimum stay open until at least co-requisite protocol extensions get published. Jeff Tantsura: MPLS is done but v6 is still to come. Feedback from v6 should come into the group. Closing is definitely too early. Acee Lindem(Cisco): Even without recharter, a few documents are still coming in e.g. conflict resolution document. There are also additional use case documents. So there is plenty of work without rechartering. Martin: Agree, we do need to process that document before. Uma Chunduri(Huawei): definitely not closing. o Implementing non protected paths using SPRING draft-litkowski-spring-non-protected-paths-01 Stephane Litkowski, 7 minutes, 13:15 Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=770 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1280 Julien Meuric (Orange): Side comment as PCE chair; support this document as it addresses interoperability issues that we may face in deployment. No change required in PCEP session initiation (which does not imply anything about its relevance). Jeff Tantsura: Valid use case, needs to be done. We need to support PCEP session on demand, so need BGP auto-discovery of PCE. Stephane: For BGP, some implementations already support authorization of a range of valid addresses. So no configuration needed. Alvaro (Cisco): What is the goal of the draft? Is this a mandatory to implement option? Stephane: If you want to implement this use case you have to do it this way. Alvaro: So not mandatory to implement. Stephane: No. Alvaro: Should it be a STD track document? Stephane: I don't know. Martin: Who has read the document? About 10-15 persons. o Segment Routing Policy for Traffic Engineering draft-filsfils-spring-segment-routing-policy-00 Stephane Litkowski, 7 minutes, 13:22 Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1485 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1995 Jeff Tantsura: Configuration is still very imperative (CLI-driven). Decouple the value of the binding SID from the action/meaning. The action should be driven by the business logic, not hand-coded by CLI. Acee Lindem: Document is only 20 pages, not 45! This document really puts SR-TE and IDR into perspective, it's a good companion. We should discuss on IDR list. Stefano Previdi: We removed SR policy from IDR draft and left only BGP mechanics. We had a BGP-LS draft (LSP distribution) that we could re-use for this with a simple extension. o SRv6 Network Programming draft-filsfils-spring-srv6-network-programming-00 Kamran Raza, 20 minutes, 13:29 Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=2220 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=3204 Chair: Who has read this document? (More than 20 people) Prem Jonnalagadda (Barefoot): We have an implementation of this draft - just wanted to make that comment. o Separating Routing Planes using Segment Routing draft-gulkohegde-routing-planes-using-sr-00 Shraddha Hegde, 10 minutes, 13:49 Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=3310 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=4475 Greg Mirsky: When does the 50ms failover timer start? From when falilure is detected? (Yes) Normally in IPFRR it is understood that you have to precompute - with a central PCE you will have to precompute for all possible failures. Your proposal is reactive. If instead you propose FRR then describe it explicitly. Scaling characteristics are different. Shraddha: I am not proposing anything new about FRR itself. Your comment seems disconnected from the actual proposal here. Greg: FRR is local computation. You are talking about central computation. Shraddha: No, I'm not talking about central computation. Greg: So it's computed only on nodes affected by the failure? OK. If you put PCE in the picture it confuses. Jeff Tantsura: It looks operationally as complex as multi-topology. Shraddha: You don't ave to maintain separate routing tables or configure MT information. Jeff: Complexity from operations - troubleshooting. Jeff: Comment 2 - Look into conflict resolution daft and also mapping server. Shraddah: sr-conflict is within algorithm (and not across) so should not be a problem. Martin Hoeffner (DT): I don't agree PCE needed for end-to-end solution with Anycast. Could be done without any controller. Martin: What is the overlap in use cases between this draft and Stephane's non-protected path? The use case I have in mind would be the same for both. Shraddah: good comment. Stefano: Acknowledge Multi Topology does not work well. Stefano: There are easy ways to achieve FRR within 1 plane without changing the architecture or extending the protocol. This proposal goes way beyond what is needed. But I agree with the requirement. Shraddah: It would be possible to tweak the TI-LFA algorithm to stay in one plane but it requires a lot of configuration. Stefano: I don't think it does require a lot of configuration. Tony P. (Juniper): Having invented Multi-Topology, Stefano, you may have to hire better implementers. Speaker Shuffling Time 5 minutes Total 64 minutes 14:04