< draft-ietf-nvo3-encap-01.txt   draft-ietf-nvo3-encap-02.txt >
INTERNET-DRAFT Sami Boutros(Ed.) INTERNET-DRAFT Sami Boutros(Ed.)
Intended Status: Informational VMware Intended Status: Informational VMware
Ilango Ganga Expires: March 18, 2019 September 14, 2018
Intel
Pankaj Garg
Microsoft
Rajeev Manur
Broadcom
Tal Mizrahi
Marvell
David Mozes
Erik Nordmark
Michael Smith
Cisco
Sam Aldrin
Google
Ignas Bagdonas
Equinix
Expires: April 27, 2018 October 24, 2017
NVO3 Encapsulation Considerations NVO3 Encapsulation Considerations
draft-ietf-nvo3-encap-01 draft-ietf-nvo3-encap-02
Abstract Abstract
As communicated by WG Chairs, the IETF NVO3 chairs and Routing Area As communicated by WG Chairs, the IETF NVO3 chairs and Routing Area
director have chartered a design team to take forward the director have chartered a design team to take forward the
encapsulation discussion and see if there is potential to design a encapsulation discussion and see if there is potential to design a
common encapsulation that addresses the various technical concerns. common encapsulation that addresses the various technical concerns.
There are implications of different encapsulations in real There are implications of different encapsulations in real
environments consisting of both software and hardware implementations environments consisting of both software and hardware implementations
skipping to change at page 2, line 25 skipping to change at page 2, line 4
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 2, line 45
6.2.1. Telemetry extensions. . . . . . . . . . . . . . . . . . 6 6.2.1. Telemetry extensions. . . . . . . . . . . . . . . . . . 6
6.2.2. Security/Integrity extensions . . . . . . . . . . . . . 7 6.2.2. Security/Integrity extensions . . . . . . . . . . . . . 7
6.2.3. Group Base Policy . . . . . . . . . . . . . . . . . . . 7 6.2.3. Group Base Policy . . . . . . . . . . . . . . . . . . . 7
6.3 Hardware Considerations . . . . . . . . . . . . . . . . . . 7 6.3 Hardware Considerations . . . . . . . . . . . . . . . . . . 7
6.4 Extension Size . . . . . . . . . . . . . . . . . . . . . . . 8 6.4 Extension Size . . . . . . . . . . . . . . . . . . . . . . . 8
6.5 Extension Ordering . . . . . . . . . . . . . . . . . . . . . 9 6.5 Extension Ordering . . . . . . . . . . . . . . . . . . . . . 9
6.6 TLV vs Bit Fields . . . . . . . . . . . . . . . . . . . . . 9 6.6 TLV vs Bit Fields . . . . . . . . . . . . . . . . . . . . . 9
6.7 Control Plane Considerations . . . . . . . . . . . . . . . . 10 6.7 Control Plane Considerations . . . . . . . . . . . . . . . . 10
6.8 Split NVE . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.8 Split NVE . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.9 Larger VNI Considerations . . . . . . . . . . . . . . . . . 11 6.9 Larger VNI Considerations . . . . . . . . . . . . . . . . . 11
6.10 NAT traversal Considerations . . . . . . . . . . . . . . . 11
7. Design team recommendations . . . . . . . . . . . . . . . . . . 11 7. Design team recommendations . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1 Normative References . . . . . . . . . . . . . . . . . . . 14 10.1 Normative References . . . . . . . . . . . . . . . . . . . 14
10.2 Informative References . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . 15
11. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 15
11.2.1. Native Extensibility Support . . . . . . . . . . . . 15 11.2.1. Native Extensibility Support . . . . . . . . . . . . 15
skipping to change at page 11, line 45 skipping to change at page 11, line 45
identify the EVPN L2 instance. identify the EVPN L2 instance.
6.9 Larger VNI Considerations 6.9 Larger VNI Considerations
We discussed whether we should make VNI 32-bits or larger. The We discussed whether we should make VNI 32-bits or larger. The
benefit of 24-bit VNI would be to avoid unnecessary changes with benefit of 24-bit VNI would be to avoid unnecessary changes with
existing proposals and implementations that are almost all, if not existing proposals and implementations that are almost all, if not
all, are using 24-bit VNI. If we need a larger VNI, an extension can all, are using 24-bit VNI. If we need a larger VNI, an extension can
be used to support that. be used to support that.
6.10 NAT traversal Considerations TBD
7. Design team recommendations 7. Design team recommendations
We concluded that Geneve is most suitable as a starting point for We concluded that Geneve is most suitable as a starting point for
proposed standard for network virtualization, for the following proposed standard for network virtualization, for the following
reasons: reasons:
1. We studied whether VNI should be in base header or in extensions 1. We studied whether VNI should be in base header or in extensions
and whether it should be 24-bit or 32-bit. The design team agreed and whether it should be 24-bit or 32-bit. The design team agreed
that VNI is critical information for network virtualization and MUST that VNI is critical information for network virtualization and MUST
be present in all packets. Design team also agreed that 24-bit VNI be present in all packets. Design team also agreed that 24-bit VNI
 End of changes. 6 change blocks. 
32 lines changed or deleted 3 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/