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

[[e-mail]]

Thank you for clearing your DISCUSS, Eric!






Best Regards,


Xiao Min



Original



From: EricVyncke(evyncke) <[e-mail]>
To: 肖敏10093570;
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月24日 19:26
Subject: Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-bfd-geneve-12: (with DISCUSS and COMMENT)




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: "[e-mail]" <[e-mail]>
 Date: Wednesday, 23 August 2023 at 11:39
 To: Eric Vyncke <[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]>
 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 <[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?

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
 [e-mail]
 https://www.ietf.org/mailman/listinfo/nvo3