Benoit: Great comments - see below. Thanks for finding additional typos/unclear text. You some good questions - I hope my answers were as good.
Cheerily, Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Benoit Claise Sent: Wednesday, March 16, 2016 9:36 PM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-architecture-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >A couple of points, not all of them are minor (I've been wondering: >COMMENT or DISCUSS. Let's go for a COMMENT) > >- "Second is the access to structured information and state that is frequently not directly configurable". >I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft->ietf-netmod-opstate-reqs-04 It would be good if the terminology were aligned. Sue: You are so right. The ietf-netmod-opstate-reqs-04 was not approved when I started the process - but I will do this in -14.txt > This I2RS architecture assumes a data-model driven protocol where the > data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1 > ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model > drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). " >RFC 6020 is YANG 1.0, not YANG 1.1 >I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1 btw, this "YANG" not "Yang" Sue: On Yang --> YANG (Ack - will fix in -14.txt). Will change error on RFC6020 to 1.0. Due to all the features we need for pub/sub - I2RS will be Yang 1.1. > Are the two sentences redundant? > As can be seen in Figure 1, an I2RS client can communicate with > multiple I2RS agents. An I2RS client may connect to one or more I2RS > agents based upon its needs. Sue: Sigh. Other reviewers felt that we needed the second sentence to Indicate that is was 1-n I2RS Agents. > There are several key benefits for I2RS in using model-driven > architecture and protocol(s). First, it allows for transferring > data-models whose content is not explicitly implemented or understood. > Reading that second sentence multiple times, I still fail to understand. > Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood. > Really confused. Sue: I see your point on the editorial issue, and I will try to fix it. (see -14.txt) >Two of the existing protocols which the > which may be re-used are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]. >editorial "may be reused". / I will check with RFC editor (some people say reused /re-used). >What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. > On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or > YANG1.1), and in some cases, a complete specification (for example the notification) Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols. The architecture does out rule out other data transfer protocols, but says the WG will design I2RS as a higher level protocol that combines other protocols (NETCONF/RESTCONF + x). The I2RS requirements documents and protocol strawman will state is if any other protocols will be used for a particular version of I2RS with a particular scope for data modules. I am sorry if this is not what you excepted, but it was my direction from my AD on how to approach this work. At this time, we are closing in on the last of the requirements documents - the requirements for other data flows. draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data flows, but IMO the first version of the I2RS is likely to stay with just NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module library, and some yang changes. > To handle I2RS Agent failure, the I2RS Agent must use two different notifications. > NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the > I2RS Client(s) that the associated I2RS Agent has started. It > includes an agent-boot-count that indicates how many times the > I2RS Agent has restarted since the associated routing element > restarted. The agent-boot-count allows an I2RS Client to > determine if the I2RS Agent has restarted. (Note: This > notification will be only transmitted to I2RS clients which are > know in some way after a reboot.) >- editorial: > Optionally, a routing element may permit a priority to be to be.... > For the case when the I2RS ephemeral state always wins for a data > model, if there is an I2RS ephemeral state value it is installed > instead of the local configuration state. > Again, I read that sentence multiple times, and could not understand it Sue: Reasonable editorial comment. This was added to address another comment, But it looks like we broken something. Text change below. Old/ Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / New: Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the configured priority of the I2RS ephemeral Is higher than the Local Configuration's policy, the The I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / > figure 2. "The initial services included in the I2RS architecture are as follows." > Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ... > Maybe I should review the I2RS charter? Sue: Our charter is wide, but only ephemeral layer deep. Due to the excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we are focusing on allowing ephemeral to be added to any data model. I2RS WG is focused first on the I2RS protocol and protocol independent modules. After this, I2RS purpose is to simply support other WGs in creating data modules with ephemeral state. > The I2RS protocol may need to use several underlying transports (TCP, SCTP > (stream control transport protocol), DCCP (Datagram Congestion > Control Protocol)), with suitable authentication and integrity > protection mechanisms > Do you really want to have define transports? Sue: We indicate that I2RS will use these protocols. Each protocol we mention has to be then validated with requirements (see protocol security requirement and security environment requirements). >And below is Fred Baker's OPS DIR review: Sue: Responded to Fred on another channel - before I got your message. I will not repeat it here. ========================== The first nit is a statement in section 1.1: Such an interface also facilitates the injection of ephemeral state into the routing system. Ephemeral state on a router is the state which does not survive a the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device. Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage. I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times. At the top of page 6, the first paragraph reads: The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS Services. Section 4 describes how access is mediated by authentication and access control mechanisms. Figure 1 shows I2RS agents being able to write ephemeral static state (e.g. RIB entries), and to read from dynamic static (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the I have a hunch the authors intended to complete the final sentence. In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. >From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple. So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?" In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read An I2RS Client is not automatically trustworthy. Each I2RS Client is associated with identity with a set of scope limitations. I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
