I2RS 16 November 2016 Wednesday 15:20-16:20 11/16/2016 KST)
Scribes (Russ White, Susan Hares)
Agenda Bashing
Agreed to move ops state to the first item in the agenda
Agreed to add on two new topics if there is time, including timing
Revised Agenda is:
• Chair’s slides [15:20-15:25] (Sue Hares, Russ White)
• OPSTATE + Ephemeral State (Sue Hares, Huawei)
Group Discussion
• Data Center Fabric Models (Yan Zhuang, Hauwei)
• FB-RIB Data Model - implementation report (Susan Hares, Huawei)
• Timing operations in I2RS (Tal Mizrahi, Marvell)
Chairs' Slides
May want to separate models into simple and complete to make things easier to implement
Discussing opstate model and how it applies to ephemeral
Kent: on first slide, in the intended box, s/co/ro/
Questions slide:
Dean B: What type of validations do you have in mind
Sue: May do some validation off line and less on
Dean B: So how do you do hardware based validation
<more discussion>
Sue: we need to get use cases to cover this (reduced validation)
Dean B: how does the multiple control pane sources of information combined
Sue: This is just what is being allowed in the new draft
Joel H: Let's make progress on what we've been defined before revisiting past decisions
Dean: How will multiple "panes of glass" be merged
Joel: We have a requirements draft that spells this out
Does the individual draft (which???) step on the work of other WGs
Sue: Individual contribution is separate from asking what the WG should do next
Kent: resolution occurs to the side (outside of) the data stores
Yan presenting Data Center Fabric
Jeff T: Do you plan to describe complexity within the server/within the host
You might have a host with a virtual switch within it
How do you represent notifications?
Yan: The endpoint has two connection points, physical and logical layer
Jeff T: Do you envision a chain of notifications
??: In this model there is the concept of abstract nodes. The abstract node can represent a layer. What is the difference between the layers?
Yan: Each layer represents a different "fabric"
Room: It is exactly the same
Sue presenting filter based rib model from hackathon
Dan B: ACL drafts designed as match/action sets
Sue: That's a portion of this, events were ... ??
Dan B:
Sue: Should these be consumed under the same model, or set off the side as a separate thing
Right now it goes through filter based RIB->ECA->packet matching
Two different options
Dan B: No opinion at the moment
Sue: Next step is to implement using IP Tables
Timing operations in I2RS (Tal Mizrahi, Marvell)
Dan B: How will the controller know the load, and or the amount of time it will take to install
You will get inconsistent updates
Tal: How do we know the device will perform the update at precisely the time required
Move to slide about silicon support
Dan B: This is only at the hardware
Joel: This assumes hardware support
Much bigger problem -- spent a lot of time debating this problem
Combining this with I2RS injects a lot of complexity
Would like to finish current work before doing this kind of work
Tal: There is software, and there is silicon
Software installs update ahead of time, silicon performs the action
Dan B: What can happen in one second can change what you want to do, making the event installed in the silicon obsolete
Tal: Software can cancel
These are implementation questions we need to address, but it is possible
Yufon: About the mechanism
Presented scheduling draft in netmod
May want to check to see if this satisfies this kind of thing
Several different use cases
Scheduling is similar
Already a mechanism for the rpc scheduling, can use that