SPRING WG - Source Packet Routing in Networking Thursday, November 17, 2016 9:30-11:00 Thursday Morning session I Room: Grand Ballroom 3 ====================================================== WG Chairs status Chairs, 15 min http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=0 Serious issue in responsiveness of authors to IPR polls Chairs stress the importance of authors' and wg's engagement with regards to challenging objective which is being set: pack of 4 documents to IESG within 1 month, 2nd pack of 4 before next meeting. Chris: any update on architecture document? What is expected in v10? Stefano: under review between authors, integrates strict spf comments, should be submitted next week. Chris: Does it include the SRLB additions to the IGP drafts. Stefano: no, no impact on architecture. Chris: thanks for clarification o Segment Routing Conflict Resolution draft-ietf-spring-conflict-resolution-02 Les, 15 min Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=622 currently draft has chosen the path of ignore overlap only. introduces implementation complexity and potential interop issues. competing goals: maximize traffic delivery Vs keep conflict resolution policy simple Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=1640 [?]: if order not followed then interop issues? Les: yes [?]: but you don't control the receive order Les: true but transient [?]: keep it simple is important, for debugging also. Shraddha: shouldn?t we also have a protocol preference? and that it be most important. Les: this is explicitly stated in the draft. Forwarding plane is agnostic to the protocol. Thus intentionally not included. Shraddha: if conflicting entries between ISIS and OSPF, protocol preference should be used. Shraddha: let's discuss on the list George: if there is a conflict something is broken. whatever allows to find what is broken is goodness Robin: problem would not exist with global label. also vendors do not use SRGB. This mainly a config issue, we should not spend that much time on this. Jessy?: some other scenario of conflict exist (same prefix with same SID, anycast SID) Les: covered in draft Jessy?: other scenario, different IGPs, different domains, ... How to resolve the associated conflicts. Les: on protocols, covered in the draft; On domain, we are not trying to resolve conflicts across domains. Robin: could have other issues with other protocols. policy will become even more complex. we don't want that. Wim: operators should speak-up. Stefano: just want to emphasize what Wim just said. John (Google): not interested in this solution Would like the simple one. St?phane (Orange): yes, but errors can happen so we want to maximize traffic delivery Jeff: SR deployments exist. go talk to operators. o YANG Data Model for Segment Routing draft-ietf-spring-sr-yang-05 St?phane, 15 min Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=2410 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=2730 Robin: My ideas are not represented in this yang model St?phane: document reflects the WG consensus. We need to focus on stable elements. Could be enhanced in the future. Chair: I second that o SPRING non protected paths draft-litkowski-spring-non-protected-paths-00 St?phane, 15 min Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=2914 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=3354 Jeff: destination based forwarding isn't it? Stephane: from service or transport PoV? Jeff: transport St?phane: a customer may indeed want a protected path, another a non-protected path, ... Jeff: that an overload of semantics Acee: 3 SIDs with different attributes. not an issue. Jeff: not really different from FRR over optical restoration. Only need to make sure that upper layer kicks-in before re optimization under layer St?phane: yes, but we don't know the timers. Jeff: I mean scope is wide. It's a valid problem worth working on. Chris: with node-SID solution, it's going to converge with IGP. Is that a problem? St?phane: regular convergence is acceptable. automatic is needed. Acee: 2nd solution is best. St?phane: which flavour? Acee: with an additional flag on Node SID Acee: worth working on Jeff: with IGP reconvergence you might end up back on shortest path. Shraddha: protection is not really important for customers. St?phane: yes here. This is similar to optical transport service. Shraddha: If you use Node-Sid it can change. St?phane: True Robin: what is application scenario? St?phane: SR-TE Robin: Which status are you targeting? St?phane: Standard Track o Segment Routing Recursive Information draft-filsfils-spring-sr-recursing-info-03 Stefano, 15 min Presentation: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=3900 Discussion: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_SPRING&chapter=chapter_1&t=4200 Robin: we have proposed the same two years ago. Did you read my draft? Stefano: no I did not read it Robin: also I proposed this on the list. Stefano: if that is the case and we are in agreement then we merge the drafts Dave Allan: PHP could not be used, is that correct? Stefano: no, you can still use PHP, you know the significance of that local label. Robin: I hope you will read the mailing list of the SPRING WG to remind your memory Stefano: send to me your ideas and not assume I will dig into the archives two to three years back [?]: useful cases for that, but could be achieved with IS-IS SID and Labeled BGP sessions between local node and target node, ... Stefano: this draft follows a requirement expressed in IGP WGs, but I agree there are plenty other ways to solve this [?]: some discussion on this would be useful