Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

["Susan Hares" <[e-mail]>]

Juergen:

<chair hat on> 
The agreement with the NETCONF WG chairs was to bring requirements to
NETCONF.  The I2RS  is working to bring a full-set of requirements for I2RS
protocol based on 

draft-ietf-i2rs-traceability-03 (WG LC) 
draft-haas-i2rs-ephemeral-state-reqs-00 (WG Adoption)
draft-ietf-i2rs-pub-sub-requirements-02 (WG LC) 
and mutual-authentication/transport text from
draft-haas-i2rs-netmod-netconf-requirements-01 (draft forthcoming).   

This work is based on technology proposed by authors of traceability,
pub-sub, and Jeff's co-workers on ephemeral state (Juniper).   While
draft-haas-i2rs-ephemeral-state-req-00 is not 100% complete, it has gotten a
lot of discussion and has the form of a proposal.  

I2RS is taking choice (a) below  - to state its requirements to the
NETCONF/NETMOD group and to evaluate the solutions they propose.   Based on
feedback from members of the NETCONF WG, the I2RS WG is trying to a best
effort in specifying its requirements including the I2RS ideas of solutions
so that we may transmit as much information to NETCONF/NETMOD as possible.
We are not adopting choice b or c at this time.  Choice (a) does not
constrain I2RS to accept the solution NETCONF/NETMOD proposes, but says the
I2RS will review the resulting technology from NETCONF/NETMOD based on the
I2RS requirements.  

If you feel the overlay model discussed at the NETMOD interim is a viable
candidate, I suggest you write a draft outlining the details for I2RS WG.
If you publish draft, I will put you on the agenda on 6/10/2015 for the WG
to consider before we close on the ephemeral state.  As you know from being
a WG chair, the floor is open now for the overlay alternative but the
adoption call of Jeff's draft (draft-haas-i2rs-ephemeral-state-reqs-00)
signals a direction that the WG will take. 
<chair hat off> 

It would please me personally if you had time to published a draft with
details for the overlay model published in a draft prior to 6/9/2015 so we
can consider overlay model concepts.   Perhaps you can chat with Kent Watsen
about creating the draft together.  
 
Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: Friday, June 05, 2015 8:36 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]; 'Joel M. Halpern'; [e-mail];
'Alia Atlas'
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote:
> Juergen: 
> 
> I understand your technical point on being concerned about
> 
> "solutions that require (i) separate data models for ephemeral state 
> and
> (ii) data model specific merge logic. While this may work for I2RS, 
> this approach does not scale or has a very high cost of scaling to 
> other ephemeral state editing needs."
> 
> If you have full overlay model proposal, we would be glad to receive it.
> However, no one else has proposed a full overlay model.

Frankly, there is no full alternate proposal either. The overlay model has
been discussed at quite some detail at a NETMOD interim. I am happy to point
at the meeting minutes. The question perhaps really is whether (a) I2RS has
requirements to be addresses and NETMOD/NETCONF looks at solutions or
whether (b) I2RS casts a solution into stone to be run through the NETCONF
working group or whether (c) creates a solution on its own independently of
any other NETMOD/NETCONF requirements.

