Re: [RTG-DIR] [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06

xiao.min2@zte.com.cn Thu, 11 August 2022 07:37 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9219CC157B5C; Thu, 11 Aug 2022 00:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level:
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, 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=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 DZm_AEKc9q3D; Thu, 11 Aug 2022 00:37:52 -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 7A285C157B41; Thu, 11 Aug 2022 00:37:51 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.81]) (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 4M3JYm6vc5z4xVnv; Thu, 11 Aug 2022 15:37:48 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 27B7TMV3077902; Thu, 11 Aug 2022 15:29:23 +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:29:22 +0800 (CST)
Date: Thu, 11 Aug 2022 15:29:22 +0800
X-Zmail-TransId: 2afd62f4afd20e2edd7e
X-Mailer: Zmail v1.0
Message-ID: <202208111529229531394@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: sb@stewartbryant.com
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-fl1.zte.com.cn 27B7TMV3077902
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 62F4B1CC.001 by FangMail milter!
X-FangMail-Envelope: 1660203468/4M3JYm6vc5z4xVnv/62F4B1CC.001/10.5.228.81/[10.5.228.81]/mse-fl1.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62F4B1CC.001/4M3JYm6vc5z4xVnv
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/JdZ8U4ycZ2EGEp6xAwVAVSVJ87I>
Subject: Re: [RTG-DIR] [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2022 07:37:54 -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