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:
- 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
