Hi Eric, Thank you for sending this. Some comments in line.
On Tue, Oct 21, 2014 at 8:37 AM, Erik Nordmark <[email protected]> wrote: > > I expressed this on the phone at the interim meeting and was asked to post > with a bit more detail. > > According to the call the intended purpose of the requirements document is > to help the WG choose between different proposed dataplane encapsulation > protocols. However, I get the impression that > draft-ietf-nvo3-dataplane-requirements was not written with that purpose in > mind. > > To be clear, the document contains useful background text and various > discussion on what needs to be done at encapsulation and decapsulation > points either by an implementation or operationally. However, that does not > help with the (current) intended purpose. > > The actual requirements on encapsulation protocol are few and weak. Section > 3.3.1 contains a few of them. > But even the requirement on VNID is weak. The document says that there MUST > be a VNID, but then goes on to > > This field MAY be an > explicit, unique (to the administrative domain) virtual network > identifier (VNID) or MAY express the necessary context information > in other ways (e.g. a locally significant identifier). > > While in theory locally significant indentifiers can be made to work, they > would require an additional control-plane mechanism to handle the (dynamic?) > mapping between VNID and the local identifier. Especially with BGP EVPN now > being handled in the BESS WG, I think we should have a requirement for our > dataplane that it MUST contain a VNID field. > > That section also discusses QoS/CoS. But it's requirement is a MAY for a QoS > field in the NVO3 overlay header. Either we should require such a field or > not; otherwise this doesn't help us choose. > (And my personal take is that we can have solutions which map between TS > QoS/CoS and underlay CoS without also having some QoS field in the NVO3 > header. But my overall point is that the "MAY" isn't a helpful criteria to > choose between protocols.) > > > Those are the only "requirements" on the dataplane I've found in the > document. > > There might be other required or desired properties that are not in the > draft. For instance, one can contemplate a requirement that the > encapsulation MUST/SHOULD facilitate ECMP in unmodified routers in the > underlay (e.g., using the common technique of UDP encaps with entropy placed > in the UDP source port field). > > Thus my take is that a document with requirements on the NVO3 dataplane > encapsulation can be a page or two. Some introduction and background > followed by a list of required and desired properties of the encapsulation > format such as: Agreed, but I think there are a few more probably. > - MUST contain an VNID field. This field MUST be large enough to scale to > 100's of thousands of virtual networks In even moderate sized deployments hierarchical assignment of VNIDs, sub-VNs, fragmentation in the space, classed VNIDs might be used-- this probably should be reflected in requirements to allow for that (I have pointed this out previously). I believe the bigger item missing around VNID is security. Isolation between VNs isolation is a critical requirement, so it follows that the VNID must be adequately secured to protect against spoofing or corruption. > - ??? QoS field inside the NVO3 overlay header or not ??? I would add that a congestion control mechanism in the encapsulation layer might also be considered. > - MUST/SHOULD facilitate ECMP in unmodified routers in the underlay Is it reasonable to require UDP based encapsulation to support this, or at least that any protocol can easily be encapsulated within UDP (like being done for GRE/UDP)? > (Others participants might have other requirements on the encapsulation > format. My main message is the focus on the encaps requirements which seems > to be quite few.) With respect to encapsulation protocol requirements, I would propose that extensibility (ability to associate meta data with the encapsulation) is also a requirement. > The implementation and operational requirements in > draft-ietf-nvo3-dataplane-requirements should IMHO belong in a different > document. Some might already be covered in the architecture document. And > others might need to be refined as we specify more details for the NVO3 > solution. > One other thing that should be clarified: The protocol of the encapsulated packet is described in the req. draft as "Tenant frame: Ethernet or IP based upon the VNI type". This is a requirement for a multi-protocol encapsulation which is good, but seems restrictive in the protocols carried and implies that protocol is inferred from VNID as opposed the to requiring/allowing the encapsulation layer to have a protocol field. Thanks, Tom > Hence if we are going to get WG consensus on a dataplane encapsulation > requirements document I strongly suggest we start small with the above (3, > give or take) bullets being the actual content. > > Erik > > > Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away. Antoine de Saint-Exupery > French writer (1900 - 1944) > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
