Subject: [Netconf] Fwd: I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 23 Sep 2014 09:54:16 +0200

Copied (by me) from netmod mailing list.

I believe that NACM issues belong in our NETCONF WG.
So we should all be aware of this.

I also suggest we discuss this on THIS NETCONF mailinglist and not on netmod.
(or am I missing something)?

Bert

-------- Forwarded Message --------
Subject: 	Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)
Date: 	Mon, 22 Sep 2014 14:09:52 -0700
From: 	Andy Bierman <[email-masked]>
To: 	Jeffrey Haas <[email-masked]>
CC: 	[email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Susan Hares <[email-masked]>

On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
     https://www.ietf.org/mailman/listinfo/netmod