Minutes for IDR at interim-2014-idr-1
||Minutes for IDR at interim-2014-idr-1
John Scudder (IDR co-chair)
Susan Hares (IDR co-chair)
Alia Atlas (Routing AD)
Alvaro Retana (cisco)
Jeff Haas (Juniper)
jie dong (Huawei)
Rob Shakir (BT)
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
13:03 Rob Shakir mentions that his draft and Keyur although they have had
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
Sue discussed add-path progress, forthcoming adoption calls, forthcoming
etc. See the details on the IDR status slides (
Alvaro presenting add-path
Promises this is the last last add-path presentation ever
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!
Sue: Jie, you might want to mention China Unicom's requirements
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?
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
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.
Sue: Anything else?