Source Packet Routing in Networking (SPRING) WG Tuesday, April 5, 2016 14:00-16:00 Tuesday Afternoon session I Room: Buen Ayre C Chairs: John Scudder Bruno Decraene o Administrativia 15 minutes - actual start 2:03 pm local http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=220 Chairs - Note Well - Scribe - Blue Sheets - Document Status John Scudder> Note well Problem statement received a number of comments from IESG, hoping to resolve by end of week. Arch doc, completed WGLC, making some changes proactively based on feedback from IESG on problem statement, if changes are large, we may do another WGLC. OAM use case - authors have asked for it to be last called, will do this week. Two more use case docs, working on trying to move them forward due to IESG request to get reqs to them before the architecture document. No Q&A. o SR drafts update 20 minutes - actual start 2:08 pm local http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=525 https://www.ietf.org/proceedings/95/slides/slides-95-spring-0.pdf Stefano Previdi SP> Problem statement draft close to resolving all comments, large number detailed on slide 2. Removed some text on comparison between RSVP and SR, clarified a number of sections and put pointer to IPv6 SR draft. Moved a number of requirements from SHOULD to MUST and added some text that SR is referring to the label stack. On next slide, a number of comments received that we have not addressed in the draft - explanations on the slide. First item out of scope for draft, other document (resiliency draft). Don't plan on changing terminology from SPRING to SR. On the TE use case draft, we had a draft, WG should let us know if we should resurrect TE use case description as it's expired. Most comments received are addressed in the actual implementation drafts so it's not felt to add value to the problem-statement draft. One comment on problem statement draft is whether or not we need a draft for something that is in architecture, implemented by multiple vendors and deployed. Since a lot of work was put into these drafts, authors would like to continue to advance them however. Next slide has 3 other use case drafts which we are waiting for problem statement to go first, they describe various other use cases. On architecture drafts - still addressing some comments on segment-routing draft as John Scudder mentioned (from IESG), and working through comments on IPv6 and MPLS dataplane as well. Two other documents are pending for WG evaluation. There was little feedback on the draft-filsfills-spring-sr-recursive-info draft, please comment. large scale interconnect has update but missed IETF cut-off window. o Segment Routing Conflict Resolution 20 minutes - actual start 2:19 pm local http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=1170 https://www.ietf.org/proceedings/95/slides/slides-95-spring-1.pdf draft-ginsberg-spring-conflict-resolution-01 Les Ginsberg Les Ginsberg> version 00 presented last IETF, have not done update but had discussions on list, will be soon. Goal is to address conflicts since SR identifiers are global in scope. Two issues that draft addresses: First - when multiple SRGB ranges overlap advertised by sendor, agreement has been reached on list email (not currently in draft). If overlapping ranges, ignore all SRGB from that node. Second issue - prefix SID conflict advertised by multiple nodes, conflicts could occur. Two options thought of, ignore all advertisements that are conflicting or apply some preference rule for which to use. Draft is currently agnostic. Ignore is easy to diagnose but impacts all destinations. Preference rule may allow traffic forwarding but may be hard to diagnose and may not be noticed right away. Slide 8 reviews terminology to discuss these options further. Two kinds of conflict - prefix conflict (two prefixes same SID), or SID conflict (SID has been mapped to multiple prefixes). Preifx conflict is intra topology/VRF. SID conflict is inter-topology/VRF. If preference rule implemented not based on source of advertisement, only content of advertisement. All routers must have consistent database and conflict resolution only applies to actually advertised (vs configured) information. Preference rule proposal (not current in draft -00) - smaller range wins, biases choice towards prefix advertisements (typically /32 or /128) vs SRMS advertisements. However if you are doing LDP interop via SRMS mapping, you may have case during migration where a non-SR node has config added for advertising SID's and may still want to use SRMS mapping vs locally configured (possibly incorrect) information. So, if you detect a conflict, what does the implementation do - 3 choices are outlined: 1. Quarentine - last entry that has conflict (the one bad entry) is excluded from use. 2. Overlap only - break entries up to avoid the conflict and only exclude the conflicting ranges after fragmenting. 2. Ignore - ignore all conflicting entries. Q&A: started 2:34 pm local http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=2030 Acee> If you quarantine or ignore entries, would you bring them back if the entries change and the conflict disapear. LG> Yes. Anytime the entries change, the policy is re-applied. Alvaro Retina> - why IPv4 over IPv6 in 2nd rule? LG> Don't care. We'll follow consensus. Alvaro Retina> In general, that's the direction. Jeff Tansura> would be good to hear from SP's on whether we should use this preference rule? We should get some concensus on this ASAP due to implementations deployed already. Certain implementations already doing types of selection. John> Is your point is that we need to hurry up. Jeff Tansura> Yes, if possible. Uma Chunduri (Ericsson)> Why do we have to compare mapping server prefixes with other SID prefixes? These two are different. Some implementation may not support mapping server. LG> Even if doesn't have mapping server, if you have a deployment rule has to identify preference for this. Wim Henderickx (Nokia)> We believe Quarentine is our prefered option: simple implementation and some benefits that we are trying to achieve. Bruno Decraene (Orange, as WG contributor)> Question on slide 7 - why do you say it's easier to diagnose preference rule versus ignore, either way notification can go to SP about conflict (from implementation). LG> We don't have to agree on this, but we have to agree on preference policy. BD> But why do you say this? LG> Because the traffic if ignored will all be dropped, so will be noticed sooner. BD> So you mean it's easier to detect. Then I disagree we have to drop all this traffic to do detection, most operators will catch it even if you drop some of the endpoints traffic. JT> We are listening, which is why we proposed the overlap only implementation (fragmenting the ranges). LG> Yes, we want to agree on the preference rule and the policy to apply. - in my opinion, we should use quarentine which minimizes some of the damage and is easier to implement vs the overlap only which is complex. Shraddha Hegde - Juniper Networks> I agree with putting smaller range at top, on the policy side, i think overlap gives maximum advantage to operators, I think that should be the preferred one. Acee Lindem - Cisco> I agree with Les that Quarentine is simpler, this is an error case, we shouldn't have a lot of complexity in the solution. John Hardwick - Metaswith > I highly prefer quarantine. BD> Improved compared to -00. Better to give preference to prefix SID. With quarentine you can still blackhole a lot of PE, but at least it's the LDP/non-SR ones, and this set should reduce as SR gets deployed. But I need to read draft carefully, this is the right direction. JS> Bruno - question for you - in BGP we took simple approach for 20 years but the error cases were not as exceptional as we thought they were so we had to do more complex error handling. What do we think about (rarity) of this case? BD> I think for anything that can be done as an operator CLI error, this will likely happen at some point, it will not be that exceptional. I need read/think more about the draft. LG> This is not an implementation specification on how to store the active or excluded entries in overlap case, this doesn't specify that. Acee> I think this is very different from BGP error handling or redistribution errors. In this case mapping servers are in same domain, and unlike redistribution SID are explicitly configured, not dynamically created based on state. This would only happen with two mapping servers configured differently in the same admin domain. JS> Nothing could go wrong (sarcasm). BD> Errors can happen, like in migration cases. They can happen for a number of reasons (operator or implementation). JT> We will incorporate errors into the Yang model and notifications if found. SH>> Different SID coming for same prefix, one coming from SRMS and one prefix SID example. SRMS wil typically advertise a range covering both SR capable and LDP/SR non capable nodes. With Quarantine, a single error on a prefix SID will exclude the whole SRMS range. LG> For any rule we can make, it will not always make optimal decision for some example of misconfiguration. Stewart Bryant (Meetecho chat)>could you get the problem under a failover condition between two config servers? If so the you might needlessly take out a large slice of the network while you resolve this. I agree with the need for robustness LG> We are asking for adoption when we release -01 which includes the various options presented today, we just want to take it on as WG even if we don't have concensus yet on which options to choose, expect -01 in next week. Chris Bowers> In -01, present the possibilities but make it clear that it's not yet decided but up to the WG to decide. LG> Point taken. o A Framework for Computed Multicast applied to MPLS based Segment Routing https://www.ietf.org/proceedings/95/slides/slides-95-spring-2.pdf http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=3540 draft-allan-spring-mpls-multicast-framework-00 15 minutes - actual start 2:59 pm local David Allan David> This draft is about multicast over MPLS SR, may be able to work for IPv6 SR but have not investigated. Describes how we can make multicast trees that are explicit or loose, and able to use SR dataplane to implement. This draft requires all nodes can make same decisions about multicast trees by putting this information in the IGP. If we combine this with unicast tunneling approach, there are benefits. For instance since we are putting in IGP, topology change is only messaging required. Large state reduction, 30% of bandwidth savings in most deployments, re-use existing MPLS dataplane. Since using tunnels, don't need to do full computation. Tree generation in this appraoch is a bit complicated. To be ECMP friendly we need to make sure no duplicate packets are sent, by creating a minimum cost trees. We need a unique solution per S,G tree. Tree pruning - two types of prunes - if we fully resolve tree are known to produce minimum cost tree, this will sort out 97% of leaves. Second type is described as best guesses for those that weren't resolved with first approach, with good guesses only a small set will need a fix to tunnel to a neighboring node. This is computationally intensive but advantage is less state. This approach has less state sync between control and data plane however. Next slide has graph with proof of concept code results. Run on laptop, resolves 1.2M endpoints/sec in a thousand node network. So far have described making minimum cost trees, to do a strict tree, we just concatonat loose trees, we do this as a strict or loose tree can be strictly loop free, but a hybrid tree can't guarentee this. However by having unique SID per tree, and describing the cross points / way points with that SID, we can specify the tree as a unique item in IGP. This is -00, future drafts for IGP extensions and interworking with existing mechanisms, goal is standard track. Q&A http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=3540 Greg / Cisco - what is the problem trying to be solved by this? DA> this creates minimum cost trees with minimum messaging. Greg> The challenge is the flow state itself, just minimizing doesn't get rid of it. I'm wondering if are really looking at the fundamental issues with multicast rather just moving the problem into SPRING. DA> I had this approach from SPB, and Spring has some advantages over SPB. Greg> I'm not sure about the 30% bandwidth savings either, I think we should try to get rid of the requirement of messaging in multicast. DA> Are you referring to BIER? Greg> Yes. DA> My understanding is the bandwidth savings requires entropy and level lookups. Greg> Replication is the challenge, there are implementations that can do the lookups for BIER. DA> I think the most optimum approach is minimum cost, least hops. Greg> Use a subdomain. DA> I tried prototyping BIER, it adds a lot of complexity to dataplane, compared to control plane, technology trends aren't friendly to dataplane changes. Greg> I don't doubt your experience, but talking to silicon vendors, they don't want more state, so they think BIER is a net advantage. Chris Juniper> More on how this works, for a loose tree, you would just go into tree with single label, for a combined tree you would use a stack? DA> No, I have waypoints where I cross connect the labels, I can't put a 2D thing into a 1D label. Chris> add more details on this in draft. o Packet-Optical Integration in Segment Routing 20 minutes - actual start 03:17 pm local https://www.ietf.org/proceedings/95/slides/slides-95-spring-3.pdf http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=7116 draft-anand-spring-poi-sr-00 Sanjoy Bardhan Sanjoy> Goal to expose optical elements into the IGP. Use existing IGPs and scale for metro and DC edge scenarios. Next slide, A/B/E/F packet, D/E are packet/optical gateways, they will advertise different optical paths they have available with specific characteristics. Packet optical gateway announces itself to IGP domain, and announces transport segments as opaque transport segments. POG map label on packet side to right forwarding action optically. Changes will be required for segment-routing-extensions (IS-IS) draft as well as changes for OSPF/BGP-LS, and PCEP-LS to communicate this new information. Packet header slide - an opaque sub type could be signalling an L0 or L1. For segment routing extensions added a flag to say node could perform packet optical gateway function. Q&A - 3:26 pm local http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=7620 Daniele Ceccarelli (Ericsson)> Are the optical paths pre-provisioned or dynamic? SB> There is GMPLS in core DC> Are these paths pre-provisioned or can I provision through this mechanism new paths? SB> Pre-provisoned. Acee> What information would the PCE use of this new information, not clear. SB> Bandwidth/latency/protection vs restoration/other optical nature characteristics. Acee> Not defined in draft today. SB> Outside scope of draft, but potentially. Wim Henderickx (Nokia)> There is binding TLV in SR, could you use that framework as start for this? SB> We could take a look at that. Stefano> We tried this recently with last attempt L2 bundles in IS-IS draft. I think this is a good idea to get more information about L3 adjacencies. I think this makes sense, but you should look at what is already being done in various IGP working groups. JT> I think binding TLV is the right approach for this requirement. Igor Huawei> In TLS(TEAS?) working group we have idea of not permitted link. This is not a novel solution. SB> These are not IP links, the goal is to adv. Just want to bring this discussion into using SR solution space. Acee> Today you are using GMPLS. Igor> The optical path you have to consider whether you can actually use this path as an IP link, it has to have that capability. Stefano> You only want to give the optical characteritics of the IP links in the topology. We can already advertise multiple Adjency SID for an IP link. SB> Yes. Stefano> Seems you need multi-adjacency SID for each optical path under the IP link. SB> The main thing we want to avoid is increasing the number of links in the topology. Richee?> In PCE, we have inter-layer model for connecting optical layer, we should talk about existing similar ideas. SB> Yes, after this discussion, we need to start discussion. Richee> Better to use PCEP implementations for sharing this information between layers. SB> Optical link characteristics need to be gotten by PCE. Richee> We have PCEP for that. Rajiv Asati Cisco> I'm scratching head on putting this information into routing domain, isn't main reason to get this information to PCE. SB> Yes, main reason, other reason is that adjancency is not a standard IGP adjancency so not part of path calc. Headend can look at domain ID's that are part of segment list and make decisions (out of scope of draft). Rajiv> Controller can tell headend already this information. SB> This is the policy part of it, for future use. o Node Protection for SR-TE Paths 10 minutes - actual start at 3:40 pm local https://www.ietf.org/proceedings/95/slides/slides-95-spring-4.pdf http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=8460 draft-hegde-spring-node-protection-for-sr-te-paths-00 Shraddha Hegde Shraddha> Since midpoints don't maint state, you don't know which LSPs are traversing the midpoint. With RSVP, you have this information so you know the nexthop node (NHN). Point of local repair (PLR) needs to find the next node in label stack. When you build explicit paths using node SID's, if one of the nodes in that path goes down, without looking at next label in stack it's not possible to figure out where to forward traffic. SR must look at next label to forward to, diagram shows explicit path to R5 by using one extra label to send traffic through R8. If SRGB is different on R8, R7 needs to forward packet that has 3005 1008 on stack, needs to understand 3005 using node R8 SRGB. If you build context tables for all neighbors to understand each nodes SRGB + index to get label understanding. However SPF needs to be done individually for those neighbors so that understanding of forwarding decision is known as well. So to build this context table, R7 builds context table for all prefixes that would forward to R8 to be able to provide FRR protection. For Adj-SID's the method for building the context table is similiar but includes all Adj-SID's advertised by the protected node. For Binding SID's, if R2 advertises a binding SID to R4 (could be RSVP-TE or some other technology), R1 would have to look into context table of R2 and do corresponding actions. o Tunnel Segment in Segment Routing 10 minutes - actual start at 03:53 local https://www.ietf.org/proceedings/95/slides/slides-95-spring-5.pdf http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SPRING&chapter=chapter_1&t=9285 draft-li-spring-tunnel-segment-01 Xia Chen Xia> Due to lack of time, I will go right to comparison between tunnel segment and binding segment. Many types of segment types in architecture. Two scenarios in architecture, mapping server or tunnel headend binding segments. This draft has another type, tunnel segment. This has 3 use cases, reduce SR stack size, span non-SR domains, or support multiple services. Can be RSVP-TE tunnel, SR-TE tunnel or IP tunnel, first two types can have primary/secondary paths. Comparison slide - tunnel segment can carry more information than LSP segment. LSP segment has to readvertise if the paths change for the RSVP-TE LSP, tunnel segment is stable, does not need re-advertisement. It also carries further info of tunnel identifier and tunnel attributes. Require extensions to IGP to carry additional information of tunnel segment, next slide shows all related drafts required to fully support tunnel segment in all protocols. Meeting closed - 4:01 pm local