On 01/03/14 01:51, Tom Herbert wrote: > On Fri, Feb 28, 2014 at 3:24 PM, Sam Aldrin <[email protected]> wrote: >> Hi all, >> >> Read the draft but have few questions on the same line others have asked. >> >> - Is this draft intended for standardizing within NVo3 WG? The status >> indicates it as informational. Also it is good to have it as draft-nvo3...., >> if it is meant for NVo3 WG. >> - I fail to find good reasoning, in the current version of the draft, on why >> design of encap transport header should be closely associated with metadata >> OR closely tied together? Could you add more details to clarify? > The draft alludes to the general need for extensibility, but does not > provide any example uses, so maybe I can suggest one. We have a real > use case for an encapsulation protocol with security to allow > validation of the virtual network identifier. In their current for > vxlan and nvgre have no provisions for authenticating or integrity > check of vni, existing mechanisms in the network were not deemed > robust enough to guarantee integrity of vni and ensure strict > isolation between tenants. UDP checksum is not sufficient for this. We > need a mechanism to at least have enforce an unpredictable security > token, or possibly at stronger authentication using something like a > message digest. This is intrinsic to the encapsulation, we cannot > deploy network virtualization without this security, hence an > extensible protocol is desirable. Additionally, as the network scales, > new threats emerge, we may have need for further extensions to adapt. > All of this needs to be efficient and amenable to HW performance > optimizations. > >
Tom, you are describing the L2TPv3 cookie. http://tools.ietf.org/html/rfc3931#section-4.1.1 That has already been defined and standardized in 2005. As quite a few people said - we do not need to invent a new encapsulation for the goals of this draft or for the goals of NVO3 for that matter. This just proves the point. We can copy that option to VXLAN or NVGRE as an extension if we wish too. As far as metadata extensions - I believe there is an agreement that we should do it. Similarly there is a consensus that they should not be welded into the network header. That particular aspect of the design has no other function but to be a "mono-culture monopoly license". A. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
