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:[email protected]] > Sent: Thursday, June 04, 2015 2:24 AM > To: Susan Hares > Cc: [email protected]; [email protected]; 'Joel M. Halpern'; [email protected]; > '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 -- 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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
