Andy:
2a and 2b: · This is just a highly reliable requirement as we talked about in the interim. It is not perfect, but highly reliable. · No specific changes are being suggested to RFC 5277, but setting this requirement will cause the NETCONF group to consider changes need to be made or can be made. Implementations must be fast and highly reliable for the normal I2RS data. We expect the NETCONF group to provide some details on what “fast and highly reliable” means for their protocols. In the past FORCES proponents gave those numbers. · Joel mentioned that large RIB pulls were not the normal I2RS data. I will ask the working group the larger question – Do we need to specify “fast and highly reliable” in terms of response time or packets per second? Sue -----Original Message----- From: Andy Bierman [mailto:[email protected]] Sent: Wednesday, June 03, 2015 9:10 PM To: Susan Hares Cc: [email protected]; Jeffrey Haas; Joel M. Halpern; [email protected]; Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) Hi, Re 2(a) and (b): Are changes to RFC 5277 being proposed to make notifications highly reliable, or is there an assumption that implementations will just provide adequate memory to buffer notifications? Real time guarantees on getting data sounds like RAI work is needed? Are any changes needed to RESTCONF or NETCONF to support this requirement? Or is there just an expectation that implementations will be fast. IMO, the standard should be silent on response times and packets per second issues. Unless a certain speed is required for interoperability, then it seems inappropriate to mention in an RFC. Andy On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares < <mailto:[email protected]> [email protected]> wrote: > The minutes for the I2RS meeting are at: > > > > > <http://www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter> > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter > im-2015-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. > > > > 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. > > 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). > > > > 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. > > > > 4) Secondary identity data is meta-data that is stored in the agent. > Agent does not do anything with the meta-data. The client has to do > one edit per secondary at a time. > > > > 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. > > > > > > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > > > > > > Does anyone have any concerns regarding these requirements? > > > > Sue Hares > > > > > _______________________________________________ > i2rs mailing list > <mailto:[email protected]> [email protected] > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
