[Idr] Minutes from the idr meeting

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

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