Minutes for I2RS at interim-2014-i2rs-1
minutes-interim-2014-i2rs-1-2

I2RS interim meeting December 11, 2014.  Chairs Sue Hares, Jeffrey Haas.
10:00-11:00 ET

Attendees:
Jeff, Sue, Alia
Amit Dass
Dhruv Dhoty
Hariharan Anathakakrishnan
Igneous Bagdonas
Lixing Wang
Juergen Schoenwaelder
Alexander Clemm
Cary FitzGerald
Dean Bogdanovich
Don Fedyk
Yael Frank
Zafar Ali

Status
=======
RIB model looking for design team members.  Currently, Amit and Lixing.

Use case summary
==============
Dean: The main issue with the protocol selection was does I2rs want to talk
directly to daemons or via configuration? Do we want to focus on managing
primitives such as routes, interfaces, etc. or do we want to manage more
complex objects such as VPNs (l3vpn, l2vpn, etc.) If we can figure out what we
want to do, it will make selecting protocol behaviors a bit easier. Maybe even
outside of the IETF since there already exist some solutions. What do we want
to enable through the agent?  E.g. Apache Thrift is an interesting protocol if
we are dealing with primitives.

Sue: Use cases have both.  E.g. virtual topology.  Can these be done with just
primitives? One option is we can take a protocol selection that works for just
the primitives, but we know that BGP is something that people want to do and
BGP cannot be solved with just primitives.

[slide Virtual topology cases]
25 reqs. that are in-charter.

[slide Discussion questions]
Is it okay to just use primitives or do we need complex objects?
Dean: If we do not want to support bgp vpns, only need primitives.
Ignas: One of the important thing is transactions.  If we have both, there is a
lot of flexibility. If transactions are not in protocol level but are in client
agent interaction or some other entity, then we have to worry about
deterministic issues. Jeff: Speed may require two distinct mechanisms. Ignas:
Speed? Possible. Depends on use case. Maybe makes sense. Alia: In architecture,
we do not have the idea of transactions.  You may have multiple operations in
single exchange with agent.  Trying to add transaction complexity will rat-hole
us. The concept of going to two mechanisms if the more complex use cases sounds
much better than trying to push more complexity into the simpler use cases.
Jeff: Getting state out of the system is also important. Dean: This might push
us into duplicating cases already elsewhere?  If you can already do complex
stuff via configuration - e.g. l3vpn - many components, each particular daemon
has work to do. If we can do it using primitives as well, but exposing those
interfaces adds complexity. Know from two vendors that we have different
approaches; this would lead to vendor specific issues. Sue: Your suggestion is
we go through config process for everything or complex? Dean: Primitives should
go through daemons - [it is] faster. But then you limit flexibility. Complex
always should go through config; already a solved problem.  What is open? Do we
want to have two different ways to do this? Jeff: Simple, complex, issues may
have protocol impacts.  See discussion about netconf vs. restconf. Sue: Dean,
you know about this in thrift? Dean: Yes, have done some implementation. Sue:
We should split this into simple or complex.  Next week, let discuss having the
protocol split-up between complex and simple. Dean: I’ve already done that
split up, can send to list. Sue: Want to focus on protocol independent items
and topology.  Alexander, could you do the analysis on your topology items?
Alexander: Ok I can present that. Jeff: IETF session broke things down into
interactions with config state vs. i2rs injected state. This discussion
clarified we need to further break this down to simple vs. complex.

Rib Info Models…
[slides]

Nitin and Sriganesh are in Asia and don’t think they can present. They’ll talk
info model next week.

RIB yang model
[technical issues with Amit and Lixing presenting…]
Jeff: How to do the multiple encaps.  Is this a good idea?
Amit: Good idea, best idea to date?
Jeff: Overlap with rtg-cfg?
Amit: Not yet.
Hari: I did some of this.  Collaborating with Lada.  Will work with Amit. 
There is some confusion about who is the derived model of whom. Dean: Many
discussions about rtg-cfg model. When we started modeling other protocols such
as ospf, we realized we could not do that work yet due to inconsistencies in
rtg-cfg.  IMO, should be used as base for all rtg-cfg models. Jeff: Motivation
for asking is overlap with regard to complex config vs. primitives. Hari:
Should be complementing? Sue: For next week, figure out how this relates to
rtg-cfg. Amit will come back with that information to the next interim. Sue:
let’s talk about this on list. Can you drive it Dean, Amit, Lixing? Alex, for
your model? Jeff: Juergen general recursion for 1.1, 2.0? Juergen: 1.1, no. 2.0
no clue. Jeff: Raise on netmod mailing list? Juergen: yes. Jeff: Will raise on
netmod.

EOF.