Thanks Fred, great review. I think the subject escaped, adjusted so we can find it. joel On 3/15/16 2:41 PM, Fred Baker (fred) wrote: > I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. > > I think the draft is ready with nits and some changes. I don't believe that any of these issues are showstoppers, but I do believe they require addressing. > > > 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. > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR at ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > Attachment: signature.asc Description: OpenPGP digital signature