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

[Stewart Bryant <[e-mail]>]

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, [e-mail] 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: [e-mail] <[e-mail]>;
> Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> 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 <[e-mail]>
> To: [e-mail] <[e-mail]>;
> Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
> 
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3