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

[Ballot comment]

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.

[Ballot discuss]

Just a note that I looked over -09 and don't think it yet resolves
the discuss, so the discussion continues.

-- previous text:

(1) I note the charter calls for this deliverable to "provide
a description of... security models" The charter also
generally notes that "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." My conclusion is that this
deliverable needs to reflect the results of a security
analysis that the wg are suppoed to have carried out but that
it's currently too vague only saying that solutions need to
consider this. (Essentially this is a continuation of the
mail threads from the secdir review [1] and a satisfactory
resolution of that will probably resolve this.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html

(2) Metadata that contains information that is protected in
the data plane SHOULD be equally well protected when passed
about by SFC. I hope that's acceptable and documented. I'm
not sure myself if "passed about" ought also include within a
device but maybe it should really.  But at minimum, I do
think you need to define confidentiality and origin
authentication services for SFC metadata and/or for the SFC
encapsulation as a whole. And I think this architecture
document needs to say that those services have to be
well-defined as part of any solution. (And I am not
saying that this draft needs to define how to do those.)

[Ballot comment]
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.

[Ballot comment]
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/

[Ballot comment]

- 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

[Ballot discuss]
I agree with Stephen's discuss and comment points and am just adding a few that I think are also important.

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.

[Ballot comment]
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.

[Ballot discuss]
DISCUSS-DISCUSS: no action from the authors is expected at this point. This will be discussed during the telechat.

- 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

[Ballot comment]
- 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

[Ballot comment]

- 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.

[Ballot comment]

- 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
1)

- 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.

[Ballot discuss]

(1) I note the charter calls for this deliverable to "provide
a description of... security models" The charter also
generally notes that "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." My conclusion is that this
deliverable needs to reflect the results of a security
analysis that the wg are suppoed to have carried out but that
it's currently too vague only saying that solutions need to
consider this. (Essentially this is a continuation of the
mail threads from the secdir review [1] and a satisfactory
resolution of that will probably resolve this.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html

(2) Metadata that contains information that is protected in
the data plane SHOULD be equally well protected when passed
about by SFC. I hope that's acceptable and documented. I'm
not sure myself if "passed about" ought also include within a
device but maybe it should really.  But at minimum, I do
think you need to define confidentiality and origin
authentication services for SFC metadata and/or for the SFC
encapsulation as a whole. And I think this architecture
document needs to say that those services have to be
well-defined as part of any solution. (And I am not
saying that this draft needs to define how to do those.)

[Ballot comment]

- 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 end of section 1.1
does not appear to meet 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
1)

- 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.

[Ballot discuss]
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/

[Ballot comment]
Just a couple of other comments:

1. Section 1.1(Scope): “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.”  What is standardized, the physical topology?  Confusing sentence.

2. Section 5.2 (SFC Control Plane): “This is part of the overall architecture but outside the scope of this document.”  I don’t understand how the control plane, being part of the architecture, is not in scope of the architecture document..??  Especially since in this section there is a discussion of the functionality to be provided by the control plane.  What am I missing?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sfc-architecture-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Service Function Chaining (SFC) Architecture) to Informational RFC


The IESG has received a request from the Service Function Chaining WG
(sfc) to consider the following document:
- 'Service Function Chaining (SFC) Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.  This document does not propose solutions, protocols, or
  extensions to existing protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2315/
  https://datatracker.ietf.org/ipr/2281/
  https://datatracker.ietf.org/ipr/2283/

This architecture document is the product of the Service Function Chaining (SFC) WG in the IETF Routing Area.  The WG is chaired by Jim Guichard and Thomas Narten.  Alia Atlas and Adrian Farrell are the routing area directors, with Alia being the AD directly supervising this working group.

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.  This document does not propose solutions, protocols, or extensions to existing protocols as these will be addressed in other documents produced by the SFC WG.

Note that the selected architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity as laid out in the SFC WG problem statement document.

This document has been reviewed multiple times by many participants in the working group and has undergone several revisions to integrate all aspects requested of the SFC architecture.  The document is also the product of a merge of multiple previous documents.

The document is in good shape, and the shepherd agrees with the chairs conclusion that it is ready for publication as an informational RFC.

This architecture document is the product of the Service Function Chaining (SFC) WG in the IETF Routing Area.  The WG is chaired by Jim Guichard and Thomas Narten.  Alia Atlas and Adrian Farrell are the routing area directors, with Alia being the AD directly supervising this working group.

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.  This document does not propose solutions, protocols, or extensions to existing protocols as these will be addressed in other documents produced by the SFC WG.

Note that the selected architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity as laid out in the SFC WG problem statement document.

This document has been reviewed multiple times by many participants in the working group and has undergone several revisions to integrate all aspects requested of the SFC architecture.  The document is in good shape, and the shepherd agrees with the chairs conclusion that it is ready for publication as a standards track RFC.

The shepherd has observed that the WG has received confirmation from all authors that all relevant IPR has been disclosed.