Andy: I agree that ties are really errors, and I think the architecture document tries to say that the priority is just a way to allow the first one that wins - to stay connected. You are correct - the client must have a connect and reload strategy.
Sue From: i2rs [mailto:[email protected]] On Behalf Of Andy Bierman Sent: Tuesday, September 23, 2014 9:25 PM To: Susan Hares Cc: Jeffrey Haas; [email protected]; [email protected] Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) 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
