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:j.schoenwael...@jacobs-university.de]
Sent: Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: i2rs@ietf.org; jh...@pfrc.org; 'Joel M. Halpern'; i2rs-cha...@ietf.org;
'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-inter
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
