Hello all, Please find comments in-line.
-hao 发件人: nvo3 [mailto:[email protected]] 代表 Erik Nordmark 发送时间: 2014年10月21日 23:37 收件人: [email protected]<mailto:[email protected]> 主题: [nvo3] Concerns about NVO3 dataplane requirements document 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). [hao] Existing ECMP routing hashes in a per-flow fashion. All packets from a single flow will be delivered along the same path. It’s unreasonable for large flow which is very common in today’s datacenters. Hashing in a finer granularity rather than per-flow hashing will be helpful for load balancing. Actually there are already some work[FLARE][CONGA] which we may refer to. [FLARE] Kandula, S.; et al. “Dynamic Load Balancing Without Packet Reordering”, SIGCOMM Comput. Commun. Rev., ACM, 2007, 37, 51-62. [CONGA] Alizadeh, M.; et al. “CONGA: Distributed Congestion-aware Load Balancing for Datacenters”, Conference on SIGCOMM, ACM, 2014, 503-514. 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: - MUST contain an VNID field. This field MUST be large enough to scale to 100's of thousands of virtual networks - ??? QoS field inside the NVO3 overlay header or not ??? - MUST/SHOULD facilitate ECMP in unmodified routers in the underlay (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.) 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. 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<http://www.quotationspage.com/quotes/Antoine_de_Saint-Exupery/> French writer (1900 - 1944)
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
