Routing Area Working Group (rtgwg) Minutes - IETF 82 (Taipei) scribe: John Scudder timestamps are approximate (I find these useful for referring to the audio archive if needed) I haven't attempted to capture anything covered in the slides. rtgwg minutes 1:03 meeting begins 1:05 charter update Main goal: clarify that FRR related work belongs in RTGWG. (Although other work is still welcome!) 1:07 No comments on charter. Ready to go! 1:09 Composite Link, Ning So presenting 1:10 Requesting WG adoption for framework draft (authors will send request to mailing list). 1:11 Maximally Redundant Trees, Alia Atlas presenting Local SRLGs not covered in doc, know how to do it, will update doc. 1:14 Re-architecting network to maximize LFA coverage is NP-hard... 1:25 Summarizing 1:26 how many people have read? (quite a few) 1:27 Wes George: support it becoming a WG draft. Wim Hendrickx: good way to get 100% coverage. Suggest extending number of tunneling options to include (for example) VLANs. Generally very good and support as WG draft. Thomas Clausen: see draft-cardenas-dff-03, relates to this one. Complementary to this one. Is it appropriate for this WG? Chairs: please send reference! Ice Wijnands: I suggest putting the mcast stuff into a separate draft. Alvaro: poll for show of hands supporting adoption? (many hands) 1:31 John Scudder: There is an IPR filing against this draft with RAND terms; this makes me uncomfortable. I hope it will be brought to the attention of the list before any decision is taken. 1:32 MRT Algorithm, Gabor Enyedi presenting 1:52 Dimitri Papadimitriou: Regarding evaluation, will you have an estimation for communication costs when doing route selection? How does this work in a distributed setting? Alia: IGP capability, advertise priority for being GADAG root, everyone in island does same, elects GADAG root. Similar to IGP LAN DR election. Dimitri: Would be nice to document (something). Alia: I anticipate we'll expand that section. 1:54 Jeff Tantsura: We are working with our lawyer to solve all the IPR issues. Speaking about the algorithm, it looks intimidating but it's really elegant and beautiful. Dave Ward: Is there IPR to be filed on this one? Jeff: There will be Ericcson/Juniper IPR, still being worked out. Dave: So there is IPR yet to be disclosed? Alia: Yes, as soon as possible. 1:56 Dave Ward: Why are these Informational? Alia: We need to straighten that out. Algo should probably be Standards Track. Dave: Does the architecture allow for different algorithms to be used? Alia: Signaling should allow for algorithm IDs to be advertised. Kind of like with crypto algorithms. Dave: Please add that to the draft! 1:57 Stewart Bryant: Sounds like encapsulation mechanisms and algorithm should be completely separate. Also not sure that source/dest reroute pairings is the best. Repair to destination, repair to midpoint, repair around failure, not sure what's best. 1:58 Alia: We did break out algo into different doc. Ice, Yiqun and I will break out mcast separately too. Assuming we will do different ones for IS-IS and OSPF. Not sure we need something that describes forwarding alternatives in lots more detail since there are existing drafts/RFCs on multitopology forwarding. 1:59 Stewart: I do think we want to end up in one solution but it might be better partitioned first so we can think of bits individually. You're presenting a package, I have a nagging feeling we need to decompose the package a little more. 2:00 Alia: I did provide a survey at the beginning. When you talk about a forwarding mechanism you have to talk about which of the classes of solutions you're trying to address. We can take this off line and work on resolving this. Stewart: To emphasize, this is engineering input, not speaking as AD. 2:01 Alia: Destination, NNH? Stewart: Or Q-space. Alia: MRT can do NNH but then you get into tunneling. I expect to report back at next IETF. Alia: Also please send topologies! Stewart: Tradeoff is how many failures can you tolerate? Alia: Until you've partitioned your network. Stewart: How many concurrent? Alia: As long as you haven't partitioned. Stewart: No, I mean temporally concurrent. Double-fault. Alia: Draft doesn't talk about local SRLGs. Gabor and I have discussed them and understand how to deal with them. General ones are an open issue. This is generally trying to solve single faults. Stewart: SRLGs are often not known a priori, so you have to attempt to cope with unknown ones. Alia: At least MRT doesn't cause looping in the undetected SRLG case. This is better than LFA. Stewart: Agreed it's better, not known if it's optimum. Alia: Would be interested in knowing the criteria for evaluation you propose. Complexity level is a problem with notvia. Stewart: We need to discuss complexity at greater length. 2:06 IP Fast-Reroute with Fast Notification, András Császár presenting 2:29 Hannes Gredler: You have done a nice performance optimization exercise, congratulations. I could not do that in my environment realistically. The number of other jobs competing for resources would preclude tuning the system to get to 180 usec latence. Andras: Yes, you would need to have support on the line card and the host. Hannes: It's worse than that, we have multiple layer distributed systems with lots of latencies. Optimizing each piece of the path is a pointless exercise. Local repair provides good bang for the buck. Requiring top-down optimization to get from 50 ms down to 20 ms is just not an interesting exercise. Andras: Yes, but... Hannes: We already have local repair with 100% coverage. So the problem is already solved. Andras: There isn't really fielded 100% local repair solution. I don't want to speak against MRT but... Hannes: The other child (MRT) is nicer looking and less spoiled. Hannes: Optimization usually has a huge tail of hidden cost. 2:32 Stewart: We got similar input when we were designing FRR systems. The performance is dominated by FIB update time; in very high end routers FIB update complexity is severe, particular in distributed platforms. Andras: Exactly, that's why we pre-download backup next hops. Stewart: I don't see how you can do that. You have to have in your line card the result of the decision for any failure in the network. Andras: I tried to explain that; you need backup next hops for every unique impacting failure. In our scenario it worked out to 3.4MB. Stewart: Can someone explain that 9000 number and tell me if it is reasonable? (referring to slide 8) Stewart: What's your definition of a prefix group? (multiple conversations) 2:36 Stewart: This all hinges on whether your assumptions are correct. Gabor: I don't think this is just an optimization. (Missed) A protection technique must not be local; this is a protection technique. Andras: And we have tried to prove that it is feasible. 2:37 Eric Osborne: You assumed 1 ms delay per link. Andras: Yes except we varied one of the link delays. I was trying to show that packet loss occurs only on node directly adjacent to failure. Eric: Two other questions. To the 9000 prefix groups, makes sense from PE towards ABRs. From ABRs toward PE I don't see how it can work. Eric: Comparing this to MRT, clearly both are not necessary. What's up with the fact that the authors have produced two mutually exclusive solutions? Do we need both? Andras: Great question. Is the WG going to do multiple solutions? 2:41 Alia: (missed) ... This technique is not independent of the number of prefixes being protected. It's linear in the number of prefixes. Andras: It's different from flipping a bit but still fast. 2:43 Ilya Varlashkin: You did some experiments with very short BFD timers. Can you factor out BFD time and say how much you're winning? 2:44 Stewart: When you revise this draft can you please cover the labeled/MPLS case too? (multi-way conversation after mic cutoff missed) Alia: With regard to question about multiple solutions, our goal as a WG is fewer not more. 2:47 Protection Mechanisms for LDP P2MP/MP2MP Label Switched Paths, Quintin Zhao presenting 2:58 No questions/comments