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:[email protected]] Sent: Friday, June 05, 2015 8:36 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 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-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: +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
