draft-ietf-nvo3-encap-00.txt   draft-ietf-nvo3-encap-01.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
Pankaj Garg Pankaj Garg
Microsoft Microsoft
Rajeev Manur Rajeev Manur
Broadcom Broadcom
Tal Mizrahi Tal Mizrahi
Marvell Marvell
David Mozes David Mozes
Mellanox
Erik Nordmark Erik Nordmark
Michael Smith Michael Smith
Cisco Cisco
Expires: December 9, 2017 June 7, 2017 Sam Aldrin
Google
Ignas Bagdonas
Equinix
Expires: April 27, 2018 October 24, 2017
NVO3 Encapsulation Considerations NVO3 Encapsulation Considerations
draft-ietf-nvo3-encap-00 draft-ietf-nvo3-encap-01
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 3, line 18 skipping to change at page 3, line 22
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
11.2.2. Extension Parsing . . . . . . . . . . . . . . . . . . 15 11.2.2. Extension Parsing . . . . . . . . . . . . . . . . . . 15
11.2.3. Critical Extensions . . . . . . . . . . . . . . . . . 16 11.2.3. Critical Extensions . . . . . . . . . . . . . . . . . 16
11.2.4. Maximal Header Length . . . . . . . . . . . . . . . . 16 11.2.4. Maximal Header Length . . . . . . . . . . . . . . . . 16
11.3. Encapsulation Header . . . . . . . . . . . . . . . . . . 16 11.3. Encapsulation Header . . . . . . . . . . . . . . . . . . 16
11.3.1. Virtual Network Identifier (VNI) . . . . . . . . . . 16 11.3.1. Virtual Network Identifier (VNI) . . . . . . . . . . 16
11.3.2. Next Protocol . . . . . . . . . . . . . . . . . . . . 16 11.3.2. Next Protocol . . . . . . . . . . . . . . . . . . . . 17
11.3.3. Other Header Fields . . . . . . . . . . . . . . . . . 17 11.3.3. Other Header Fields . . . . . . . . . . . . . . . . . 17
11.4. Comparison Summary . . . . . . . . . . . . . . . . . . . 17 11.4. Comparison Summary . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses (In alphabetical order) . . . . . . . . . . . . 18 Authors' Addresses (In alphabetical order) . . . . . . . . . . . . 18
1. Problem Statement 1. Problem Statement
As communicated by WG Chairs, the NVO3 WG charter states that it may As communicated by WG Chairs, the NVO3 WG charter states that it may
produce requirements for network virtualization data planes based on produce requirements for network virtualization data planes based on
encapsulation of virtual network traffic over an IP-based underlay encapsulation of virtual network traffic over an IP-based underlay
data plane. Such requirements should consider OAM and security. Based data plane. Such requirements should consider OAM and security. Based
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
skipping to change at page 19, line 15 skipping to change at page 19, line 17
Rajeev Manur Rajeev Manur
Broadcom Broadcom
Email: rajeev.manur@broadcom.com Email: rajeev.manur@broadcom.com
Tal Mizrahi Tal Mizrahi
Marvell Marvell
Email: talmi@marvell.com Email: talmi@marvell.com
David Mozes David Mozes
Mellanox Email: mosesster@gmail.com
Email: davidm@mellanox.com
Erik Nordmark Erik Nordmark
Arista Networks
Email: nordmark@sonic.net Email: nordmark@sonic.net
Michael Smith Michael Smith
Cisco Cisco
Email: michsmit@cisco.com Email: michsmit@cisco.com
Sam Aldrin Sam Aldrin
Google Google
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
 End of changes. 8 change blocks. 
7 lines changed or deleted 13 lines changed or added

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