Hi Eric,
Thank you for the review and thoughtful comments.
Please see inline.
Original
From: ÉricVynckeviaDatatracker <nore...@ietf.org>
To: The IESG <i...@ietf.org>;
Cc: draft-ietf-nvo3-bfd-gen...@ietf.org
<draft-ietf-nvo3-bfd-gen...@ietf.org>;nvo3-cha...@ietf.org
<nvo3-cha...@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>;matthew.bo...@nokia.com
<matthew.bo...@nokia.com>;matthew.bo...@nokia.com
<matthew.bo...@nokia.com>;d3e...@gmail.com <d3e...@gmail.com>;
Date: 2023年08月07日 17:56
Subject: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-nvo3-bfd-geneve-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
# Éric Vyncke, INT AD, comments for raft-ietf-nvo3-bfd-geneve-12
Thank you for the work put into this document.
Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.
Special thanks to Matthew Bocci for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status.
Other thanks to Don Eastlake, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-nvo3-bfd-geneve-12-intdir-telechat-eastlake-2023-08-05/
Don's review was 'not ready', and I concur with him after doing my own review.
Authors' reply to Don's review will be welcome.
[XM]>>> I've replied to Don's review and the resolutions to address his
comments have been confirmed.
I hope that this review helps to improve the document,
[XM]>>> Yes, I'm sure about this.
Regards,
-éric
# DISCUSS
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:
## Sectin 6
I share Don's issue about having `Geneve provides security` and `Geneve does
not have any inherent security mechanisms` in the same paragraph. There should
probably some nuance or limitation in those two assertions to make them
compatible.
[XM]>>> The following proposed change has been accepted by Don, is that
acceptable for you?
OLDGeneve provides security between the peers and subject to the issue of
overload described below.NEWThe IP underlay network and/or the Geneve option
can provide security between the peers, which are subject to the issue of
overload described below.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# COMMENTS
## Section 1
Unsure whether the following text is useful here `The major difference between
Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payload and
variable length options.`
[XM]>>> Will remove the text you quoted.
I trust the transport ADs for the accuracy of the last paragraph about the
congestion control.
[XM]>>> To avoid possible confusion, I've proposed some editorial changes
that's been confirmed by Don.
## Section 4.1
`the BFD session SHOULD be identified using`, what is the procedure to be
followed when it is not possible? The I-D should be clear on this.
[XM]>>> OK. Propose to add some text to the end of this paragraph (both Section
4.1 and 5.1).
NEW
If it fails to identify the BFD session, the incoming BFD Control packets MUST
be dropped, and anexception event indicating the failure should be reported to
the management.
## Section 5;1
`MUST be validated to determine` how can the receiving node validate ? Of
course, the reader can guess, but let's be specific.
[XM]>>> OK. John raised the similar issue, and I proposed to change the text as
below.
OLD
Then the UDP destination port and the TTL or Hop Limit of
the inner IP packet MUST be validated to determine whether the received
packet can be processed by BFD.
NEW
Then the UDP destination port and the TTL or Hop Limit
of the inner IP packet MUST be validated to determine whether the received
packet can be processed by BFD, i.e., the two field values of the inner IP
packet MUST be in compliance with what's defined in Section 5 of this document,
as well as Section 4 of [RFC5881].
What should the receiving node do if this validation fails ?
[XM]>>> Propose to add some text to the end of this paragraph (both Section 4.1
and 5.1).
NEW
If the validation fails, the received packet MUST NOT be processed by BFD.
## Section 6
Suggest to specify what "enough" means in ` are enough for the pair of NVEs`.
[XM]>>> OK. Propose to change the text as below.
OLD
In this case, it's recommended that N BFD
sessions covering all N VAPs are enough for the pair of NVEs.NEW
In this case, it's recommended that N BFD
sessions covering all N VAPs are run for the pair of NVEs.
Generally speaking, the number of BFD sessions is supposed to be enough as long
as all VAPs of the pair of NVEs are covered.
# NITS
## Section 1
s/an other device/another device/
[XM]>>> OK. Will do it.
s/p2p Geneve tunnel/P2P Geneve tunnel/ or expand `p2p`
[XM]>>> OK. Will do s/p2p Geneve tunnel/P2P Geneve tunnel.
Best Regards,
Xiao Min
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
