Service Function Chaining (SFC) Architecture
draft-ietf-sfc-architecture-11

I'm clearing my DISCUSS on this document, but want to leave most of the text just for the record.

I want to talk about the intended status of this document: right now (-08) it
is marked as Informational, but up to -06 it was intended to be on the
Standards Track.  Why did this change?  [I looked at the archives, but couldn’t
find a specific reason or discussion.]

From the Abstract:

   This document describes an architecture for the specification,
   creation, and ongoing maintenance of Service Function Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, with a focus on those to be standardized in the
   IETF.

If this architecture is what ongoing standardization of SFC should be based on,
then I think it should be on the Standards Track.  There are already a number
of drafts that intend to be on the standards track that are using this document
as a normative reference [1], which makes sense based on the text above.  Note
that none of the drafts that use the document as a normative reference have
been adopted by the WG, but the point is still the same: if the intent is for
this document to be used as a base for future standardization, then I think it
should belong in the standards track.  I know that we can always add a downref
exception, but why would that be necessary if this document is intended to be
guide future standardization for SFC?

OTOH, if the WG decided that this is just “an architecture” (vs. *the*
architecture), and that is why the intended status changed in -07, then it
should be made clear in the text.

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/

- Section 1.1
What does "minimum requirements on the physical topology"mean in:

   This document defines the architecture for Service Function Chaining
   (SFC) with minimum requirements on the physical topology of the
   network, as standardized in the IETF. 

It seems to me that "independent" is what you're after, like in:
   "it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities."

or
   "This SFC architecture is predicated on topological independence from
   the underlying forwarding topology." 



- Service Function Path definition: I'm confused. you don't explain what it is, but only explain why you need it.
Later on, I see "As an example of such an intermediate specificity, there may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is the ordered list of SFFs?

-
"Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. 

Am I correct that it only applies in case of a SFC proxy?
Related question, along the same lines:

       1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and, if needed, is forwarded
       to another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path. 

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)

This would be consistent with section 5.4:
   "Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once."


- Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy.
In figure 3, the SFC proxy is inside the domain, right?
But what about the SFC-unaware Service Function? Inside or outside?

- 
6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

Except if one SF depends on the shared metadata from a previous SF in the chain, right?


Editorial.

- 
OLD:
   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
NEW:
   SFC Proxy:  Removes and inserts SFC Encapsulation on behalf of an


THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD  (AND THIS DISCUSS-DISCUSS HAS BEEN DISCUSSED)

- Can you explain this disconnect:
From the charter:

    It will produce an architecture for service function
    chaining that includes the necessary protocols or protocol extensions to
    convey the Service Function Chain and Service Function Path information
    to nodes that are involved in the implementation of service functions
    and Service Function Chains, as well as mechanisms for steering traffic
    through service functions.

From the abstract:

    This document does not propose solutions, protocols, or
       extensions to existing protocols.

While I'm on the charter, I'm always available for this milestone:

    Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining

Thanks for adding text to address my previous discuss:
1. The Security Considerations section only talks about privacy of the SFC information for classification.  The more important point may be the privacy of any data gathered from a payload used for the classification and this needs to be mentioned.

Comments:

1. For the Service Functions, I would think you would want to leave out "Lawful Intercept" as a device type since it's not a universal requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly more difficult as encryption is rolled out.  The IETF and IAB both support the increased use of encryption for privacy and security purposes and are looking to have it end-to-end where possible.  With the work out of TCPInc, encryption will be even more prevalent.

Thanks for the extensive discussion about the security aspects
of this architecture. I think in -11 we've probably gotten as far
as we're likely to agree upon in terms of addressing those (which
is far enough for me to change from a discuss to a no-objection
ballot) and we can work further on the topic as specific protocols 
that adhere to this architecture emerge.

I didn't check if the (non-blocking) comments below were
taken into account or not in -11. If we need to chat about 
any of them feel to ping me.

OLD COMMENTS BELOW

- It occurs to me that it might really be better for the WG
to not publish this as an RFC now, but rather to put it on
hold until they've made progress on the solutions. Perhaps
revistiting this when the solutions are just at WGLC would
result in the eventual RFC being a much more useful document.
I think this one has to hedge so many bets that it's quite
vague and won't be very useful even in the medium term. But
that's just a suggestion, I can see why the WG might prefer
to push this out, even if that might only give the appearance
of progress and not reflect real progress.

- While IPR on an architecture document is sad to see, esp
with what seems like it may be restrictive licensing, I do
see the wg debated that and decided to move on.

- The charter text describing this deliverable notes that
"The initial scope is restricted to a single administrative
domain, keeping in mind that architectural decisions made for
the intra-domain case may have implications for the
inter-domain case." So I think there is also a currently
missing analysis (or the results of that) as to how the
single-domain elements of this architecture might impinge on
a later inter-domain architecture. So the text at the 
end of section 1.1 appears to contradict the chartered 
goals.

- Chains will require some representation, and re-ordering
that is security sensitive (e.g. swap order of f/w and nat
for fun) therefore there must be a requirement for some data
integrity service and origin authentication and an
authorisation decision function and therefore there must
(istm) be a need for the architecture to define a chain
producing entity of some kind that could be authenticated.
That is an example of the missing security analysis that
really is needed before this proceeds. (See my discuss point
2)

- 1.1: "classified on ingress" and applicable to mobile
networks are slightly incongrous. In the case of WiFi when do
the packet ingress? (When it gets to the AP or leaves the
mobile node transmitter?) I suspect you really mean the wired
bits of a mobile network so it might be better to say that.

- 1.2 should follow 1.3 I think.

- 1.2: What does "chaining logic" mean? You say there's no
standard chaining logic, which is maybe right, but then you
imply that a fully ordered set of SF's is a well defined
thing. I'm not sure that makes sense. Perhaps what you want
to say is that the architecture doesn't determine if an SFC
{{A,B},C} is or is not the same as {{B,A},C} but that later
protocol work will have to do that. (In fact, I think you
could say a lot more here and probably should.)

- 1.2: what is a "chaining policy"? Isn't here where those
terms need to be defined.

- 1.3: SFC definition: by ordered do you mean fully or
partially ordered?

- 1.3: I'd omit LI as a SF - we won't be standardising that
(cf. RFC2804) so better to not drag in the controversy
really. Similarly, HOST_ID injection is not afaik any kind of
standard and perhaps not likely to be (cf. some confict
reviews on the same telechat as this) so I'd also drop that.
And I think all of the exemplar SF's should really have a
reference (ideally an RFC).

- Figure 1 caption is misleading. That seems to me to show a
set of paths through (one or more) graphs but doesn't show
the full graphs themselves.

- 2.2: The concept of a bi-directional SFC seems odd.  Does
the example given imply that all traffic (of what kind?) that
followed SF1->SF2->SF3 on the way "in" must follow
SF3->SF2->SF1 on the way "out"? If so, then I think more
precision is needed really. The hybrid concept seems even
odder to me.

- 2.3: How can an SFP "be vague" - surely the point of an
architecture is to avoid such vagueness? If you mean that an
SFP representation can embody an if-statement then saying
that would be the thing to do.

- Section 3: I think there's maybe a missing principle here
about not making security and privacy worse in general.

- 4.1: I wonder if one could ever get enough SFC control
traffic that congestion would be an issue?  If so, should you
say rather that any transport that has some way of handling
congestion is ok. If not, then I guess the current text is
fine.