Attendees: John Scudder (IDR co-chair) Susan Hares (IDR co-chair) Alia Atlas (Routing AD) Alvaro Retana (cisco) Ignas Bagdonas Jeff Haas (Juniper) jie dong (Huawei) Nikos leontsinis Rob Shakir (BT) Robert Raszuk Adam Simpson Anees Shaikh (Google) IDR Interim meeting notes December 16, 2014 Scribe: John Scudder Previously schedule Flow Specification (Weiguo Hao) and Yang presentation (by Keyur Patel) will be deferred until the next interim. 13:00 Start the Meeting and Walk through the Agenda Flow specification and BGP Yang document (by Keyur Patel) are deferred 13:03 Rob Shakir mentions that his draft and Keyur although they have had discussing, are not expected to be merged or aligned. New model forthcoming. Sue: Will you be able to attend the next interim? Rob: Someone from Openconfig will attend. Sue: I'm glad we delayed the presentations 13:05 Sue discussed add-path progress, forthcoming adoption calls, forthcoming interims, etc. See the details on the IDR status slides ( 13:07 Alvaro presenting add-path Promises this is the last last add-path presentation ever 1:13 Nikos: I want to be able to use this with both Juniper and Cisco. How can we find out how many paths are supported for each platform? Vendor doc, or...? Alvaro: You mean mode or something else? Nikos: How many paths can I advertise into IBGP? Alvaro: That wouldn't be in the implementation report. Some implementations report N-path, but N is going to be implementation-dependent. Jeff (in IM): Nikos is asking if "send path count" could be added to the report. I think that's reasonable. Jeff (voice): I do agree that in some circumstances there MIGHT be restrictions on N, but in most cases many implementors ought to be able to provide a value for N. Alvaro: I'll check with those who provided data. Jeff: Something like "number of paths you can send and any limitations associated with that." Sue: Did that answer the question? Nikos: This doesn't help me in any way without a specific value for N. 1:18 Rob: This is implementation-specific, I don't think it's for the WG. Not a best-practices document. Sue: Agree 1:22 John: doesn't guidelines doc cover scaling? if not, it's an opportunity to add or propose a new draft. Adam: It does, but only in general. Providing specific numbers is never going to be realistic. Sue: Adam, can you say any more about guidelines? 1:23 Adam: -07 out with feedback from Jeff. Been stable for a long time. Talks about different path selection modes, there's value in having vendors report on their supported modes. Whether we put that in Alvaro's implementation report or a different one is up for discussion, but we should get those answers. Once that's done, we should advance guidelines doc too. Alvaro: There may be other things from the guidelines we need to poll for too? Adam: Modes is the main one. Could include constraints, as Jeff suggested -- for example, is there a limit on N for N-paths? Alvaro: Will do. Adam: I'll help. 1:25 Sue: Sounds like we're ready to advance the base specification for add-path and guidelines? Jeff: Agree. Esp. since dangling ref for EBGP has been cleaned up, and guidelines too. Sue: I have the AI to send notes to folks at RIPE, NANOG to generate guidelines, best practices. Or Nikos can directly propose. Sue: Anything else on add-paths? ...crickets (silence)... on to Hierarchical RR! 1:27 Sue: Jie, you might want to mention China Unicom's requirements 1:28 Jie presenting on Hierarchical RR RT-Constrain Two candidate solutions: most-disjoint route advertisement, or add-path Post-WG adoption we can continue to explore the solution space. Cina Unicom has one level for MBH and a second for aggregation of traffic. China Unicom case demonstrates that this problem could manifest in the real world and thus we should work on fixing it before a problem arises. Sue: Operators have opinion regarding preferred solution? [silence] Jie: No clear preference. Jeff: I may have suggested add-path earlier. I think we may have discussed whether diverse-path is a special case of best-external? If that, then most people have code for that already, and would not require you to turn on add-path. So good operational reasons to avoid add-path solution. 1:36 Sue: Any input from operators? ...crickets... Sue: It is going toward adoption, we think the problem statement is reasonable, if you don't think it is worth IDR please provide feedback. 1:37 Sue: Moving on to Yang models. Had expected a new draft, don't have one yet. Welcome any discussion on BGP model for service provider. Rob, Anees? Or we can delay until you have next rev out. Anees: We've addressed feedback on next rev of model, will also update draft. Almost ready. Sue: Next interim is in January 12, would you provide an update at that time? Anees: Someone from the group will do it, yes. Rob: As soon as we have published an update we will tell the list so that we can have concrete discussion items for the interim. 1:41 Sue: Anything else? ...crickets... Adjourned!