Framework for Data Center (DC) Network Virtualization
draft-ietf-nvo3-framework-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-09-30
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-09-02
|
09 | Alia Atlas | Changed consensus to Yes from Unknown |
2014-09-01
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-08-27
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-07-25
|
09 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. |
2014-07-09
|
09 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-07-09
|
09 | (System) | RFC Editor state changed to EDIT |
2014-07-09
|
09 | (System) | Announcement was received by RFC Editor |
2014-07-08
|
09 | (System) | IANA Action state changed to No IC |
2014-07-08
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2014-07-08
|
09 | Cindy Morgan | IESG has approved the document |
2014-07-08
|
09 | Cindy Morgan | Closed "Approve" ballot |
2014-07-08
|
09 | Cindy Morgan | Ballot approval text was generated |
2014-07-08
|
09 | Cindy Morgan | Ballot writeup was changed |
2014-07-08
|
09 | Alissa Cooper | [Ballot comment] Thanks for accommodating my discuss and comment points. |
2014-07-08
|
09 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2014-07-04
|
09 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-09.txt |
2014-07-02
|
08 | Kathleen Moriarty | [Ballot comment] Thank you for addressing my prior discusses, the security section provides a much better overview now and will hopefully help subsequent drafts from … [Ballot comment] Thank you for addressing my prior discusses, the security section provides a much better overview now and will hopefully help subsequent drafts from NVO3. I appreciate the effort that went into these edits. Now addressed: 1. The Security Considerations section hint around the risk of breaking the intended isolation of tenants without ever stating that possibility in the first few sections that describe securing NVEs, NVAs, and management systems. The risks should be explained so that the reader, including developers and implementers, understand that breaking the designed tenant isolation is possible when security requirements and considerations are not met (or there are weaknesses/flaws in software). This may help to further motivate implementation of security requirements. 2. The framework describes both overlay and underlay networks. When responding to Alissa's discuss, I would like like to see the text address when encryption is needed with the associated risks for the overlay and underlay networks as well, the answers may be different for each. The security considerations section goes back and forth between the two right now without always calling out which it is referring to and this would be helpful. This is also the case for the unauthorized access descriptions in the security considerations section. I'm adding this as a second discuss to make sure we can work through some text to add and these considerations are included as I think they will be helpful to address what each means for both overlay and underlay networks (management/control data and tenant data). Not yet addressed: For Alissa's comment, it would be good to include the reference intended in the draft for opportunistic encryption to avoid confusion. |
2014-07-02
|
08 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2014-07-02
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-07-02
|
08 | Marc Lasserre | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-07-02
|
08 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-08.txt |
2014-06-19
|
07 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2014-06-12
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-06-12
|
07 | Benoît Claise | [Ballot comment] This is combined feedback from the OPS DIR review (Thanks Al Morton) and my own review. I like the document and in particular … [Ballot comment] This is combined feedback from the OPS DIR review (Thanks Al Morton) and my own review. I like the document and in particular section 4 about "Key aspects of overlay networks" - Thanks for section 2.4. Operational Management Considerations, but I share Al Morton's views (OPS-DIR review) on this section ... As far as the IP underlay is concerned, existing IP OAM facilities are used. So, a clear mapping between overlay and underlay addresses is needed by the person or entity directing OAM activities, right? It appears section 3.1.5.3 discusses this to some degree. Section 3.3 on VM Mobility adds to the complexity of performing meaningful OAM. Maybe I expect too much from this document and this is/will be covered in draft-ashwood-nvo3-oam-requirements? . . . As far as configuration is concerned, the DC environment is driven by the need to bring new services up rapidly and is typically very dynamic specifically in the context of virtualized services. It is therefore critical to automate the configuration of NVO3 services. This last sentence sounds like a requirement, but automation does not appear to be addressed very extensively in the draft, except that VNI values are automatically generated by the egress NVE, and there are a few others. - 4.1. Pros & Cons The Cons and other issues raised in section 4 are potential pitfalls for operations, and this could be noted. In particular, sections 4.2.5 and 4.2.6 point to difficulties of VM placement and the lack of interaction between network layers when coordination is needed in critical areas. For example, with many specific examples provided in the previous sections, how do the authors recommend to provision bandwidth in the IP network for each, ideally performance-isolated, VNI? EDITORIAL: - ... to provide similar functions to a ToR. ... Another example is the case where the End Device is the Tenant System, and the NVE function can be implemented by the connected ToR ... ToR => ToR switch There are multiple instances of this. - Having figure 3 and section 3 would help readability. - Some more comments, more editorial, from Al Morton Although I don't request a change in terminology, I found the term "underlay" to be distracting as a non-indoctrinated reader. Further, Figure 3 doesn't identify the underlay network, but it depicts the L3 Network (IP underlay) above the "Overlay" network and therefore the figure is drawn upside-down. I think "foundation" would be a more easily understood term for some readers, but the Figure should identify the underlay network and be re-drawn for clarity, at least. Perhaps some of the difficulty with the underlay network concept is the alternate reference to either IP networks or L3 networks/ technologies: . . . In the case of NVO3, the underlay network is IP. ... Underlay nodes utilize L3 technologies to interconnect NVE nodes. These nodes perform forwarding based on outer L3 header information, It's hard to maintain clarity with numbered-layers in the face of overlays, underlays, tunneling, VPNs (but here L* is embedded in the names), etc., but can't solve the whole problem here. |
2014-06-12
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-06-12
|
07 | Joel Jaeggli | [Ballot comment] can you find something other than BUM? |
2014-06-12
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-06-12
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-06-12
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-06-11
|
07 | Kathleen Moriarty | [Ballot discuss] The overview is very good for NVO3, but I think it could benefit from some additional information in the security considerations and would … [Ballot discuss] The overview is very good for NVO3, but I think it could benefit from some additional information in the security considerations and would like to discuss that with a couple of concerns. 1. The Security Considerations section hint around the risk of breaking the intended isolation of tenants without ever stating that possibility in the first few sections that describe securing NVEs, NVAs, and management systems. The risks should be explained so that the reader, including developers and implementers, understand that breaking the designed tenant isolation is possible when security requirements and considerations are not met (or there are weaknesses/flaws in software). This may help to further motivate implementation of security requirements. 2. The framework describes both overlay and underlay networks. When responding to Alissa's discuss, I would like like to see the text address when encryption is needed with the associated risks for the overlay and underlay networks as well, the answers may be different for each. The security considerations section goes back and forth between the two right now without always calling out which it is referring to and this would be helpful. This is also the case for the unauthorized access descriptions in the security considerations section. I'm adding this as a second discuss to make sure we can work through some text to add and these considerations are included as I think they will be helpful to address what each means for both overlay and underlay networks (management/control data and tenant data). |
2014-06-11
|
07 | Kathleen Moriarty | [Ballot comment] I fully support Alissa's DISCUSS and comment. For the discuss, it would be helpful to see her questions addressed rather than just changing … [Ballot comment] I fully support Alissa's DISCUSS and comment. For the discuss, it would be helpful to see her questions addressed rather than just changing may to must. I agree with her list of questions and would like to see this further elaborated on in the draft. For her comment, it would be good to include the reference intended in the draft for opportunistic encryption to avoid confusion. |
2014-06-11
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2014-06-11
|
07 | Adrian Farrel | [Ballot comment] Thanks for this document. I know it represents a lot of effort. The document is very clear and a good read. I have … [Ballot comment] Thanks for this document. I know it represents a lot of effort. The document is very clear and a good read. I have just a few minor points for you to consider as you progress the document. ---- Tiny ambiguity... Virtual Network (VN): A VN is a logical abstraction of a physical network that provides L2 or L3 network services to a set of Tenant Systems. It is the VN or the physical network that provides the L2 or L3 services? --- You have... The Underlay Network does not need to be aware that it is carrying NVO3 packets. I wondered whether you wanted to make a stronger statement here. We usually have a stronger separation of overlay and underlay such that The Underlay Network is not aware that it is carrying NVO3 packets. --- Possibly "NIC card" is tautology. --- Format of Figure 3 is a bit messed up --- The use of "seamless" in Section 3.3 seems a bit or an overstatement or perhaps just under-defined. Given the text that follows, I would just delete "in a seamless manner" from the first paragraph. |
2014-06-11
|
07 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-06-11
|
07 | Alissa Cooper | [Ballot discuss] I note that the security ADs have not balloted on this document yet, so they may have better/different ideas about the two points … [Ballot discuss] I note that the security ADs have not balloted on this document yet, so they may have better/different ideas about the two points below. Section 5: "When NVO3 data traverses untrusted networks, data encryption may be needed." As written, this is sort of a truism and seems a little weak. Under what circumstances would it be advisable to transfer NVO3 data unencrypted across untrusted networks? Seems like those need to be fleshed out here, or otherwise the recommendation should be for encryption to be used when sending data on untrusted networks. |
2014-06-11
|
07 | Alissa Cooper | [Ballot comment] Section 3.1.4: "When confidentiality is required, the use of opportunistic encryption can be used as a stateless tunneling … [Ballot comment] Section 3.1.4: "When confidentiality is required, the use of opportunistic encryption can be used as a stateless tunneling solution." Since there is active debate about "opportunistic" terminology, just wanted to check if this is meant as "opportunistic encryption" in the RFC4322 sense, or something else (e.g., "opportunistic security" [http://tools.ietf.org/html/draft-kent-opportunistic-security-01][http://www.ietf.org/mail-archive/web/saag/current/msg04932.html]). |
2014-06-11
|
07 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2014-06-11
|
07 | Alia Atlas | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is appropriate as the draft describes a framework for providing multi-tenancy in large data centers. It does not specify new protocols, but rather provides the overall framework, including functional reference models, in which existing or new protocols would operate in a multi-tenant data center, together with defining some required terminology. The intended status is properly indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a framework for Network Virtualization over L3 (NVO3) and it defines a reference model along with logical components required to design a solution. Working Group Summary The document is one of the base documents chartered for the NVO3 working group. The first version of the draft was introduced at the time of the WG forming BoF for NVO3, as a way to provide network architecture context to the design of a multi-tenant data centre, for example in defining the terminology and functional blocks that are required. There has been nothing unusual or particularly controversial about the working group process for the draft. There are no IPR declarations on the draft. Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list since formation of the NVO3 working group. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com). The responsible Area Director is Alia Atlas (akatlas+iesg@gmail.com). (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed v04 of the document. I had no significant technical comments, but I did make some editorial comments that have been resolved in the latest version (v05). (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has been developed within the WG and reviewed over a period of a number of IETFs, as well as being a major focus of the BoF that led to the creation of the NVO3 working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No further review required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each author listed in the Authors Addresses section has personally indicated that they are not aware of any IPR that has not already been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It has been discussed over a long period , both in face to face IETF meetings and on the list. It received a number of comments in WG last call that were addressed by the authors. Some comments were related to the detailed architecture and would be more appropriate to address in an architecture draft that is currently being developed by the NVO3 Working group. There were a number of comments on the draft during IETF last call. These included an objection to examples of particular loop removal techniques, that might infer specific solutions or interpreted to rule out other solutions. These were removed from the draft and I believe this new text reflects the consensus of the discussion. There was also a comment related to the inclusion of an inter-virtual network gateway function in the NVO3 reference model. There was some debate as to whether this is a special type of Network Virtualization Edge (NVE). Note that a similar discussion has occurred within the NVO3 working group in October 2013, and this resulted in text describing gateways added to the draft-ietf-nvo3-arch-01. The consensus was that the separate NVO3 architecture draft would be a better place for detailing such functional components. The framework draft was therefore not updated to include and further details of an inter-VN gateway function. I am comfortable that this outcome is in line with previous consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None indicated. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID-Nits passes. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. All references are explicitly identified as informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. All references are informative. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no IANA actions. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections containing formal language that needs reviewing. |
2014-06-11
|
07 | Alia Atlas | [Ballot comment] The WG chair and Shepherd need to show IETF consensus on the draft. Many of the comments made in IETF last call were … [Ballot comment] The WG chair and Shepherd need to show IETF consensus on the draft. Many of the comments made in IETF last call were addressed and others may be duplicating what was discussed in the WG - but that needs to be clearly articulated in the Shepherd's report. Matthew is updating the Shepherd's report to indicate how the IETF last call input was considered. |
2014-06-11
|
07 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to Yes from Discuss |
2014-06-11
|
07 | Martin Stiemerling | [Ballot comment] Thanks for Section 4.2 and especially 4.2.4 and 4.2.6. Good to have the discussions about the challenges! |
2014-06-11
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-06-10
|
07 | Alia Atlas | [Ballot discuss] The WG chair and Shepherd need to show IETF consensus on the draft. Many of the comments made in IETF last call were … [Ballot discuss] The WG chair and Shepherd need to show IETF consensus on the draft. Many of the comments made in IETF last call were addressed and others may be duplicating what was discussed in the WG - but that needs to be clearly articulated in the Shepherd's report. |
2014-06-10
|
07 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to Discuss from Yes |
2014-06-10
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-06-10
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-06-10
|
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-06-06
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Al Morton. |
2014-06-06
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2014-06-06
|
07 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-06-06
|
07 | Alia Atlas | Ballot has been issued |
2014-06-06
|
07 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-06-06
|
07 | Alia Atlas | Created "Approve" ballot |
2014-06-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2014-06-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2014-06-05
|
07 | Alia Atlas | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is appropriate as the draft describes a framework for providing multi-tenancy in large data centers. It does not specify new protocols, but rather provides the overall framework, including functional reference models, in which existing or new protocols would operate in a multi-tenant data center, together with defining some required terminology. The intended status is properly indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a framework for Network Virtualization over L3 (NVO3) and it defines a reference model along with logical components required to design a solution. Working Group Summary The document is one of the base documents chartered for the NVO3 working group. The first version of the draft was introduced at the time of the WG forming BoF for NVO3, as a way to provide network architecture context to the design of a multi-tenant data centre, for example in defining the terminology and functional blocks that are required. There has been nothing unusual or particularly controversial about the working group process for the draft. There are no IPR declarations on the draft. Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list since formation of the NVO3 working group. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com). The responsible Area Director is Alia Atlas (akatlas+iesg@gmail.com). (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed v04 of the document. I had no significant technical comments, but I did make some editorial comments that have been resolved in the latest version (v05). (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has been developed within the WG and reviewed over a period of a number of IETFs, as well as being a major focus of the BoF that led to the creation of the NVO3 working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No further review required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each author listed in the Authors Addresses section has personally indicated that they are not aware of any IPR that has not already been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It has been discussed over a long period , both in face to face IETF meetings and on the list. It received a number of comments in WG last call that were addressed by the authors. Some comments were related to the detailed architecture and would be more appropriate to address in an architecture draft that is currently being developed by the NVO3 Working group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None indicated. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID-Nits passes. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. All references are explicitly identified as informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. All references are informative. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no IANA actions. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections containing formal language that needs reviewing. |
2014-06-05
|
07 | Marc Lasserre | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-06-05
|
07 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-07.txt |
2014-06-04
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-05-28
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-05-28
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-nvo3-framework-06, 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-nvo3-framework-06, 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-05-26
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Morton |
2014-05-26
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Morton |
2014-05-22
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2014-05-22
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2014-05-22
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rob Austein |
2014-05-22
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rob Austein |
2014-05-21
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-05-21
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Framework for DC Network Virtualization) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Framework for DC Network Virtualization) to Informational RFC The IESG has received a request from the Network Virtualization Overlays WG (nvo3) to consider the following document: - 'Framework for DC Network Virtualization' 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-06-04. 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 a framework for Network Virtualization Overlays (NVO3) and it defines a reference model along with logical components required to design a solution. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-05-21
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-05-21
|
06 | Alia Atlas | Ballot writeup was changed |
2014-05-21
|
06 | Alia Atlas | Placed on agenda for telechat - 2014-06-12 |
2014-05-21
|
06 | Alia Atlas | Last call was requested |
2014-05-21
|
06 | Alia Atlas | Last call announcement was generated |
2014-05-21
|
06 | Alia Atlas | Ballot approval text was generated |
2014-05-21
|
06 | Alia Atlas | Ballot writeup was generated |
2014-05-21
|
06 | Alia Atlas | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-05-21
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-05-21
|
06 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-06.txt |
2014-03-19
|
05 | Alia Atlas | Alia's AD review comments: In general, this is a well written document. I have a few questions about some of the differences in functionality or … Alia's AD review comments: In general, this is a well written document. I have a few questions about some of the differences in functionality or assumptions between this and the nvo3-problem-statement. I agree with Stewart about the need for operational management requirements. I would also like to see a bit more thought given to security - particularly around addressing concerns such as anti-snooping and confidentiality. More detailed comments follow: 1) In Sec 2.1: " It is also possible for NVEs to communicate with an external Network Virtualization Authority (NVA) to obtain reachability and forwarding information. In this case, a protocol is used between NVEs and NVA(s) to exchange information. OpenFlow [OF] is one example of such a protocol." Can you please explain how OpenFlow is being used to do this? From looking at the referenced spec, I do not see it. Certainly, OpenFlow can be used for a switch to send packets with unrecognized addresses up to the controller to be processed. This seems like quite a reach to claim that is what OpenFlow is doing. I do not see the rationale for mentioning this particular protocol here. 2) In Sec 2.2: NVE hub and NVE spoke appear for the first and only time. "For instance, an End Device can act as an NVE Spoke, while an access switch can act as an NVE hub." Can you please expand on what is meant in the draft? What functionality would be in an NVE spoke and what in an NVE hub? 3) In Sec 3.1.3, one option is "One VN Context identifier per Tenant". How does this satisfy the problem statement that says "Hence, there is a one-to-many mapping between tenants and virtual network instances." Additionally, in Sec 3.1.3, the concept of globally unique vs. local seems to be mixed up with the ideas of per-tenant, per-VNI, and per-VAP. I'd like to see some text that clarifies why this coupling exists? Presumably, it isn't impossible to satisfy the problem-statement's need for one-to-many using globally unique values?? If it is, I'd certainly want to see that clearly articulated with reasons. 4) In Sec. 3.1.4, have you considered the possibility and advantages of opportunistic encryption to support a stateless tunneling approach? Are any tunneling mechanisms with confidentiality considered beyond IPSec? Instead of ruling out stateful tunneling approaches, can you decouple the management considerations (say your centralized controller can specify the configuration in a rapid fashion) from the scaling considerations from other pros/cons for stateless versus stateful? I'm particularly concerned because the only tunneling mechanism with confidentiality that is mentioned is IPsec which is stateful. In looking at the Security considerations in the problem-statement, it says "In addition to isolation, assurances against spoofing, snooping, transit modification and denial of service are examples of other important data plane considerations. Some limited environments may even require confidentiality." |
2014-03-05
|
05 | Cindy Morgan | Shepherding AD changed to Alia Atlas |
2014-02-11
|
05 | Stewart Bryant | This surely needs a sections on operational management |
2014-02-11
|
05 | Stewart Bryant | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2014-01-28
|
05 | Matthew Bocci | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is appropriate as the draft describes a framework for providing multi-tenancy in large data centers. It does not specify new protocols, but rather provides the overall framework, including functional reference models, in which existing or new protocols would operate in a multi-tenant data center, together with defining some required terminology. The intended status is properly indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a framework for Network Virtualization over L3 (NVO3) and it defines a reference model along with logical components required to design a solution. Working Group Summary The document is one of the base documents chartered for the NVO3 working group. The first version of the draft was introduced at the time of the WG forming BoF for NVO3, as a way to provide network architecture context to the design of a multi-tenant data centre, for example in defining the terminology and functional blocks that are required. There has been nothing unusual or particularly controversial about the working group process for the draft. There are no IPR declarations on the draft. Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list since formation of the NVO3 working group. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com). The responsible Area Director is Stewart Bryant (stbryant@cisco.com). (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed v04 of the document. I had no significant technical comments, but I did make some editorial comments that have been resolved in the latest version (v05). (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has been developed within the WG and reviewed over a period of a number of IETFs, as well as being a major focus of the BoF that led to the creation of the NVO3 working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No further review required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each author listed in the Authors Addresses section has personally indicated that they are not aware of any IPR that has not already been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It has been discussed over a long period , both in face to face IETF meetings and on the list. It received a number of comments in WG last call that were addressed by the authors. Some comments were related to the detailed architecture and would be more appropriate to address in an architecture draft that is currently being developed by the NVO3 Working group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None indicated. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID-Nits passes. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. All references are explicitly identified as informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. All references are informative. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no IANA actions. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections containing formal language that needs reviewing. |
2014-01-28
|
05 | Matthew Bocci | IETF WG state changed to Submitted to IESG for Publication |
2014-01-28
|
05 | Matthew Bocci | IESG state changed to Publication Requested |
2014-01-28
|
05 | Matthew Bocci | State Change Notice email list changed to nvo3-chairs@tools.ietf.org, draft-ietf-nvo3-framework@tools.ietf.org |
2014-01-28
|
05 | Matthew Bocci | Responsible AD changed to Stewart Bryant |
2014-01-28
|
05 | Matthew Bocci | Working group state set to Submitted to IESG for Publication |
2014-01-28
|
05 | Matthew Bocci | IESG state set to Publication Requested |
2014-01-28
|
05 | Matthew Bocci | IESG process started in state Publication Requested |
2014-01-28
|
05 | Matthew Bocci | Changed document writeup |
2014-01-28
|
05 | Matthew Bocci | Intended Status changed to Informational from None |
2014-01-20
|
05 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-05.txt |
2013-12-02
|
04 | Matthew Bocci | Document shepherd changed to Matthew Bocci |
2013-11-12
|
04 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-04.txt |
2013-07-04
|
03 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-03.txt |
2013-02-14
|
02 | Benson Schliesser | Changed shepherd to Benson Schliesser |
2013-02-04
|
02 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-02.txt |
2012-10-19
|
01 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-01.txt |
2012-09-11
|
00 | Marc Lasserre | New version available: draft-ietf-nvo3-framework-00.txt |