Hi Tim,
thank you for the review and comments. Please find my notes below tagged GIM>>. The attached diff highlights the updates applied in the current working version (to be -15) of the draft.
Regards,
Greg
On Mon, Jan 6, 2025 at 7:21 AM Tim Chown via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Tim Chown
Review result: Ready with Nits
Hi,
This draft presents requirements and a framework for OAM within Geneve
networks, to guide the implementation of active OAM mechanisms that can be run
between Geneve NVEs.
Overall the draft is close to being Ready for advancement to the IESG, save
some minor comments/nits below which I would encourage the authors to address
to enhance the clarity of the document where currently I find some parts
ambiguous or even at odds with each other.
General:
The draft doesn't clearly state in the abstract that the scope of the document
is OAM *within* the Geneve network, i.e., between the tenant-facing interfaces
of the NVEs, and that testing end-to-end between tenants is out of scope. Once
I realised this my second pass through the document was much easier. I'd
suggest putting the text in para 5 of section 1 about "Active OAM messages in
a..." much earlier on.
GIM>> Thank you for the suggestion. Would the following update reflect your idea:
OLD TEXT:
Active OAM messages in a
Geneve overlay network are exchanged between two Geneve tunnel
endpoints, which may be a Network Virtualization Edge (NVE) or
another device acting as a Geneve tunnel endpoint.
NEW TEXT:
Active OAM messages in a
Geneve overlay network are exchanged between two Geneve tunnel
endpoints, which may be the tenant-facing interface of the Network
Virtualization Edge (NVE) or another device acting as a Geneve tunnel
endpoint. Testing end-to-end between tenants is out of scope.
Secondly, the draft is about OAM, but you might want to troubleshoot by running
other supported tools in the platform over the Geneve elements, e.g., iperf.
Does this draft apply to such tools as well as the active OAM examples you
give, as a side benefit, or would that need separate treatment?
GIM>> Thank you for this great question. AFAIK, iperf is not developed in IETF. In my experience, we define the applicability of OAM tools developed in IETF.
Section 2.1:
It's not made clear HOW test packets are made to share the same fate as data
packets. Given this document is implementation guidance, maybe make it more
explicit? In particular, is there the possibility of different traffic over
the same tunnel following different paths through the underlay? If so, how is
this catered for?
GIM>> We intended Figure 2 to provide sufficient information on how an active OAM message may be encapsulated in a Geneve tunnel. Do you find that that information insufficient?
Requirement 4 - must not be forwarded to a tenant, but presumably never sent
from a tenant - the source is always an NVE?
GIM>> As I understand Geneve, a tenant is not part of a Geneve tunnel. If that is correct, an active OAM sent by a tenant is not Geneve. i.e., tunnel level, OAM but service level OAM.
Is it always the outer interface
or may it be any NVE interface?
GIM>> It may be any NVE interface.
I don't understand the "express entropy" part of Requirement 5 - how does the
"programming" ensure the in-band property? What is the entropy here? Isn't
entropy normally something you need a lot of to allow a good hash/load balance
distribution?
GIM>> Similar comment we received in the OpsDir review. It was addressed in -14 version by the following update:
OLD TEXT:
The second case is when a test packet is transmitted using the VNI
value associated with the monitored service flow. By doing that, the
test packet experiences network treatment as the tenant's packets.
Details of that use case are outside the scope of this specification.
NEW TEXT:
The second case is when a test packet is transmitted using the VNI
value associated with the monitored service flow. By doing that, the
test packet experiences network treatment as the tenant's packets.
An example of the realization of that scenario is discussed in
[RFC9521].
Section 2.2
Nice examples, but in the first case Req 4 is about tenants, not the overlay?
I think you should state very clearly what the test endpoints are for
diagnosing the first case. I assumed the tests would be within the Geneve
network, but you then imply it is not?
GIM>> A Geneve test packet can be injected into the Geneve network from an NVE. To conform to Requirement#4 we recommend using the Management VNI, which doesn't have any tennants attached. The termination of the Management VNI on an NVE is defined in Section 2.2. Do you find that some information is insufficient in that reagrd?
Then for the second case you say details are out of scope of the document. This
seems the more interesting, "real" case, but it's not considered in detail - is
there a reason?
GIM>> In the course of the discussion with Tony Li, and addressing his OpsDir review, added the reference to RFC 9521 as follows:
An example of the realization of that scenario is discussed in
[RFC9521].
Typos:
Section 1, para 3 "example of active" - make plural
GIM>> Done.
Section 2.2 penultimate para "specification, MUST" - delete the comma
GIM>> Done.
Tim
<<< text/html; charset="US-ASCII"; name="draft-ietf-nvo3-geneve-oam-15.diff.html": Unrecognized >>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
