Skip to main content

Problem Statement for Service Function Chaining
draft-ietf-sfc-problem-statement-13

Revision differences

Document history

Date Rev. By Action
2015-04-08
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-04-02
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-04-02
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-03-01
13 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2015-02-23
13 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-02-23
13 (System) RFC Editor state changed to EDIT
2015-02-23
13 (System) Announcement was received by RFC Editor
2015-02-23
13 (System) IANA Action state changed to No IC
2015-02-23
13 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-02-23
13 Amy Vezza IESG has approved the document
2015-02-23
13 Amy Vezza Closed "Approve" ballot
2015-02-23
13 Amy Vezza Ballot approval text was generated
2015-02-19
13 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2015-02-19
13 Alia Atlas IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2015-02-19
13 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-19
13 Paul Quinn IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-02-19
13 Paul Quinn New version available: draft-ietf-sfc-problem-statement-13.txt
2015-02-19
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-19
12 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-02-18
12 Richard Barnes [Ballot comment]
I agree with my esteemed co-AD.
2015-02-18
12 Richard Barnes [Ballot Position Update] New position, Abstain, has been recorded for Richard Barnes
2015-02-18
12 Alia Atlas [Ballot Position Update] Position for Alia Atlas has been changed to Yes from Discuss
2015-02-18
12 Benoît Claise
[Ballot comment]
- A little bit disappointed that there are no much operational aspects in this problem statement.
I guess this is fine as the …
[Ballot comment]
- 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.
2015-02-18
12 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-02-17
12 Kathleen Moriarty
[Ballot comment]
Thanks for addressing my question on multi-tenancy and adding in text to describe how that could be handled.

I agree with Barry, Alissa, …
[Ballot comment]
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
2015-02-17
12 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2015-02-17
12 Paul Quinn New version available: draft-ietf-sfc-problem-statement-12.txt
2015-02-12
11 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2015-02-12
11 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2015-02-09
11 Stephen Farrell
[Ballot comment]

Thanks for handling my discuss via the additional security considerations
text. I look forward to seeing the SFC architecture and subsequent
documents and …
[Ballot comment]

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.
2015-02-09
11 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2015-02-09
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-02-09
11 Paul Quinn IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-02-09
11 Paul Quinn New version available: draft-ietf-sfc-problem-statement-11.txt
2015-02-09
10 Alia Atlas Still needs to address Kathleen's discuss
2015-02-09
10 Alia Atlas IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2015-02-09
10 Alia Atlas IESG state changed to Waiting for AD Go-Ahead from AD Evaluation::Revised I-D Needed
2015-01-30
10 Alia Atlas Placed on agenda for telechat - 2015-02-19
2015-01-20
10 Alia Atlas IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2015-01-20
10 Alia Atlas Removed from agenda for telechat
2015-01-12
10 Alia Atlas Tag Revised I-D Needed - Issue raised by IESG set. Tag Revised I-D Needed cleared.
2015-01-12
10 Alia Atlas
Various reviews (secdir and IESG) need changes that are technical.  Therefore, this draft is going back to the WG for a quick update and additional …
Various reviews (secdir and IESG) need changes that are technical.  Therefore, this draft is going back to the WG for a quick update and additional WGLC.
2015-01-12
10 Alia Atlas IESG state changed to AD Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead::Revised I-D Needed
2015-01-08
10 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Benjamin Kaduk.
2015-01-07
10 Alia Atlas IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2015-01-07
10 Alia Atlas Telechat date has been changed to 2015-01-22 from 2015-01-08
2015-01-07
10 Kathleen Moriarty
[Ballot discuss]
I didn't see any mention of risks with multiple tenants and shared infrastructure for service functions, is that a concern?  This consideration may …
[Ballot discuss]
I didn't see any mention of risks with multiple tenants and shared infrastructure for service functions, is that a concern?  This consideration may fall into the same description as the second point from Ben's SecDir review (linked in Stephen's review). Although the SecDir review point could be within a single tenant environment where there may or may not be various levels of trust depending on access constraints (to the same or different set of applications for a single tenant).  I'd like to make sure both points get addressed or if someone can tell me why it doesn't matter, that would be fine too.
2015-01-07
10 Kathleen Moriarty
[Ballot comment]
I agree with Barry, Alissa, and maybe others that a wiki may be a better option, but I won't stand in the way …
[Ballot comment]
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
2015-01-07
10 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2015-01-07
10 Alissa Cooper
[Ballot comment]
The WG wiki seems like a more logical place to publish the content of this document. It doesn't seem to really refine the …
[Ballot comment]
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.
2015-01-07
10 Alissa Cooper [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper
2015-01-07
10 Alia Atlas
[Ballot discuss]
It was pointed out to me that the definitions in the problem-statement and the architecture differ.  These seem to be minor and accidental …
[Ballot discuss]
It was pointed out to me that the definitions in the problem-statement and the architecture differ.  These seem to be minor and accidental differences.  It is better to have the definitions in only one place or at least have a single authoritative reference.  Could you decide upon the correct and final definitions and please do one of the following:
    a) For overlapping definitions, define them only in the problem-statement and have the architecture refer to the problem-statement for the authoritative definitions (quoting if desirable).
    b) For overlapping definitions, define them only in the architecture and have the problem-statemen refer to the architecture for the authoritative definitions (quoting if desirable)
