An Architecture for Overlay Networks (NVO3)
draft-ietf-nvo3-arch-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8014.
|
|
---|---|---|---|
Authors | David L. Black , Jon Hudson , Larry Kreeger , Marc Lasserre , Dr. Thomas Narten | ||
Last updated | 2014-10-27 | ||
Replaces | draft-narten-nvo3-arch | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | Benson Schliesser | ||
IESG | IESG state | Became RFC 8014 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | "Benson Schliesser" <bensons@queuefull.net> |
draft-ietf-nvo3-arch-02
Black, et al. Expires April 30, 2015 [Page 26] Internet-Draft Overlays for Network Virtualization October 2014 10. Control Protocol Work Areas The NVO3 architecture consists of two major distinct entities: NVEs and NVAs. In order to provide isolation and independence between these two entities, the NVO3 architecture calls for well defined protocols for interfacing between them. For an individual NVA, the architecture calls for a logically centralized entity that could be implemented in a distributed or replicated fashion. While the IETF may choose to define one or more specific architectural approaches to building individual NVAs, there is little need for it to pick exactly one approach to the exclusion of others. An NVA for a single domain will likely be deployed as a single vendor product and thus their is little benefit in standardizing the internal structure of an NVA. Individual NVAs peer with each other in a federated manner. The NVO3 architecture calls for a well-defined interface between NVAs. Finally, a hypervisor-to-NVE protocol is needed to cover the split- NVE scenario described in Section 4.2. 11. NVO3 Data Plane Encapsulation When tunneling tenant traffic, NVEs add encapsulation header to the original tenant packet. The exact encapsulation to use for NVO3 does not seem to be critical. The main requirement is that the encapsulation support a Context ID of sufficient size [I-D.ietf-nvo3-dataplane-requirements]. A number of encapsulations already exist that provide a VN Context of sufficient size for NVO3. For example, VXLAN [RFC7348] has a 24-bit VXLAN Network Identifier (VNI). NVGRE [I-D.sridharan-virtualization-nvgre] has a 24-bit Tenant Network ID (TNI). MPLS-over-GRE provides a 20-bit label field. While there is widespread recognition that a 12-bit VN Context would be too small (only 4096 distinct values), it is generally agreed that 20 bits (1 million distinct values) and 24 bits (16.8 million distinct values) are sufficient for a wide variety of deployment scenarios. 12. Operations and Management The simplicity of operating and debugging overlay networks will be critical for successful deployment. Some architectural choices can facilitate or hinder OAM. Related OAM drafts include [I-D.ashwood-nvo3-operational-requirement]. Black, et al. Expires April 30, 2015 [Page 27] Internet-Draft Overlays for Network Virtualization October 2014 13. Summary This document presents the overall architecture for overlays in NVO3. The architecture calls for three main areas of protocol work: 1. A hypervisor-to-NVE protocol to support Split NVEs as discussed in Section 4.2. 2. An NVE to NVA protocol for disseminating VN information (e.g., inner to outer address mappings). 3. An NVA-to-NVA protocol for exchange of information about specific virtual networks between federated NVAs. It should be noted that existing protocols or extensions of existing protocols are applicable. 14. Acknowledgments Helpful comments and improvements to this document have come from Lizhong Jin, Anton Ivanov, Dennis (Xiaohong) Qin, Erik Smith, Ziye Yang and Lucy Yong. 15. IANA Considerations This memo includes no request to IANA. 16. Security Considerations Yep, kind of sparse. But we'll get there eventually. :-) 17. Informative References [I-D.ashwood-nvo3-operational-requirement] Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A., Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3 Operational Requirements", draft-ashwood-nvo3-operational- requirement-03 (work in progress), July 2013. [I-D.ietf-nvo3-dataplane-requirements] Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., and B. Khasnabish, "NVO3 Data Plane Requirements", draft- ietf-nvo3-dataplane-requirements-03 (work in progress), April 2014. Black, et al. Expires April 30, 2015 [Page 28] Internet-Draft Overlays for Network Virtualization October 2014 [I-D.ietf-nvo3-nve-nva-cp-req] Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network Virtualization NVE to NVA Control Protocol Requirements", draft-ietf-nvo3-nve-nva-cp-req-02 (work in progress), April 2014. [I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A., Wang, Y., Garg, P., Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan-virtualization-nvgre-06 (work in progress), October 2014. [IEEE-802.1Q] IEEE 802.1Q-2011, , "IEEE standard for local and metropolitan area networks: Media access control (MAC) bridges and virtual bridged local area networks,", August 2011. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014. [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, October 2014. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, October 2014. Black, et al. Expires April 30, 2015 [Page 29] Internet-Draft Overlays for Network Virtualization October 2014 Appendix A. Change Log A.1. Changes From draft-ietf-nvo3-arch-01 to -02 1. Minor editorial improvements after a close re-reading; references to problem statement and framework updated to point to recently- published RFCs. 2. Added text making it more clear that other virtualization approaches, including Linux Containers are intended to be fully supported in NVO3. A.2. Changes From draft-ietf-nvo3-arch-00 to -01 1. Miscellaneous text/section additions, including: * New section on VLAN tag Handling (Section 3.1.1). * New section on tenant VLAN handling in Split-NVE case (Section 4.2.1). * New section on TTL handling (Section 3.1.2). * New section on multi-homing of NVEs (Section 4.4). * 2 paragraphs new text describing L2/L3 Combined service (Section 3.1). * New section on VAPs (and error handling) (Section 4.5). * New section on ARP and ND handling (Section 5.5) * New section on NVE-to-NVE interactions (Section 6) 2. Editorial cleanups from careful review by Erik Smith, Ziye Yang. 3. Expanded text on Distributed Inter-VN Gateways. A.3. Changes From draft-narten-nvo3 to draft-ietf-nvo3 1. No changes between draft-narten-nvo3-arch-01 and draft-ietf-nvoe- arch-00. A.4. Changes From -00 to -01 (of draft-narten-nvo3-arch) 1. Editorial and clarity improvements. Black, et al. Expires April 30, 2015 [Page 30] Internet-Draft Overlays for Network Virtualization October 2014 2. Replaced "push vs. pull" section with section more focused on triggers where an event implies or triggers some action. 3. Clarified text on co-located NVE to show how offloading NVE functionality onto adapters is desirable. 4. Added new section on distributed gateways. 5. Expanded Section on NVA external interface, adding requirement for NVE to support multiple IP NVA addresses. Authors' Addresses David Black EMC Email: david.black@emc.com Jon Hudson Brocade 120 Holger Way San Jose, CA 95134 USA Email: jon.hudson@gmail.com Lawrence Kreeger Cisco Email: kreeger@cisco.com Marc Lasserre Alcatel-Lucent Email: marc.lasserre@alcatel-lucent.com Thomas Narten IBM Email: narten@us.ibm.com Black, et al. Expires April 30, 2015 [Page 31]