On 6/10/14, 1:21 PM, "Jeffrey Haas" <[email protected]> wrote:
Problem statement: >> Section 2: It would be useful to clarify the scope of the proposed data >> model. <snip> >The way I've interpreted the diagram is basically: >- I2RS defines the client and agent and the interactions (protocol) >- The Agent, by necessity, interacts with system components in a black-box > implementation-specific fashion. > >While I understand you're looking for "where does a data model box fit >into >the diagram", I'm not sure there's enough flexibility in the ASCII diagram >to cover that. :-) If this were UML (which would balloon the diagram an >order of magnitude), we'd have Interface lollipops all over the place and >even then, that's probably the best we'd have for the high level >description. WG] Not necessarily asking for additional boxes in the diagram, because I agree that there’s no way to represent it unless you duplicate the same diagram (with appropriate changes in scope) for the data model. I was more thinking in terms of making it a bit clearer in the text following the diagram that the data model may necessarily include things that are listed as out of scope for the I2RS interface/protocol, because it needs a way to represent the things that it gets from the I2RS agent based on its black box interaction with other parts of the routing system. > >> but you may want to be more explicit in the latter half of >> section 2, as well as replacing ???I2RS" with something more >>descriptive in >> the diagram to avoid naming confusion since ???I2RS??? can mean IETF >>WG/effort >> OR the actual interface to the routing system and related protocol. > >I think it's meant to cover both cases: Within the scope of the WG effort >and also protocol interactions. WG] That’s sort of the problem I was pointing out. Maybe this only matters while we’re in the middle of the discussion and people remember the name of the WG and are therefore likely to conflate the two, but for right now, it does have some potential for confusion. I leave it to the WG and authors to decide whether that’s a trivial concern or not. Architecture: > >Flow data isn't specifically in-scope to chartered work - today. ‘WG] Yes, wasn’t advocating to include it, merely observing that the document is not explicit one way or the other here, and one could make the argument that flow data is a type of stats. So if it is indeed out of scope, I think there’s value in calling that out specifically. > > >> 6.2 - I recommend that you explicitly call out the need to be able to >> review (e.g. via CLI) the changes made by the I2RS agent and its state >> data without a dependency on the client itself. <snip> >[Please note: Discussion, not necessarily disagreement.] > >I think there's a few challenges with this. The biggest one is that no >matter how carefully we try to word such an architectural requirement, >we're >going to end up making demands on implementations that either will be >difficult to standardize or perhaps even impossible. > > >For what it's worth, this isn't much uglier (and probably is a case that >brought this to mind for you) than configuration state imposed by SNMP >rather than the CLI. Configuration constructs in SNMP may not have good >mappings to those in the CLI and vice versa. WG] and as noted, we recommend against using SNMP to impose state anymore for lots of good reasons, so I’m not at all convinced that “not much uglier than SNMP” is a feature… > >A trivial comparison might be if your I2RS agent was implemented by doing >CLI translation, then it might be possible to do CLI comparisons. But if >it's not, such comparison may be hard. WG] The reality is that operators have been dealing with this disconnect for years, where a vendor implements a feature that is either fully supported in CLI but not simultaneously in $magic_management_interface du jour, or vice versa. It can be a temporary gap due to mismatches in release cadence, or it could be a permanent gap based on a conscious decision, but either way those gaps make it difficult for operators to implement the feature, because either you don’t have a way to verify and troubleshoot it outside of the primary (systematic) interface, or you don’t have a way to systematically interact with it and you have to screen scrape or swivel seat. This can’t be an either-or, because for the foreseeable future we are not going to be able to assume that if the agent/systematic interface is present, that no one will ever use or need the CLI for anything that can be done via the agent, or that the uses for each can be mutually exclusive. That just makes the system brittle and the methods for troubleshooting it needlessly complex. There are a lot of folks in operations with a healthy distrust for large-scale, complex automation where the system is making a lot of decisions on its own, because of the risk to experience a major outage due to the "ghost in the machine” - for them, that makes having a means to observe/manipulate/fix things independent of the machinery is a non-negotiable requirement, at least until there is some trust built up that the machine isn’t going to go insane and nuke the network. There’s a reason I’m using the language I’ve chosen here, the fears are not totally rational, but they do serve as a real barrier to deployment, so we ignore them at our own peril. > >Given the above, what would you suggest? I realize what we want is a way >to >troubleshoot, but I'm not sure there can be any specific recommendation >that >will span the architectures well enough to be standardized. WG] Well, I think there’s a valid traceability and troubleshooting requirement in the form of needing the ability to do verification and examination of the state and actions taken by I2RS agent(s) without invoking the agent being examined. We don’t need to be prescriptive on the format for that information, nor the method for providing that independent avenue for accessing it, we must only note that it needs to be available. For example, in a routing element that doesn’t really have a CLI, the independent method doesn’t have to be via CLI, it could be via a web UI or some pretty GUI if that’s the other method to manage the device. I mention CLI as an example because for the most part, the fail-safe method for interacting with the routing system today is indeed CLI. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