2015-01-07
10 Alia Atlas [Ballot Position Update] Position for Alia Atlas has been changed to Discuss from Yes
2015-01-05
10 Alia Atlas Notification list changed to sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com, sfc@ietf.org from sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com
2015-01-05
10 Barry Leiba
[Ballot comment]
It seems to me that this document would best serve its purpose as something in the sfc working group wiki, not as a …
[Ballot comment]
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.
2015-01-05
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-01-04
10 Spencer Dawkins
[Ballot comment]


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


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.



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!
2015-01-04
10 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-01-04
10 Stephen Farrell
[Ballot discuss]

I have two points to discuss. Hopefully, they should
be fairly easily resolved though there may be a bit
of work needed.

(1) …
[Ballot discuss]

I have two points to discuss. Hopefully, they should
be fairly easily resolved though there may be a bit
of work needed.

(1) The secdir review [1] I think does a good job of
identifying some real security issues that will emerege
and that are a consequence of the three bits of
architecture described here. Inclusion of some
variation of the 4 bullets from [1] would be at least a
good start in improving what is clearly an deficient
security considerations section (as Adrian correctly
said). I think that plus some text about other fairly
obvious issues (e.g. slow middlebox s/w update has
prevented applying some patches or slowed down
deployment of new security features, recognising the
tension between SFC and privacy/confidentiality,...)
should be fairly easily done with a little work from
someone.

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

(2) The IAB have encouraged us to encrypt everything
and that, and RFC 7258, would seem to me to be very
much in tension with some aspects of this work. And the
WG charter says "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." I see no real evidence
that that has happened so far from this particular
deliverable so my question is: when will you tackle the
security and privacy considerations and the obvious
tension between doing more inside the n/w vs.
protecting users and applications? Also - don't you
consider that DoS attacks are a problem that could be
mitigated or made worse via SFC?  And isn't it clear
that privacy could easily be made worse if SFC is
developed without real consideration of privacy
trade-offs? Resolving this discuss point would ideally
be done by someone pointing me at WG drafts that do
substantively address these issues. (I've not looked,
so it's quite possible that will be done, and if so,
great.) If that is not currently possible, then we
should probably talk some more about when and how that
work is going to happen.  (Translating that last bit:
I'm not trying to insist that the security and privacy
work needed for SFC be finished already, but I'd like
to be confident that it will happen, so this DISCUSS is
perhaps more for chatting with the AD and WG chairs
rather than the authors of this deliverable.)
2015-01-04
10 Stephen Farrell
[Ballot comment]


