Xiao, The proposed text will address my DISCUSS point indeed. Thanks for the -13 revision, I am clearing my previous DISCUSS ballot ;-)
Other comments are also OK. Regards -éric From: "xiao.m...@zte.com.cn" <xiao.m...@zte.com.cn> Date: Wednesday, 23 August 2023 at 11:39 To: Eric Vyncke <evyn...@cisco.com> Cc: "i...@ietf.org" <i...@ietf.org>, "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>, "d3e...@gmail.com" <d3e...@gmail.com> Subject: Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT) 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? OLD Geneve provides security between the peers and subject to the issue of overload described below. NEW The 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 an exception 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
