Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Eric,



Thank you for the review and thoughtful comments.



Please see inline.



Original



From: ÉricVynckeviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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
[e-mail]
https://www.ietf.org/mailman/listinfo/nvo3