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 <nore...@ietf.org>
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
<https://mailarchive.ietf.org/arch/browse/nvo3/?gbt=1&index=BSZeoePvNbW-MH0kEScFZcJKT0w>.
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
<https://mailarchive.ietf.org/arch/browse/nvo3/?gbt=1&index=BSZeoePvNbW-MH0kEScFZcJKT0w>,
added the reference to RFC 9521 <https://datatracker.ietf.org/doc/rfc9521/> 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 >>>
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
