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