Skip to main content

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