Skip to main content

Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
draft-ietf-nvo3-rfc7348bis-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nvo3-rfc7348bis@ietf.org, gunter@vandevelde.cc, matthew.bocci@nokia.com, nvo3-chairs@ietf.org, nvo3@ietf.org, rfc-editor@rfc-editor.org
Subject: Document Action: 'Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks' to Informational RFC (draft-ietf-nvo3-rfc7348bis-11.txt)

The IESG has approved the following document:
- 'Virtual eXtensible Local Area Network (VXLAN): A Framework for
   Overlaying Virtualized Layer 2 Networks over Layer 3 Networks'
  (draft-ietf-nvo3-rfc7348bis-11.txt) as Informational RFC

This document is the product of the Network Virtualization Overlays Working
Group.

The IESG contact persons are Gunter Van de Velde, Jim Guichard and Ketan
Talaulikar.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-rfc7348bis/


Ballot Text

Technical Summary

   This document specifies Virtual eXtensible Local Area Network
   (VXLAN), which is used to address the need for overlay networks
   within virtualized data centers accommodating multiple tenants.  The
   scheme and the related protocols can be used in networks for cloud
   service providers and enterprise data centers.  This document
   obsoletes RFC 7348, which documented the deployed VXLAN protocol for
   the benefit of the Internet community, and moves the VXLAN
   specification to the IETF document stream, allowing for the creation
   of extensions to VXLAN that require additions to the VXLAN header and
   their registration with IANA.  The format and processing described
   here are fully compatible with those in RFC7348.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

The document achieved broad working group consensus. Multiple working group
participants reviewed the document during its development and Working Group
Last Call, and comments received during WGLC were addressed by the authors.
Support for publication was expressed by participants representing multiple
vendors and operators. The consensus was not limited to a small set of
contributors.
There were no significant controversies during working group review. Comments
received during review focused on clarification, editorial improvements, and
ensuring consistency with current deployment and implementation practices.
Consensus on the final document was straightforward and did not require any
particularly rough consensus calls.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

The document updates an existing specification that has been widely
implemented and deployed. Implementations of the underlying technology exist
from multiple vendors and in open-source software.

Personnel

   The Document Shepherd for this document is Matthew Bocci. The
   Responsible Area Director is Gunter Van de Velde.

IANA Note

  	IANA - Not OK
        (AD Note: authors reminded on 19 Aug 2026 to respond to IANA clarification question)

RFC Editor Note