Subject: [sfc] Adrian Farrel's No Objection on draft-ietf-sfc-problem-statement-10: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Dec 2014 02:58:14 -0800

Adrian Farrel has entered the following ballot position for
draft-ietf-sfc-problem-statement-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting No Objection on this document although I did not find it a
satisfying or detailed read. I think it contains text that could be left
out and would improve the document. I think it omits material 
(describing the deployment and operation of service function chains
today, and discussing security) that should be included. None of these
issues quite makes it to the level of a Discuss for me, but it was a
close thing. 

Perhaps the authors and working group would like to look at the 
document more closely.

---

Section 1

   Furthermore
   there is a cascading effect: service changes affect other services.

This is not clear (to me). 
Perhaps you intend s/affect/may affect/
Perhaps you intend s/service changes/service function changes/
And maybe you meant that the introduction of a new service function onto
a path in order to change one service, causes that same service function
to be applied to all traffic on that path thereby changing other
services.

---

Section 1.1
Thank you for the reference to OSI layers. It's been a long time and
they have been sorely missed. 
In a document where you are hot on overlays (which imply layer 
inversions) the mention of OSI layers is certainly "interesting".

---

Notwithstanding your definition in section 1.1, the term "Service 
Function" remains ambiguous. Under your definition, a packet forwarder
is a service function. What about a packet classifier?

---

Section 1.1 Service Function Chain
I stumbled over "The implied order may not be a linear progression".
I think you need s/implied order/ordering constraints/

---

I suspect 2.2 needs to say "physical topology" since the point of this
work is to introduce overlays that make changes to the service topology
possible with simple configuration.

---

Section 2.3

Flip the order of the paragraphs so that the current first paragraph
has context for its statements.              

However, I think I contest the scope of your statements. They are 
true when the failure is the failure of a service function but there is
continued ability to forward traffic. They are not true when the failure
is of connectivity (such as a link) or of forwarding (such as a service
function node). In those cases "in the same topology" might be better
phrased as "in parallel paths through the same topology."

---

Section 2.4 is something of a marketing statement which is a shame.
Anyway, it conflicts with two things when it says: 
   Service function chains today are most typically built through manual
   configuration processes. These are slow and error prone.  With the
   advent of newer service deployment models
Firstly, the prior text gives the impression that the service function
chain is most typically built through physical deployment of service
function nodes along traffic paths and their subsequent configuration.
Secondly, there is little (if any) difference between a manual 
configuration process and a "newer service deployment model". That is,
automation of configuration is identical in effect to manual 
configuration.
Surely the distinction you want to draw out is the change from physical
placement of service function nodes and the consequent constraints on
ordering with the proposed virtualisation of topology through the 
overlay that allows service function nodes to be located anywhere and
chained in arbitrary orders.

---

I think the concept of "transport" in section 2.6 will (or should) run
into the classic problem of the two meanings of "transport". Can you 
make the text clearer that you are not discussing whether UDP, RTP, SCTP
etc. are in use.

---

Does 2.7 mean "flexible" instead of "elastic"?
Would it be good to have explained the current state of the are 
described here for the first time? Maybe an early section of the 
document could spend some (more) time describing how SFC is done today.

---

Shouldn't 2.8 say "...unless packets are reclassified and classification
behaviors are configured at each service function node" ?
The point being that a more flexible and granular SFC mechanism (such
as the WG is producing) effectively performs fine-grained classification
at the head of the chain and then "marks" each packet with the result of
that classification through a chain identifier, through a composite 
chain, or in metadata. Where an overlay topology is used, you are not
actually changing the behavior you describe in this section (the mapping
of traffic on a segment into a service function is still coarse), but 
you are changing the granularity of the topology.

---

Section 2.10

Is "may not" "might not", "must not", or "cannot"?

---

Why doesn't section 3 mention encapsulation? Isn't this a large part
of the work and solution?

---

I should really be happier were Section 4 to be removed. I don't believe
it adds anything, it is (by its own admission) incomplete and leaves one
to wonder about the significance of omissions, and it is out of date
even before it is published.

Actually, I have this particular Comment almost at the level of a 
Discuss: this section is harmful to the work of the IETF and detracts
from the value of this document.

---

Section 5 (rightly) notes the content present in Section 3.
Why doesn't the Abstract also mention what will be in Section 3?
Why doesn't the Introduction mention the content of Section 3?
What value does Section 5 add to the document?

---

Section 7 is deficient, IMHO. The problem statement should describe the
problem of security of configuration and construction of service chains
today. It should also observe that some service functions are 
specifically security functions: placing such functions on the physical 
path ensures that they are executed, while allowing them to be by-passed
in the overlay network or left out of a chain is a considerable risk.

However, I will leave it for the Security ADs to decide whether this 
point needs to be Discussed.

---

Dave Mcdysan needs a capital D