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 |