Andy; You are making an excellent point. I totally agree. I also wonder if the same logic applies ( and I'd say much more so) for the opposite direction - when pushing routes real time from I2RS Client to Agent. If Yes, isn't this is what FORCES folks (Jamal especially) have been saying all along? NETCONF/RESTCONF are great for a lot of stuff, but maybe not so much for I2RS? What's the point of "raping" NETCONF if: a) it was never designed for architectures like I2RS; b) it's properties do not square (at least easily enough) with I2RS requirements, c) no other NETCONF based applications are going to benefit from the proposed by I2RS modifications.
Cheers, Igor ________________________________________ From: i2rs [[email protected]] on behalf of Andy Bierman [[email protected]] Sent: Friday, June 5, 2015 10:28 PM To: Susan Hares Cc: Jeffrey Haas; [email protected]; Joel M. Halpern; [email protected]; Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) Hi, IMO NETCONF notifications are probably not the best choice for the high-performance low-latency signalling that I2RS wants between agent and client. There is a lot of overhead in the filtering, replay, YANG schema processing, XML encoding, etc. Binary notifications that contain hard-wired standard messages specially written to implement the I2RS protocol would be much faster and less expensive to implement. If this is to be as fast as a signalling protocol then it would be wise to consider protocol performance issues. Andy On Fri, Jun 5, 2015 at 12:43 PM, Susan Hares <[email protected]> wrote: > 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:[email protected]] > Sent: Friday, June 05, 2015 12:38 PM > To: Joel M. Halpern > Cc: Susan Hares; [email protected]; Jeffrey Haas; [email protected]; 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 <[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-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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
