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

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Sep 2014 17:09:13 -0400

With some help from Kent, Dean and Alia, I've put together a rough first
draft of requirements I2RS has on netmod/netconf.  It should be strongly
noted that due to a confluence of a lot of bad timing (travel, vacation,
etc.) I didn't have time to more broadly reach out and involve interested
parties.

As such, please note that this draft is not an I2RS WG draft and does not
have current WG consensus.  At best, it reflects my attempt to summarize
prior discussions and turn them into requirements.  This document will most
assuredly be wrong and be revised.

But it's primary purpose was to provide a start of the discussion of I2RS
requirements at the netmod interim meeting next week.

My abject apologies to the I2RS and netmod working groups - this was the
fastest I could get the text out.

Comments are appreciated.  Flames are not unexpected.

-- Jeff

New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : I2RS requirements for netmod/netconf
        Author          : Jeffrey Haas
        Filename        : draft-haas-i2rs-netmod-netconf-requirements-00.txt
        Pages           : 10
        Date            : 2014-09-12

Abstract:
   This document covers requests to the netmod and netconf Working
   Groups for functionality to support requirements to implement the
   I2RS architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Sep 2014 11:40:07 +0200

> etc.) I didn't have time to more broadly reach out and involve interested

[...]

> Comments are appreciated.  Flames are not unexpected.

Thanks Jeff for putting this together. Concerning section 2.1.1, I am
not sure I agree with:

   The SSH transport does not mandate authentication be done; it is an
   optional feature.

RFC 6242 says:

   The identity of the SSH server MUST be verified and authenticated by
   the SSH client according to local policy before password-based
   authentication data or any configuration or state data is sent to or
   received from the SSH server.  The identity of the SSH client MUST
   also be verified and authenticated by the SSH server according to
   local policy to ensure that the incoming SSH client request is
   legitimate before any configuration or state data is sent to or
   received from the SSH client.  Neither side should establish a
   NETCONF over SSH connection with an unknown, unexpected, or incorrect
   identity on the opposite side.

I also think that NC over TLS requires that both sides authenticate
and verify the certificates. I think as far as NETCONF is concerned,
all transports do actually mutual authentication.

Perhaps there is confusion here with RESTCONF where the current
wording may be read as authentication is optional. But then, this
is not past the IESG yet. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 16 Sep 2014 10:51:20 -0400

Juergen,

>    The SSH transport does not mandate authentication be done; it is an

And that was one of the details I missed.  As I've been doing my protocol
homework, I missed the existence of this RFC.

[...]
> is not past the IESG yet. ;-)

So, two obvious options for the document I wrote:
- Presume restconf will address this, leave it in the requirements until it
  does.
- Consider it pure noise, remove.

But I think the major concern has been addressed.  Thanks!

(And in fairness to Kent, he did think it was covered as well, but we hadn't
gotten to the level of RFC citations in our discussion prior to publishing
this draft.)

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Sep 2014 20:07:27 -0400

Jeff:

In section 2.6.1, you indicate the notification must "specify type and
various parameters for the endpoint session" - is this a new configuration
that is I2RS and empheral or is it a part of the netconf event configuration
that would need to be added?     Same question for the filters in 2.6.2? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, September 12, 2014 5:09 PM
To: [email-masked]; [email-masked]
Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs
requirements)

-- Jeff

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements
/

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Sep 2014 20:20:16 -0400

Jeff:

With I2RS datastore (empheral) and I2RS Config there is always a chance that
two different actions will change the same data.  Take the example config
you use in section 2.7 and assume that both I2rs and normal config want to
modify this bgp config in the bgp routing process.   First - do you think
this is possible?  

If you do then section 2.7's atomic transactions will need to be augmented
to indicate the interaction priority between the following different events
I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rollback).
I define interaction priority as the priority (interrupt or sequencing) when
one of these events overlaps with another. 

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, September 12, 2014 5:09 PM
To: [email-masked]; [email-masked]
Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs
requirements)

