IDR 1/26/2015 Meeting  10:00am - 11:30am (1.5 hours)  
 Agenda:  
1) agenda Bashing (Sue Hares) - 5 minutes 

2) OpenConfig BGP Yang Data Model (Anees Shaikh)- 25 minutes 
3) Update on draft-zhdankin-netmod-bgp-cfg - 10 minutes  
4) Discussion of Two Yang Data Model - 20 minutes    

Documents or code to read for the meeting: 
https://github.com/YangModels/yang/tree/master/experimental/openconfig 

http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 

Slides posted at:

Attendees:
    
John Scudder
Benoit Claise
Anees Shaikh
Helen ___?___
Ignas Bagdonas
Jay Borkenhagen
Jeff Tantsura
Jeff Haas
Jie Dong
Jonathan Sadler
Mach Chen
Matthew Myatt
Rob Shakir
Robert Raszuk
Vincent (Shunwan Zhuang)
Vivienne Wang
Sue Hares
Dean Bogdanovic
Rüdiger Volk
"Call-in User_6" (morrowc)
"Call-in User_8" (?)
"Call-in User_9" (?)
Alia Atlas
Warren Kumari

10:10 Meeting Starts

10:10 Anees (and Rob) speaking on OpenConfig

(see slides) 

10:22 Contrast to draft-zhdankin
- Policy generalized from various implementations, "bgp is not that useful without policy"
- Op State ditto. "Actual content of the stats is fairly common across implementations". Layout is up for debate.

Draft to be updated "soon", prior to next IETF certainly.

10:27 Q/A

Jeff: OpState, many things will be common across vendors. Use of optional features in Yang permits vendors to have partially supported operational state? How much forward-looking in model should we be looking to, i.e. identify gaps that may exist in implementations and document them in model? 
A: (missed some) Re forward-looking, currently focusing on actual configurations. Can update model in future as required.
R: Haven't reached that state yet but ops folks will have asks, so when we get to that point will add if there is demand.

10:32

Sue: Lots of to-dos around L2VPN.
R: We don't use it so no strong opinions. Waiting for L2VPN ops to contribute.
A: Agree. 

10:35

Benoit: How does the routing policy draft fit with the ACL yang module in netmod?
A: Some commonality around pfx match, but mostly routing policy is routes and their attributes, ACL is packet attributes. "We view them as complementary." Should share similar structure, need to discuss with Dean.
Dean: I hadn't been aware of the policy model until this call -- can't comment on this call. As Anees said we were focused on packet, wanted to create general structure for match+action. For route filters, trying to see if we can apply our approach, but haven't looked at all routing attributes, just pfx.
R: We'll look at how you defined pfx and we can go from there.
D: Ranges seemed most straightforward cross-vendor. Comparisons are not so portable if complex.
A: Considered several implementations. Basic inequalities seem to be widely supported. Our main goal is not to support EVERY implementation, but rather the major implementations the participating operators are using. We've just defined equality and a couple of inequalities anyway.
Benoit: And btw, there are policies in QoS, security, next to routing and ACL. We need to think about the structure upfront.
Jeff: Some of the BGP NLRI are structured, e.g. L3VPN includes a RD. Thought about what to do with policy for structured NLRI?
R: Existing policy languages abstract that away from the user. Yang needs to be different?
J: We've had pressure to add some of this; future-facing. Example: we've been asked to add matching on RD. Actually think some vendor already does supply that primitive. 
A: I think policy model we have would accommodate that in terms of adding those as additional match options, although since we are focusing on common denominator we might not add that. Actually I think we have RDs in the model now so defining a match against it would be OK.
R: Actually we have RT but not RD. Agreed we may need to augment it to include other useful stuff.
J: This work is going at higher velocity than Z model; policy that talks about prefixes but not about prefixes that share multiple properties -- NLRI that are composite values.
R: We don't handle non-IP NLRI well at all, e.g. EVPN. Work to be done there. Prefer to publish early and iterate. Input from implementors would be useful.
J: To summarize: "Have you thought  about it... Not yet."
R: Yes.
Dean: Your models very modular & extensible. Is your goal to lay out basics and then let other experts extend according to your designs/guidelines? Or will you do the extensions?
A: We're open to others doing extensions. We want to put enough into the model that it will be operationally useful stand-alone. Vendor extensions through augmentation. 
D: Would be useful to add examples of how to add through augmentation, and guidelines too.
A: We haven't articulated guidelines in writing yet. Good suggestion. One example is policy/BGP. 
R: Agree.

10:49

Sue: When will we see an update? 
A: Github regularly, maybe early Feb. Version now published reflects what we presented today. Draft should be published by mid-Feb. Still working through Op State.
Sue: 
    1. Need OpState input
    2. Need L2VPN input
    3. Provide examples/guidelines

R: Once we have a strawman we'll publish it, but yes.
S: Want feedback on routing policy? Or still working on consensus in your group?
R: All feedback on all published work is very welcome.
Dean: There is some work already in QoS to reuse the ACL structure and see how it fits
R: Quite a bit of feedback has already been provided.
S: Please send a note to IDR list when Github is updated.

10:53 meeting ends