Reviewer: Qin Wu
Review result: Has Nits
This document can be seen as NVO3 encapsulation design team report and
compares 3 typical data plane encapsulation formats including GENEVE, GUE,
VXLAN-GPE and explores technical problem and limitation and provides guidance
and recommendation for common encapsulation design. It also lays foundation
for future extension to Geneve encapsulation defined in RFC8926.
I believe it is well written and ready for publication, here are a few comments
to v-(10) I would like author to consider:
Major issues:
No
Minor issues:
1. Section 5.3 said
"The B bit indicates the packet is an ingress replicated
Broadcase, Unknown Unicast, or Multicast packet. The O bit indicates
an OAM packet.
Issues with VXLAN-GPE [nvo3_vxlan_gpe] are as follows:"
[Qin]: s/Broadcase/Broadcast
2. Section 5.3 said:
"
* Security, e.g., of the VNI, has not been addressed by GPE.
"
[Qin]: I am wondering how this statement is related to section 6.2.2? Do we
need add rationale here to explain why security of VNI can be be addressed?
e.g., can we use UDP checksum to protect the payload including VNI carried
in VXLAN-GPE header? or UDP checksum is always set to zero? or can we extend
VXLAN-GPE to carry HMAC-like Message Authentication Code (MAC)?
3. Section 5.3 said:
"
Although a shim header could be used for security and other
extensions, this has not been defined yet and its implications on
offloading in NICs are not understood.
"
[Qin]: Can we add rationale why offloading in NIC is not understood, is this
becos
GPE is not extensible?
4.Section 6.2.2 said:
"
This is desirable since we still have the UDP header for ECMP, the
NVO3 header is in plain text so it can be read by network elements,
and different security or other payload transforms can be supported
"
[Qin]:
I can understand DTLS and IPSEC are two different security schemes.
How do we understand transforms in the "payload transforms"?
5. Section 6.3 said:
"
It is hard to predict which options will be implemented in which
piece of hardware and when. That depends on whether the hardware
will be in the form of a NIC providing increasing offload
capabilities to software NVEs, or a switch chip being used as an NVE
gateway towards non-NVO3 parts of the network, or even a transit
device that participates in the NVO3 dataplane, e.g., for OAM
purposes.
"
[Qin] The second sentence seems too long, I think the key messages can be
rephrased as three factors decides which options is implemented in which
hardware? How about making the following change： " It is hard to predict
which options will be implemented in which piece of hardware and when. That
depends on: o whether the hardware will be in the form of a NIC providing
increasing offload
capabilities to software NVEs;
o or a switch chip being used as an NVE gateway towards non-NVO3 parts of
the network, o or even a transit device that participates in the NVO3
dataplane, e.g., for OAM
purposes.
"
6.Section 6.4 said:
"
The recommended minimum total svailable header length is 64 bytes.
"
[Qin]s/svailable/available
7.Section 6.6. TLV versus Bit Fields
[Qin]: If we have already decided to choose geneve as common encapsulation
and geneve chooses to use TLV for extension. Why should we discuss comparison
between TLV and Bit Fields.
Should common encapsulation consideration only focus on TLV?
8. Section 6.7. Control Plane Considerations
[Qin] The 2nd paragraph of section 6.6 also discuss using control plane to
control the order of the TLVs, which seems overlapping with section 6.7? Is
this intentional?
9. Section 6.9
If we need a larger VNI, an extension can
be used to support that.
[Qin]: In which case where we need a larger VNI？ Can we provide a use case
to demonstrate the limitation of 24 bit VNI.
10.Section 7 said:
"The DT studied whether VNI should be in the base header or in an
extension header and whether it should be a 24-bit or 32-bit
field."1.
[Qin] Similarly, Not clear when we will use 32 bit field?
11.Section 7 said:
"
By using Geneve options it is
possible to get in band parameters like switch id, ingress port,
egress port, internal delay, and queue in telemetry defined
extension TLV from switches.
"
[Qin] What is queue in telemetry defined extension TLV? Can not parse.
Are you saying "queue in telemetry" defined in extension TLV?
12. Section 7 said:
"
9. The DT has addressed the usage models while considering the
requirements and implementations in general including software
and hardware.
"
[Qin] Are usage models related to Useful Extensions Use Cases defined in
Section 6.2? If Yes, please add referenced section.
13. With recommendation given in section 7, Do you think RFC8926 Geneve
Document needs
to be revised as RFC8926bis document, or you expect for each extension for
OAM, performance measurement, security, a separate document is needed to
extend RFC8926 to support each extension?
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
