Andy and Joel: As my chair note stated, the chairs know they are providing extra details with the requirements. However, in the past the feedback from various NETMOD/NETCONF participants has been not enough detail. The use of NACM to control input to a I2RS agent and assign priority to a client - is one of those extra info. I believe the tight notification guarantees to support a I2RS control loop is a requirement rather than extra suggestions.
Hopefully, that the NETMOD/NETCONF chairs will review through the initial ephemeral state document and describe what they feel is requirements versus added suggestions. The I2RS chairs will clean-up that requirements document next week. Sue -----Original Message----- From: Andy Bierman [mailto:a...@yumaworks.com] Sent: Friday, June 05, 2015 12:38 PM To: Joel M. Halpern Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-cha...@ietf.org; Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern <j...@joelhalpern.com> 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:j.schoenwael...@jacobs-university.de] >>> Sent: Thursday, June 04, 2015 2:24 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; jh...@pfrc.org; 'Joel M. Halpern'; >>> i2rs-cha...@ietf.org; '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-in >>>> ter >>>> 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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
