On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern <[email protected]> wrote: > I would describe it somewhat differently from any of the choices you list. > > A) I2RS has some a set of architectural requirements. These were not as > cleanly described as one might like but they were very clearly accepted by > the working group and understood to be needed for the protocol choice. > B) The working group has decided that it will use NetConf/RestConf if that > can meet the requirements. >
I would say the arch is a mixture of architecture and functional requirements. Almost as if the authors had a design in mind and reverse-engineered the requirements from the design. As Juergen pointed out, the requirement to assign a priority to a client does not require NACM. NACM is a design choice for that requirement. I have some concerns about the tight notification control loop that is proposed. IMO, this is going to be too slow and too complicated. It seems to me that the only company that has implemented something close to I2RS is using a design that does not rely on a near real-time reliable notification loop. I don't have a strong preference for ephemeral datastore vs. tagging non-config data. The current NETCONF datastores only apply to config=true objects. YANG design allows for the config=false data to be further partitioned, but this is not required for I2RS to work. > The corrolary is that if neither NetConf nor RestConf can meet the > requirements, then the working group will, in my opinion, have to do > something else. That would be OK too, if you want to completely decouple I2RS from configuration. This simplifies some things if was invisible to NETCONF/RESTCONF and YANG. > > Yours, > Joel Andy > > On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >> >> 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 >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