-- Jeff

 

        Author          : Jeffrey Haas

        Pages           : 10

        Date            : 2014-09-12

Abstract:

   I2RS architecture.

<https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement
s/>
https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements
/

 <http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00>
http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Jeff Haas <[email-masked]>
Date: Thu, 18 Sep 2014 07:08:52 -0400

Sue,

Such endpoint and filtering behavior, while necessary for i2rs, may be generally useful. I expect good discussion about it at today's interim session. 

Jeff

> On Sep 17, 2014, at 20:07, "Susan Hares" <[email-masked]> wrote:
> 
> Jeff:
>

---

From: Jeff Haas <[email-masked]>
Date: Thu, 18 Sep 2014 07:12:14 -0400

Sue,

My expectation for such a scenario is that for overlapping config for the same state that BGP will have its neighbor configuration in an IDR defined data model. I2rs will have separate neighbor configuration. In such a case priority is expected to arbitrate the tie breaking. 

Jeff

> On Sep 17, 2014, at 20:20, "Susan Hares" <[email-masked]> wrote:
> 
> Jeff:
>  
> With I2RS datastore (empheral) and I2RS Config there is always a chance that two different actions will change the same data.  Take the example config you use in section 2.7 and assume that both I2rs and normal config want to modify this bgp config in the bgp routing process.   First – do you think this is possible?  
>  
> If you do then section 2.7’s atomic transactions will need to be augmented to indicate the interaction priority between the following different events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rollback).   I define interaction priority as the priority (interrupt or sequencing) when one of these events overlaps with another.
>  
> Sue
>  
> Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)
>  
> With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf.  It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation,
> etc.) I didn't have time to more broadly reach out and involve interested parties.
>  
> As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus.  At best, it reflects my attempt to summarize prior discussions and turn them into requirements.  This document will most assuredly be wrong and be revised.
>  
> But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week.
>  
> My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out.
>  
> New Internet-Draft is available from the on-line Internet-Drafts directories.
>  
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Sep 2014 12:58:51 -0400

Jeff:

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? 

Config datastore ----------------routing bgp code 

                                                          |

I2rs instance/datastore ---------------

Sue 

From: Jeff Haas [mailto:[email-masked]] 
Sent: Thursday, September 18, 2014 7:12 AM
To: Susan Hares
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

Sue,

Jeff

Jeff:

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, September 12, 2014 5:09 PM
To: [email-masked]; [email-masked]
Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

-- Jeff

 

        Author          : Jeffrey Haas

        Pages           : 10

        Date            : 2014-09-12

Abstract:

   I2RS architecture.

 <https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 <http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00

i2rs mailing list

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2014 16:01:54 -0400

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.  

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Sep 2014 14:09:52 -0700

> 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.

> writeup (coming shortly), please let me know and we'll resume.

Andy

> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Sep 2014 20:59:36 -0400

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? 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: Susan Hares; [email-masked]; [email-masked]
Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod
interim and i2rs requirements)

Sue,

to me.

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

 

-- Jeff

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Sep 2014 18:24:33 -0700

On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares <[email-masked]> 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

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-masked]]
> *Sent:* Monday, September 22, 2014 5:10 PM
> *To:* Jeffrey Haas
> *Cc:* Susan Hares; [email-masked]; [email-masked]
> *Subject:* Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was
> netmod interim and i2rs requirements)
>
>
>
>
>
>
>
>   #3) if both writer and current owner have the same priority, then
> current owner wins
>
>
>
> (e.g. what will break for client B if client A causes 2 of its 7 entries
> to be deleted?)
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Sep 2014 18:04:58 -0400

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-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, September 23, 2014 9:25 PM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; [email-masked]
Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod
interim and i2rs requirements)

Andy: 

 

Sure.

 

Sue 

Andy

 

Sue,

to me.

 

-- Jeff

Andy