Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
xiao.min2@zte.com.cn Thu, 17 August 2023 06:54 UTC
Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F824C14CE4D; Wed, 16 Aug 2023 23:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9wMaqvPBQ3R; Wed, 16 Aug 2023 23:54:51 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44194C14CE4B; Wed, 16 Aug 2023 23:54:48 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4RRG2l04Gjz5PLr8; Thu, 17 Aug 2023 14:54:39 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl1.zte.com.cn with SMTP id 37H6s14D072633; Thu, 17 Aug 2023 14:54:26 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid201; Thu, 17 Aug 2023 14:54:29 +0800 (CST)
Date: Thu, 17 Aug 2023 14:54:29 +0800
X-Zmail-TransId: 2afc64ddc425592-5149c
X-Mailer: Zmail v1.0
Message-ID: <202308171454291756536@zte.com.cn>
In-Reply-To: <CAF4+nEHU5xOAMoydJkRX1w=D+oar2pLVVBxC=en-UZ5mW-H_iQ@mail.gmail.com>
References: CAF4+nEG39egEFAaRQtkO6rqoyPqk2bVnfxAZHB_jWHMX7VzKgA@mail.gmail.com, 202308151629487438275@zte.com.cn, CAF4+nEHU5xOAMoydJkRX1w=D+oar2pLVVBxC=en-UZ5mW-H_iQ@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: d3e3e3@gmail.com
Cc: int-ads@ietf.org, draft-ietf-nvo3-bfd-geneve.all@ietf.org, int-dir@ietf.org, nvo3-chairs@ietf.org, nvo3@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 37H6s14D072633
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 64DDC42F.000/4RRG2l04Gjz5PLr8
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/JKAOVjLwKoC2VBPqAFcr1pgHmwY>
Subject: Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Aug 2023 06:54:53 -0000
Hi Donald, Thank you for the response.Please see inline my comments tagged with [XM-2]. CC'd to nvo3@ietf.org. Original From: DonaldEastlake <d3e3e3@gmail.com> To: 肖敏10093570; Cc: int-ads@ietf.org <int-ads@ietf.org>;draft-ietf-nvo3-bfd-geneve.all@ietf.org <draft-ietf-nvo3-bfd-geneve.all@ietf.org>;int-dir@ietf.org <int-dir@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; Date: 2023年08月17日 04:44 Subject: Re: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12 Xiao Min, On Tue, Aug 15, 2023 at 4:30 AM <xiao.min2@zte.com.cn> wrote: > > Hi Donald, > > Thanks for your review and thoughtful comments. > Please see inline. > > Original > From: DonaldEastlake <d3e3e3@gmail.com> > To: int-ads@ietf.org <int-ads@ietf.org>;draft-ietf-nvo3-bfd-geneve.all@ietf.org <draft-ietf-nvo3-bfd-geneve.all@ietf.org>; > Cc: int-dir@ietf.org <int-dir@ietf.org>;nvo3-chairs@ietf.org <nvo3-chairs@ietf.org>; > Date: 2023年08月05日 19:23 > Subject: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12 > I am an assigned INT directorate reviewer for > <draft-ietf-nvo3-geneve-12.txt>. These comments were written primarily > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with > any other Last Call comments that have been received. For more details > on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > <https://datatracker.ietf.org/group/intdir/about/>. > > Based on my review, if I was on the IESG I would ballot this document > as DISCUSS. I have the following DISCUSS/ABSTAIN level issues: > > - I do not understand the second half of the last paragraph of Section > 1. It says: "BFD for Geneve MUST be used within a TMCE unless BFD is > congestion controlled." But then seems to specify that it be > congestion controlled inside a TMCE. Would it be simpler to say that > BFD for Geneve must always be congestion controlled, if that is what > is intended? > [XM]>>> The last paragraph of Section 1 was introduced to address comments from Magnus Westerlund in his Tsvart last call review [1]. > > In Magnus's comments, it says > > "So I think there are two paths forward. Either restrict the applicability of > this usage to paths where it is known to have provisioned capacity for the BFD, > as noted as required in RFC 5881 applicability statement. The alternative is to > extend BFD to actually have a real congestion control." > > I agree with Magnus that "have provisioned capacity for the BFD" (as required in RFC 5881) and "a real congestion control" are two different things. > To avoid confusion, I propose to change the text as below. > > OLD > > BFD for Geneve MUST > be used within a TMCE unless BFD is congestion controlled. An > operator of a TMCE deploying BFD for Geneve is required to provision > the rates at which BFD is transmitted to avoid congestion and false > failure detection. > > NEW > > BFD for Geneve MUST > be used within a TMCE unless BFD is really congestion controlled. As an alternative to a real congestion control, an > operator of a TMCE deploying BFD for Geneve is required to provision > the rates at which BFD is transmitted to avoid congestion and false > failure detection. > > [1] https://mailarchive.ietf.org/arch/msg/nvo3/Gps8423YoowFB0lN2UudpLeGxHk/ OK. > - The wording in Section 4.1 first paragraph seems confusing and > > incomplete. (I believe this has been covered in other reviews.) > [XM]>>> Yes, this has been covered in John's review. > > > - In the first paragraph of Section 6: How can it be that both "Geneve > provides security" and "Geneve does not have any inherent security > mechanisms" ? > [XM]>>> Propose to change the text as below. > > OLD > > Geneve provides security between the peers and subject to the issue of overload described below. > > NEW > > Geneve (through IPsec, DTLS, or other means) provides security between the peers and subject to the issue of overload described below. I think you are talking about wrapping Geneve in IPSEC / DTLS / etc. I don't see how this is Geneve providing security. It's IPSEC / DTLS / etc. providing security for whatever their payload is including where that payload is something wrapped in Geneve. [XM-2]>>> You're right. Let me try again. 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. > The following are other issues I found with this document that SHOULD > be corrected before publication: > > - In section 4, the Inner Ethernet Header MAC addresses are in the > wrong order. The Destination MAC comes first, followed by the Source > MAC in an Ethernet header, the opposite of IP. > [XM]>>> OK. Propose to change the text as below. > > OLD > > Inner Ethernet Header:¶ > Source MAC: MAC address of a VAP of the originating NVE.¶ > Destination MAC: MAC address of a VAP of the terminating NVE. > > NEW > > Inner Ethernet Header:¶ > Destination MAC: MAC address of a VAP of the terminating NVE. > Source MAC: MAC address of a VAP of the originating NVE.¶ OK. > The following are minor issues (typos, misspelling, minor text > improvements) with the document: > > - Given the prominence of "tunnels" in the one sentence abstract, I > think it would be good to use that word in the first paragraph of the > Introduction. Possibly: "... an overlay network of tunnels by > decoupling ..." > [XM]>>> OK. Will make the change as you proposed. > > > - Section 1, last line of first paragraph on page 3: payload -> payloads > [XM]>>> I suspect you mean page 2, right? I'm pretty sure it's page 3: OLD Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payload and variable length options. NEW Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol payloads and variable length options. [XM-2]>>> OK, I see. Will make this change. > - Section 4.1, first paragraph: "Protocol Type" -> "Ethertype" > [XM]>>> As defined in Geneve Header, this field is called "Protocol Type", do I miss something? Probably better to maintain consistency. [XM-2]>>> In both Section 4.1 and Section 5.1, "Protocol Type" is consistently used, so propose to remain it as is. Cheers, Xiao Min > - Section 5, last line: that -> when > [XM]>>> Considering "Management VNI" is outside the scope of this document, I propose to remove the last sentence, and change SHOULD to MUST. > > OLD > Virtual Network Identifier (VNI) field SHOULD be set to the VNI > number that the originating VAP is mapped to. One exception is > that the Management VNI is used. > > NEW > Virtual Network Identifier (VNI) field MUST be set to the VNI > number that the originating VAP is mapped to. > > Note that the same change applies to the last paragraph of Section 4. OK. > - Section 6, "not low" -> "high" > [XM]>>> OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > Best Regards, > Xiao Min
- [Int-dir] INTDIR Review of draft-ietf-nvo3-bfd-ge… Donald Eastlake
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… Eric Vyncke (evyncke)
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… xiao.min2
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… xiao.min2
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… Donald Eastlake
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… xiao.min2
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… Donald Eastlake
- Re: [Int-dir] [nvo3] INTDIR Review of draft-ietf-… xiao.min2
- Re: [Int-dir] INTDIR Review of draft-ietf-nvo3-bf… Eric Vyncke (evyncke)