A very cleanly written draft, thank you. One question I had was prompted by section 3.2 - monitoring information. In this case, the ability to take actions during service node failure or notification that capacity has been exceeded was mentioned. Is part of the use case potentially replicating necessary state to the new and/or backup nodes to be able to attempt to handle such failover hitlessly? If so, that would potentially expand the information being monitored.
The section following that covers a set of information that may be monitored at the physical server level. One obvious component in the list that seems to be missing would be temperature. That does beg the question as to whether your parameters requiring monitoring should be generally expanded to many of the same things already covered by various physical monitoring mechanisms already deployed. For another example, fan speeds. Perhaps instead it might be suggested that server physical/electrical characteristics should be part of the monitoring information and not worry about enumerating them directly? Section 3.2 also somewhat hints at the ability to migrate functionality for service nodes as a general purpose behavior. While I suspect it's a bit out of scope for this use case document, making use of i2rs to help handle virtual server migration seems an obvious related use case. Section 3.3 makes me want to ask the following question to the authors of this draft and the authors of draft-chen-i2rs-ts-use-case: While the use cases are very targeted in the servicing chaining draft, there appears to be significant overlap in the underlying requirements for traffic steering. Should these drafts potentially have their use cases merged? -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
