> The I2RS provides a framework for registering and for requesting the > appropriate information for each particular application. The I2RS provides a > way for applications to customize network behavior while leveraging the > existing routing system as desired.
> Sue: Registering and requesting - includes the existing streams. I think the question I had when reading this is "who is registering and requesting the streams?" Maybe just: "a framework for applications/controllers/??? To register and request information from agents running on forwarding devices..." Or some such might make it clearer. > ...manipulation of protocol-internal dynamically determined data is > envisioned. > "Dynamically determined" seemed like the best way to say this in the > introduction. What do you think? I guess it's okay, just something about dynamic stuff and determined stuff doesn't seem to fit together for me. :-) > Static System State: An I2RS agent needs access to static state on a routing > element beyond what is contained in the routing subsystem. An example of > such state is specifying queueing behavior for an interface or traffic. A > second example of such state is the security environment the routing system > runs in. How the I2RS agent modifies or obtains this information is out of > scope, but the standardized information and data models for what is > exposed are part of I2RS. This is fine... > Old:/ This notification identifies that the associated I2RS Agent has started./ > > New:/This notification signals to the I2RS Client(s) that this I2RS Agent has > started./ This is fine... > 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: The list of I2RS clients to send the > notification after the reboot and the agent-boot-count must > survive the reboot process.) Or perhaps -- Note: This notification will only be transmitted to I2RS clients which are known in some way after a reboot. The agent-boot-count MUST survive the reboot process. > old: /This notification reports that the associated I2RS Agent is shutting down > gracefully. Ephemeral state will be removed./ > > New: This notification reports that the associated I2RS Agent is shutting > down gracefully, and > that I2RS ephemeral state will be removed./ This is good. > Sue: By Default, the I2RS Agent is responsible for restoring state > after the I2RS agent goes away. Conceptually, this is the simply > removing the ephemeral state out of the combined yang module. I think the paragraph in question implies something more than just the agent going away, though -- it implies the withdrawal of ephemeral data by a client. Your answer implies this is handled by the model, rather than the agent -- but I'm not certain how this would work. Is the assumption that the subsystem the agent is controlling will have both of the two sets of state, and will always choose the ephemeral over the configured? Or is the assumption that the agent will always have this information? > There are the following yang module cases: There is another potential case, as well -- the ephemeral state currently wins, but a user locally configures something that should override the ephemeral state. This seems to add a lot of the same complexity the "single pane of glass" is trying to avoid. Perhaps it should be called out in the draft that locally configured state is never allowed to overwrite ephemeral state once the ephemeral state is written -- IE, once the agent wins over the locally configured state, this can never be changed (?), if we're really to avoid the complexity? > Another question -- this is a political football, I know -- but the agent is > responsible for restoring locally configured state that is overwritten, how is > this more complex or harder than restoring the state written by multiple > clients? > You and I believe that multiple states are as easy as single state, but when I > took over as > Chair I agreed not to undo existing I2RS WG decision for a single pane of > glass. Actually, I don't think the complexity has been avoided at all -- it still exists in the interaction between the local configured state and the ephemeral state managed by the agent. Complexity is like that -- it crops up when you don't expect it. Once the local state/agent state is resolved, multiple panes of glass will already be solved. > All such communication channels will use the same higher level I2RS protocol. > > I'm struggling with what this might mean -- transport protocol? YANG model > (marshalling protocol)? If there's a specific protocol in mind (there is, right?), > perhaps it would be best just to name it here. > > Sue: The challenge is that I2RS goals were not to create a protocol even > though the language from the bottom up even though the language makes it > seem like we are . Let me describe it and then let us work on language. > We used the phrase higher-level protocol. If it is unclear, should the term > "higher-layer protocol" be defined in definition or in this section? Or maybe just say, "a transport protocol?" I don't know what a "higher level protocol" means -- does it mean the protocol is higher up the OSI protocol stack, more abstract, lower on the OSI stack, or... ?? :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
