On Thu, Jul 25, 2013 at 12:58 AM, Thomas Narten <[email protected]> wrote:
> > 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. > [Lizhong] I hope to see less dataplane approach to be standardized. The IETF WG should try its best to have one standardization solution, there are many examples, e.g, MPLS-TP OAM. Regards Lizhong > > 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
