Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
xiao.min2@zte.com.cn Thu, 11 August 2022 07:19 UTC
Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6777BC14CF0F; Thu, 11 Aug 2022 00:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level:
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, 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=no 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 D0ltHjVd2BLM; Thu, 11 Aug 2022 00:19:37 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1503C14CF05; Thu, 11 Aug 2022 00:19:32 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.82]) (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 4M3J8f2LkCz8R048; Thu, 11 Aug 2022 15:19:30 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 27B70GaM005358; Thu, 11 Aug 2022 15:00:16 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Thu, 11 Aug 2022 15:00:15 +0800 (CST)
Date: Thu, 11 Aug 2022 15:00:15 +0800
X-Zmail-TransId: 2afd62f4a8ffffffffff8515b580
X-Mailer: Zmail v1.0
Message-ID: <202208111500158589846@zte.com.cn>
In-Reply-To: <165969771901.55335.13917159119419478173@ietfa.amsl.com>
References: 165969771901.55335.13917159119419478173@ietfa.amsl.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: noreply@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-nvo3-bfd-geneve.all@ietf.org, nvo3@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl2.zte.com.cn 27B70GaM005358
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62F4AD82.000 by FangMail milter!
X-FangMail-Envelope: 1660202370/4M3J8f2LkCz8R048/62F4AD82.000/10.5.228.82/[10.5.228.82]/mse-fl2.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62F4AD82.000/4M3J8f2LkCz8R048
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/iLwmPPi65WPc8GdSZD0Voe831go>
Subject: Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2022 07:19:41 -0000
Dear Stewart, Thanks for your insightful review and comments, especially the proposed text, very helpful. Attached please find the updated draft (working -07 version) addressing your comments, and the Diff. For my responses to your comments, please see inline... Best Regards, Xiao Min ------------------Original------------------ From: StewartBryantviaDatatracker <noreply@ietf.org> To: rtg-dir@ietf.org <rtg-dir@ietf.org>; Cc: draft-ietf-nvo3-bfd-geneve.all@ietf.org <draft-ietf-nvo3-bfd-geneve.all@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>; Date: 2022年08月05日 19:08 Subject: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06 Reviewer: Stewart Bryant Review result: Has Issues I do not see any boilerplate automatically provided in the review tool, so assume that the standard RTG-dir boilerplate is here. The protocol described here is simple and will work. It is well written. [XM]>>> Thank you. However I do have some concerns about the structure of the document. I think that the document would be better as either two large sections one describing the Ethernet payload model and the other describing IP operation, or as an integrated document (as it is) but with one section describing operation in one mode and the other describing the differences. The way it is written the reader has to spend a lot of time looking at the text in adjacent sections/paragraphs to work out what changed. [XM]>>> I think your concerns are valid, so I restructured this document, attempted to make it more friendly to the reader. Detailed comments: 132 3. BFD Packet Transmission over Geneve Tunnel 134 Concerning whether the Geneve data packets include an Ethernet frame 135 or an IP packet, SB> I think that this would be clearer as: Since the Geneve data packet payload may be either an Ethernet frame or an IP packet, [XM]>>> Accepted. this document defines two formats of BFD packet 136 encapsulation in Geneve. BFD session is originated and terminated at 137 VAP of an NVE, selection of the BFD packet encapsulation is based on 138 how the VAP encapsulates the data packets. SB> I reads better as “The BFD” and “the VAP” [XM]>>> Accepted. SB> I think that it would help the reader if the authors now summarise what is about to be described. SB> I think you are saying: If the payload is IP, then we carry BFD over IP in the payload. If the payload is ethernet then the Ethernet payload becomes IP regardless of what it might normally carry and we carry BFD over IP in the same manner as we would carry it in the IP payload case. [XM]>>> Accepted. SB> If that was stated (assuming I have it correct) then many readers would immediately know what follows. ======== 193 The BFD packet MUST be carried inside the inner Ethernet frame of the 194 Geneve packet. The inner Ethernet frame carrying the BFD Control 195 packet has the following format: 197 Ethernet Header: SB> For clarity that would be better as the "Inner Ethernet Header" [XM]>>> Accepted. ========= 282 Figure 2: Geneve Encapsulation of BFD Control Packet With the 283 Inner IP/UDP Header SB> I think that this would be a bit clearer if you had a single section describing the BFD over UDP/IP and then a small section saying how you carry this directly over Geneve and a sections saying how you carry that UDP/IP over Ethernet inside Geneve. [XM]>>> As said above, I restructured this document. =========== 319 4. Reception of BFD packet from Geneve Tunnel 321 Once a packet is received, the NVE MUST validate the packet as 322 described in [RFC8926]. 324 If the Protocol Type field equals 0x6558 (Ethernet frame), and the 325 Destination MAC of the inner Ethernet frame matches the MAC 326 address of a VAP which is mapped to the same as received VNI, then 327 the Destination IP, the UDP destination port and the TTL or Hop 328 Limit of the inner IP packet MUST be validated to determine 329 whether the received packet can be processed by BFD. 331 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 332 and the Destination IP of the inner IP packet matches the IP 333 address of a VAP which is mapped to the same as received VNI, then 334 the UDP destination port and the TTL or Hop Limit of the inner IP 335 packet MUST be validated to determine whether the received packet 336 can be processed by BFD. SB> This is technically correct, but again it might be simpler for the reader to have common text and a difference text. [XM]>>> As said above, I restructured this document. ======== 369 5. Security Considerations 371 Security issues discussed in [RFC5880], [RFC5881], and [RFC8926] 372 apply to this document. SB> Does the GTSM security mechanism called up in RFC5881 do anything for you? SB> The key security mechanism is that BFD has to arrive inside a Geneve packet. SB> I think the security actually comes from RFC8926 i.e. Geneve itself. The BFD is then a payload that is carried securely between peers just like any other payload. If the peers cannot trust each other all bets are off. The security discussion is RFC5880 and RFC5881 are for when BFD is openly carried across the network, and as far as I can see add no particular value here. [XM]>>> I agree. SB> So I think that you can say (in the correct parlance) that BFD is an application that is run at the two ends of the Geneve connection within the equipment running Geneve. Geneve provides security between the peers, and subject to the issue of overload described below, BFD introduces no security vulnerabilities when run in this manner. [XM]>>> Accepted. 374 This document supports establishing multiple BFD sessions between the 375 same pair of NVEs, each BFD session over a pair of VAPs residing in 376 the same pair of NVEs, there SHOULD be a mechanism to control the 377 maximum number of such sessions that can be active at the same time. SB> I think that text needs to be expanded a bit, because this is a new threat and is possibly the biggest threat to the operation of this system. [XM]>>> Some expanding text added. Thank you again, Stewart. _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
- [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd… Stewart Bryant via Datatracker
- Re: [nvo3] Rtgdir early review of draft-ietf-nvo3… xiao.min2
- Re: [nvo3] Rtgdir early review of draft-ietf-nvo3… xiao.min2
- Re: [nvo3] Rtgdir early review of draft-ietf-nvo3… xiao.min2
- Re: [nvo3] Rtgdir early review of draft-ietf-nvo3… Stewart Bryant