> Other answers are below.
> 
> Sue
> 
> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[e-mail]]
> Sent: Thursday, June 04, 2015 2:24 AM
> To: Susan Hares
> Cc: [e-mail]; [e-mail]; 'Joel M. Halpern'; 
> [e-mail]; 'Alia Atlas'
> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)
> 
> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote:
> > The minutes for the I2RS meeting are at: 
> > 
> >  
> > 
> > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-int
> > er
> > im-201
> > 5-i2rs-8
> > 
> >  
> > 
> > These minute provide a lengthy of issues in the requirements.  From 
> > these minutes, there are the following 6 conclusions on the protocol 
> > requirements that Jeff stated:
> > 
> >  
> > 
> > 1)      There will be no consideration of an overlay model unless a
fully
> > formed proposal is presented. 
> > 
> > Jeff and I appreciate Ken Watsen's comments on the list, but we have 
> > had lots of suggestions regarding an overlay proposal - but no full 
> > proposal.  At this time, the WG will only consider full proposals 
> > and not suggestions toward a proposal.
> 
> For the record: I am highly concerned about solutions that require (i) 
> separate data models for ephemeral state and (ii) data model specific 
> merge logic. While this may work for I2RS, this approach does not 
> scale or has a very high cost of scaling to other ephemeral state editing
needs.
>  
> > 2)      Jeff's document provides details on ephemeral state requirements
> > that have not changed.  These requirements include:
> > 
> > a.       Highly reliable notifications (but not perfectly reliable
> > notifications)
> > 
> > b.      High bandwidth, asynchronous interface, with real-time
guarantees
> on
> > getting data,
> > 
> > c.       Node identification of clients that write by client identity,
> > secondary identity, and priority.  Data models will determine what 
> > is the "node" unit.  For example, the I2RS RIB node unit is the route.
> 
> I am concerned about adding protocol mechanisms that are specific to a 
> certain data model. It is unclear what a "node" unit it, terms like 
> 'highly reliable notifications' and 'high bandwidth, asynchronous 
> interface, with real-time guarantees' are somewhat unclear - how do we 
> determine we have met any of these requirements?

Apparently no answer here...

> > d.      There is one priority per client. 
> > 
> > e.      Priority is kept in the NACM at the client level [rather than
path
> > level (5/27 meeting) or group level (list discussion).  
> 
> Why does this mapping of username to priority have to be maintained in
NACM?

Apparently no answer here...

> > 3)      Joel suggests that large data write may be best done in netconf
> with
> > guarantees
> > 
> > a.       I2RS will be focused on highly asynchronous interfaces with
less
> > than full routing tables. 
> > 
> > b.      A client whose large data is interrupted by a notification has a
> > difficult time determine when the notification happened in the 
> > stream
> > - so the I2RS client must ask the agent again.
> > 
> > c.       Logging for traceability is different than event notification. 
> 
> Except c), I do not understand this. What are these 'guarantees' 3) is 
> about?
> 
> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may 
> receive a change notification for one of the routes while the rest of 
> the stream is in progress. If the change notification does not include 
> the data, the  I2RS client must poll the I2RS agent to determine if 
> the route change notification occurred before or after that route's data
was sent.
> Change notifications are reliable, but not perfectly reliable.  
> Logging is different than change notifications as logging for tracing 
> includes all change data reliably.

I am still confused what the requirement here is.

> > 5)      Secondary identity data is read-only meta-data that is stored in
> the
> > agent associated with a data model node that is being created or 
> > updated  (write-access) in the data store.
> 
> Ehem, what is read-only data that is created or written? Did you want 
> to say that the identity meta-data is immutable once a data node has been
created?
> And if so, has priority the same property: Is priority of a data node 
> is determined at creation time and then immutable?
> 
> [sue]: Secondary identity data is read-only meta-data that is only 
> changed when created or written. It is immutable unless the whole node is
changed.
> Priority is linked to I2RS client.  Priority remains unchanged with 
> the identity of the client.

You can't ever change the priority of a client? I doubt this is practical.

> Priority of an entry (route1 from client-1, priority2) remains 
> immutable with the writing of this entry from this client.  If a new 
> client (route-1 from client-2, pririty3), then the node and the 
> meta-data changes.

So I understand the priority is determined at write time but then sticking
until the next write. Or in other words, to change the priority I have to
write the data again using a client with a different priority (or using the
same client in case priority of a client turns out to be configurable).

> > 6)      I2RS Client and Agent Identities are mutually authenticated by
> > Authentication server (AAA),
> > 
> > The values of identities are originally set by operators.   
> >
> I am not sure how agent identity authentication via AAA works. Can 
> someone point me to the right direction if I assume a secure transport 
> such as SSH or TLS?
> 
> The identities used in SSH are passed via AAA (diameter or radius).  
> The identities are not standardized but sent in AAA (diameter or 
> radius) messages based on operator assignment.

I know how I can pass the client identity via AAA using SSH, I like to see
an explanation how that is supposed to work for server identities (and which
operational problem that solves).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>