Subject: [i2rs] Comments on draft-bitar-i2rs-service-chaining-01

From: "Russ White" <[email-masked]>
Date: Wed, 26 Feb 2014 21:10:15 -0500

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?