Dear Xiao Min Thank you for your reply and your edits.
I think the draft is now ready to progress to the next stage of the IETF process. Best regards Stewart > On 11 Aug 2022, at 09:01, [email protected] wrote: > > For some unknown reason, the attached files can't get to the archive. > I've posted the updated draft for your review. > https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-07 > > Sorry for the inconvenience. > > - Xiao Min > ------------------Original------------------ > From: 肖敏10093570 > To: [email protected] <[email protected]>; > Cc: [email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] <[email protected]>; > Date: 2022年08月11日 15:38 > Subject: Re: [nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06 > 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 <[email protected]> > To: [email protected] <[email protected]>; > Cc: [email protected] > <[email protected]>;[email protected] <[email protected]>; > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
