[Idr] Minutes and proceedings from Interim on 12/16/2014 at 13:00-14:00 ET

["Susan Hares" <[e-mail]>]

Minutes for the IDR interim (below and attached). Slides can be found at: 

 

http://www.ietf.org/proceedings/interim/2014/12/16/idr/proceedings.html

 

Please send any corrections to the list. 

 

Sue Hares 

 

 

---------------------

 

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!