Problem Statement for Service Function Chaining
RFC 7498

Note: This ballot was opened for revision 10 and is now closed.

(Alia Atlas; former steering group member) (was Discuss, Yes) Yes

Yes ( for -12)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2014-12-28 for -10)
No email
send info
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

(Barry Leiba; former steering group member) No Objection

No Objection (2015-01-05 for -10)
No email
send info
It seems to me that this document would best serve its purpose as something in the sfc working group wiki, not as a published RFC.  That said, I will not object to its publication.

But note that the L3VPN working group, which is mentioned in the document, no longer exists.

I agree with the comments that there are things described herein that introduce security considerations that should be explored here, broadly, and that should not wait for the protocol documents.  If this document will set the stage for protocol development, setting out the security considerations early is important.

(Benoît Claise; former steering group member) No Objection

No Objection (2015-02-18 for -12)
No email
send info
- A little bit disappointed that there are no much operational aspects in this problem statement.
I guess this is fine as the charter contains:

    5. Manageability: Work on the management and configuration of SFC
    components related to the support of Service Function Chaining will
    certainly be needed, but first needs to be better understood and
    scoped.

However, the goal for SFC is to reduce the OPEX. For this to happen, the operational aspects (Troubleshooting and OAM come to mind) can not be an afterthought.

- I can't parse

   supports the movement
   of service functions and application workloads in the existing
   network, all the while retaining the network and service policies and
   the ability to easily bind service policy to granular information
   such as per-subscriber state.


-
OLD:

Service Function Chain (SFC):  A service function chain defines an
      ordered or partially ordered set of abstract service functions
      (SFs)

NEW:
Service Function Chain (SFC):  A service function chain defines an
      ordered or partially ordered set of abstract service functions
      
OLD:
 Service Function:  A function that is responsible for specific

NEW:
 Service Function (SF):  A function that is responsible for specific

- 
In the Service Function Chain definition, I'm not sure how the sentence "An example of an abstract service function is "a firewall" helps the SFC definition.
Anyway, this is covered in the Service Function definition.

(Jari Arkko; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-01-03 for -10)
No email
send info
2.3.  Constrained High Availability

   An effect of topological dependency is constrained service function
   high availability.  Worse, when modified, inadvertent non-high
   availability or downtime can result.

This seems to say, "when you break it, it's broken" which as a tautology I agree with.

I don't see any particular reason a set of elements in a sfc should be be lower availability then if they were all static physical objects and were assembled to support the same application.

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

No Objection (2015-02-17 for -12)
No email
send info
Thanks for addressing my question on multi-tenancy and adding in text to describe how that could be handled.

I agree with Barry, Alissa, and maybe others that a wiki may be a better option, but I won't stand in the way of publication.  I do think the problem SFC is working on is important and the work will be worthwhile, but this draft isn't ready ready or may not need to be published.   

There are still numerous security considerations to be included as pointed out in the SecDir review and in Stephen's DISCUSS points that I support.

The draft mentions ordering for service functions, and it would be good to see some concrete examples of how security may be an issue with different options for ordering.  Since SFC's scope is a single administrative domain, the service chaining could result in session decryption at various points in the chain that could result in security and privacy exposures within that domain (typically considered a manageable risk).   Functionality may be limited for some of the service functions if the decryption does not happen prior to that point and risk prioritization will be necessary (exposure of data, session interception, corruption of data, etc. could result from this exposure) since this is likely to be used in hosted environments with multiple tenants.  The SecDir review did mention crossover between management/control and data planes, but tenant isolation may also need to be mentioned.