- There are no IPR declarations on this directly
visible from the agenda (I've seen and reported another
bug near there today, not …
[Ballot comment]


- There are no IPR declarations on this directly
visible from the agenda (I've seen and reported another
bug near there today, not sure if this is related) but
there is one on this and there are two on a document
that this replaces, with one (#2285) being RAND with
possible royalty/fee. And the other (#2304) gets me a
404 in the DB while the link is to #2307. I see the
write-up says the WG chairs figure that's ok, but it
only mentions 1 disclosure that it says caused some
concern. So this is just to check all's well, given the
confusing nature of the above. (Possibly the confusion
is just caused by a short-lived tracker bug.)

- 1.1, RFC6967 is referenced as if it were a spec for
HOST_ID. But it is not. HOST_ID remains highly
controversial and using it as an example here is not a
good plan, as that might be used to claim that HOST_ID
has more acceptance than is the case. Simplest thing is
to just delete that. I'd also argue that HTTP header
"enrichment" has been shown to cause many
vulnerabilities so would also be better deleted.  And
it's noticeable that the examples given are all (or
almost all) ones that will be made harder by more
cryptography, which the IAB and RFC7258 tell us is
good. Don't you have non-invasive examples that
could be added?
2015-01-04
10 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-01-03
10 Joel Jaeggli
[Ballot comment]
2.3.  Constrained High Availability

  An effect of topological dependency is constrained service function
  high availability.  Worse, when modified, inadvertent non-high
  …
[Ballot comment]
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.
2015-01-03
10 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-12-28
10 Adrian Farrel
[Ballot 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 …
[Ballot 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
2014-12-28
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-12-25
10 Alia Atlas Ballot has been issued
2014-12-25
10 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2014-12-25
10 Alia Atlas Created "Approve" ballot
2014-12-25
10 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-12-18
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-12-18
10 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sfc-problem-statement-10, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sfc-problem-statement-10, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

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.
2014-12-18
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2014-12-18
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2014-12-15
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2014-12-15
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2014-12-11
10 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2014-12-11
10 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2014-12-11
10 Alia Atlas Changed consensus to Yes from Unknown
2014-12-11
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-12-11
10 Cindy Morgan
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 Problem Statement) …
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 Problem Statement) to Informational RFC


The IESG has received a request from the Service Function Chaining WG
(sfc) to consider the following document:
- 'Service Function Chaining Problem Statement'
  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 2014-12-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 provides an overview of the issues associated with the
  deployment of service functions (such as firewalls, load balancers)
  in large-scale environments.  The term service function chaining is
  used to describe the definition and instantiation of an ordered set
  of instances of such service functions, and the subsequent "steering"
  of traffic flows through those service functions.

  The set of enabled service function chains reflect operator service
  offerings and is designed in conjunction with application delivery
  and service and network policy.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ballot/


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

  http://datatracker.ietf.org/ipr/2285/



2014-12-11
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-12-11
10 Alia Atlas Ballot writeup was changed
2014-12-11
10 Alia Atlas Placed on agenda for telechat - 2015-01-08
2014-12-11
10 Alia Atlas Last call was requested
2014-12-11
10 Alia Atlas Last call announcement was generated
2014-12-11
10 Alia Atlas Ballot approval text was generated
2014-12-11
10 Alia Atlas Ballot writeup was generated
2014-12-11
10 Alia Atlas IESG state changed to Last Call Requested from Publication Requested
2014-08-12
10 Amy Vezza Notification list changed to : sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org, jmh@joelhalpern.com
2014-08-12
10 Jim Guichard
"Service Function Chaining Problem Statement" is the product of the
Service Function Chaining working group in the IETF Routing Area.  The
WG is chaired by …
"Service Function Chaining Problem Statement" is the product of the
Service Function Chaining working group 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.

From the abstract of the document:
This document provides an overview of the issues associated with the
deployment of service functions (such as firewalls, load balancers) in
large-scale environments.  The term service function chaining is used to
describe the definition and instantiation of an ordered set of instances
of such service functions, and the subsequent "steering" of traffic
flows through those service functions.

This document has been reviewed multiple times by many participants in
the working group.  Much of the content is widely supported, with
minimal controversy.  There has been some controversy around the content
of section 3, which describes at a very high level the components of a
service chaining solution.  The working group chairs have concluded that
the working group rough consensus is in favor of retaining that text in
this document.

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

There has been no formal review by outside experts, as this is an
informational problem statement and does not therefore need any
specified formal reviews.

The shepherd has observed that the wg has received confirmation from all
authors that all relevant IPR has been disclosed.  There is one IPR
disclosure which has caused the working group some concern.  The chairs
concluded that the WG had rough consensus to publish the document in the
presence of the IPR disclosure.
2014-08-12
10 Jim Guichard State Change Notice email list changed to sfc-chairs@tools.ietf.org, draft-ietf-sfc-problem-statement@tools.ietf.org
2014-08-12
10 Jim Guichard Responsible AD changed to Alia Atlas
2014-08-12
10 Jim Guichard IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-08-12
10 Jim Guichard IESG state changed to Publication Requested
2014-08-12
10 Jim Guichard IESG process started in state Publication Requested
2014-08-12
10 Jim Guichard Intended Status changed to Informational from None
2014-08-12
10 Jim Guichard Changed document writeup
2014-08-12
10 Jim Guichard Document shepherd changed to Joel M. Halpern
2014-08-11
10 Paul Quinn New version available: draft-ietf-sfc-problem-statement-10.txt
2014-08-08
09 Paul Quinn New version available: draft-ietf-sfc-problem-statement-09.txt
2014-08-04
08 Paul Quinn New version available: draft-ietf-sfc-problem-statement-08.txt
2014-06-24
07 Paul Quinn New version available: draft-ietf-sfc-problem-statement-07.txt
2014-06-09
06 Paul Quinn New version available: draft-ietf-sfc-problem-statement-06.txt
2014-04-17
05 Paul Quinn New version available: draft-ietf-sfc-problem-statement-05.txt
2014-04-16
04 Paul Quinn New version available: draft-ietf-sfc-problem-statement-04.txt
2014-04-01
03 Paul Quinn New version available: draft-ietf-sfc-problem-statement-03.txt
2014-02-14
02 Paul Quinn New version available: draft-ietf-sfc-problem-statement-02.txt
2014-02-14
01 Paul Quinn New version available: draft-ietf-sfc-problem-statement-01.txt
2014-01-29
00 Paul Quinn New version available: draft-ietf-sfc-problem-statement-00.txt