On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares <[email protected]> wrote:
> Andy: > > > > The concept on priority and FCFS is "if a remote client talks to an agent > at a priority - then it should not be knocked out by another remote client > coming later at the same priority". In my mind this is different that the > boot/reboot configuration case. Do you think I am correct? > > > Sure. I guess I am assuming each I2RS client has some reconnect-and-reload strategy. Normally, the clients will get notified when some data gets bumped or the agent restarts. Then there may be a race between the 2+ clients with same priority. IMO ties are really errors, and the operator is going to need to assign different priorities or set some config so all the clients run without data collisions. Sue > > > Andy > *From:* Andy Bierman [mailto:[email protected]] > *Sent:* Monday, September 22, 2014 5:10 PM > *To:* Jeffrey Haas > *Cc:* Susan Hares; [email protected]; [email protected] > *Subject:* Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was > netmod interim and i2rs requirements) > > > > > > > > On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <[email protected]> wrote: > > Sue, > > On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > > Where does the priority live ??? in I2RS or in config module or in BGP > > routing model? How does this work with the three datastore proposals: 1) > > separate empheral data store, 2) configuration state in existing > datastore > > tagged by model as empheral, and 3) whole data stores tagged empheral, > > config, or both. Is the routing code that sets the priority and handles > > the rollback? > > Priority received quite a bit of discussion during the netmod interim. The > reason why it was not explicitly spelled out in my first version of the > draft is that the implementation would vary considerably depending on which > answer netmod guided us toward for how we get ephemeral state. > > > > The rationale for the priority-based "first one wins" access control model > is still unclear > > to me. > > > > A simple NACM extension to add group priority has already been proposed, > > which seems fine to me. So is this how it works? > > > > #1) NACM data rules can be used to grant or deny access to specific I2RS > data nodes. > > Steps #2 and #3 assume access is granted here > > > > #2) the I2RS agent maintains the owner and owner priority of the data > somehow. > > The priority is configured in each NACM group for enforcement > purposes. > > This data used to decide if existing data can be overwritten by a > different client. > > (I think highest priority wins if target data already exists) > > > > #3) if both writer and current owner have the same priority, then > current owner wins > > > > Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. > It seems to be based on > > the order that the networking devices will boot. Can somebody explain why > it is better? > > > > I am still unclear how the operator know the exact data each client > > will want to use, and how they determine the meaningful overlap > > (e.g. what will break for client B if client A causes 2 of its 7 entries > to be deleted?) > > > > This information seems to be required in order to configure the > tie-breaking priorities properly, > > but I think the intent is that the operator will just know what I2RS > clients are installed > > and know how to prioritize them, just based on their purpose. > > > > > > > > It turned out they gave us a fourth option. I'll be summarizing that in my > meeting minutes. If you don't believe I've adequately addressed it in that > writeup (coming shortly), please let me know and we'll resume. > > -- Jeff > > > > > > Andy > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
