> 4. section 12, why dataplane definition is not considered as the main area > of work?
Let me just quote the entirety of Section 12, and ask others in the WG to comment. My sense is that there is little reason to do any additional data plane work. There are existing data planes that are "good enough" and defining yet one more doesn't provide enough benefit. But this is something that the WG needs to make a decision on. >From the draft: > 10. 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 [I-D.mahalingam-dutt-dcops-vxlan] 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. > > [Note: the following paragraph is included for WG discussion. Future > versions of this document may omit this text.] > > While one might argue that a new encapsulation should be defined just > for NVO3, no compelling requirements for doing so have been > identified yet. Moreover, optimized implementations for existing > encapsulations are already starting to become available on the market > (i.e., in silicon). If the IETF were to define a new encapsulation > format, it would take at least 2 (and likely more) years before > optimized implementations of the new format would become available in > products. In addition, a new encapsulation format would not likely > displace existing formats, at least not for years. Thus, there seems > little reason to define a new encapsulation. However, it does make > sense for NVO3 to support multiple encapsulation formats, so as to > allow NVEs to use their preferred encapsulations when possible. This > implies that the address dissemination protocols must also include an > indication of supported encapsulations along with the address mapping > details. > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
