These might (or might not) be helpful... :-) Russ
== I found the opening paragraph a little confusing, or perhaps "blunt," in terms of describing the problem with terminology the average reader might not understand. Maybe something like: Service chaining treats a network as a set of services through which a packet or flow must pass in order to be fully processed. Services include functions such as wide area optimization, carrier grade network address translation, stateful filtering, and intrusition detection. As an example, a flow originated by a server within one zone of a network might need to pass through an application acceleration service, a stateful packet filters, and an address translation service before it can be passed through the zone border to a server or host residing in a different zone. Such a sequence of services applied to a flow is referred to as a service chain. The further examples after the last sentence aren't really needed, I don't think. == In the second paragraph, you begin with "may include," and end with, "among others." You don't need both. :-) == In the third paragraph, I'm not certain why this "new service," is even noted. If it's out of scope, and it's not going to be explained in this document, it doesn't need to be mentioned at all. I would suggest leaving that part out. Just say something like: The transition from one service to the next in a service chain may be conditioned on the output of the previous service, or it may be pre-determined (unconditional). This document addresses the simple use case of predetermined service chains... == I'm not certain why the bit about service chains being located on a single node, several virtual nodes, or etc., is included. I don't see what it adds to the description of the use cases. == The last paragraph in the first section should probably be merged with the third paragraph, above, I would think. This would put the entire document description in one place. == You mention this: It is often the case that when a flow in a bidirectional session is assigned to a service chain, the reverse flow of the same session is required to traverse the same chain in the reverse order. But there doesn't seem to be any requirement tied to it later in the document... It would seem that some sort of flag might be required to indicate that a particular service chain requires a symmetrical path? Should that be included as a required piece of information some place, perhaps in 3.1? _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