Some nits (I don't think others mentioned these, but sorry if they were already addressed):
Section 2.1: 3rd paragraph:
Is this intended to mean after a new service function is added?  I can't imagine that this our happen on the fly, so I think that's the case and adding a word or two may help:
from:
   As more service functions are required - often with strict ordering -
   topology changes are needed before and after each service function is added
   resulting in complex network changes and device configuration.  

4th paragraph:  I'm have trouble reading this paragraph as I think it contradicts itself, but the example in the following paragraph is helpful.  If topology dictates placement, how could using topology not be viable?  Maybe rewording it would help:
   The topological coupling limits placement and selection of service
   functions: service functions are "fixed" in place by topology and
   therefore placement and service function selection taking into
   account network topology information is not viable.  Furthermore,
   altering the services traversed, or their order, based on flow
   direction is not possible.

Thanks,
Kathleen

(Spencer Dawkins; former steering group member) No Objection

No Objection (2015-01-04 for -10)
No email
send info
<preamble>

I'm going to have limited opportunities to participate in conversations about this draft before Thursday's telechat, and I'm a no-objection, so don't worry about resolving these comments before the telechat if you need to ask me questions. Your responsible AD will make sure the right thing happens, even if the draft is approved on the call.

</preamble>

I look forward to seeing how Adrian's Comments and Stephen's Discuss and Comments are resolved. 

I wish I was more comfortable with the idea that service function traversal might not be strictly ordered. I'm not the right guy to ask for more explanation about that, but it does seem a possible source of additional security problems. Adrian is concerned (at Comment level) about the idea that required service functions might be inadvertently bypassed in an overlay topology; I'm not thinking that having service functions being applied in flexible order in an overlay topology would make the network *more* secure.

I could be confused, but I'm thinking you could get different answers depending on the order that service functions are applied (to guess at a possibly bogus example, if a path has a NAT and a firewall that's looking at source/destination IP addresses, a packet that's been NATed might be more or less acceptable than the same packet that would be NATed after the firewall looks at it).

A simple "yes, you're confused", or a "that's not a problem in practice" could be a fine response to this comment.

I'll defer to the SEC ADs to decide whether that's a problem, of course.

I'm also wondering if everything you're running through the service function chain has a hop count. If not, is there any concern that one might end up with a loop because a service function transforms a packet in a way that would cause it to be sent back to a service function that's already processed the packet? We've had fabulous loops with SIP proxies forwarding the same request back and forth, and resetting Max-Forwards to a default value each time. 

A simple "yes, everything has hop counts", or a "no, that's not a concern" could be a fine response to this comment.

In 4.  Related IETF Work

   4.  [ALTO]: The Application Layer Traffic Optimization Working Group
       is chartered to provide topological information at a higher
       abstraction layer, which can be based upon network policy, and
       with application-relevant service functions located in it.  The
       mechanism for ALTO obtaining the topology can vary and policy can
       apply to what is provided or abstracted.  This work could be
       leveraged and extended to address the need for services
       discovery.

This is probably OK for inclusion in the problem statement, but my impression after discussions in the ALTO session in Honolulu is that the topology ALTO is looking at, is ONLY a topology of ALTO servers, at a sufficiently abstract level that it's hard to imagine ALTO lookups being part of a service function chain. You do point out that ALTO is working at a higher abstraction layer in your text, and this question is still open in ALTO, so probably no need to change the text - just don't get anyone's hopes up!

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2015-02-09 for -11)
No email
send info
Thanks for handling my discuss via the additional security considerations
text. I look forward to seeing the SFC architecture and subsequent
documents and how they handle the security and privacy issues that 
will need to be tackled.

(Ted Lemon; former steering group member) No Objection

No Objection ()
No email
send info

(Alissa Cooper; former steering group member) Abstain

Abstain (2015-01-07 for -10)
No email
send info
The WG wiki seems like a more logical place to publish the content of this document. It doesn't seem to really refine the scope of the WG much beyond what is in the charter; is sufficiently high-level to be describing a generic technology problem; and lists a number of existing problems without indicating whether or how the work of the WG is expected to address them.

I will not stand in the way of publication, but we need not spin up the IETF machinery for documents like this.

(Richard Barnes; former steering group member) Abstain

Abstain (2015-02-18 for -12)
No email
send info
I agree with my esteemed co-AD.