Hi Magnus,
Thank you for the prompt reply. A new version has just been posted to address your comments. Link as below. https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-11 I also cc BFD WG to see if some new ideas can be motivated by your good observation. Best Regards, Xiao Min Original From: MagnusWesterlund <magnus.westerlund=40ericsson....@dmarc.ietf.org> To: 肖敏10093570; Cc: tsv-...@ietf.org <tsv-...@ietf.org>;draft-ietf-nvo3-bfd-geneve....@ietf.org <draft-ietf-nvo3-bfd-geneve....@ietf.org>;last-c...@ietf.org <last-c...@ietf.org>;n...@ietf.org <n...@ietf.org>; Date: 2023年07月04日 15:59 Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10 _______________________________________________ nvo3 mailing list n...@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 Hi Xiao Min, I think that text is mostly fine, I would think that this RECOMMENDED needs to be a “MUST unless BFD is congestion controlled”. That later part as a caveat if one can actually deploy a BFD congestion control. I would really recommend routing area to look into this problem of how to separate path failures, from on path congestion (especially self inflicted), or endpoint overload. Which appears to be the different things desired to be separated for BFD. Note, I don’t expect congestion control for BFD to look like TCP at all. I would expect it to be something may be fairly slow in reaction, which allows BFD in those deployments where it is needed to step down the load on the network and the end points to see if the failure to get all/some packets through are dependent on the introduced load. Cheers Magnus From: xiao.m...@zte.com.cn <xiao.m...@zte.com.cn> Date: Tuesday, 4 July 2023 at 08:49 To: Magnus Westerlund <magnus.westerl...@ericsson.com> Cc: tsv-...@ietf.org <tsv-...@ietf.org>, draft-ietf-nvo3-bfd-geneve....@ietf.org <draft-ietf-nvo3-bfd-geneve....@ietf.org>, last-c...@ietf.org <last-c...@ietf.org>, n...@ietf.org <n...@ietf.org> Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10 Hi Magnus, Thank you for the review and thoughtful comments. Please see inline. Original From: MagnusWesterlundviaDatatracker <nore...@ietf.org> To: tsv-...@ietf.org <tsv-...@ietf.org>; Cc: draft-ietf-nvo3-bfd-geneve....@ietf.org <draft-ietf-nvo3-bfd-geneve....@ietf.org>;last-c...@ietf.org <last-c...@ietf.org>;n...@ietf.org <n...@ietf.org>; Date: 2023年07月03日 17:36 Subject: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10 Reviewer: Magnus Westerlund Review result: Not Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. I have reviewed BFD for Geneve (draft-ietf-nvo3-bfd-geneve-10) and have one significant point on this protocol. So when BFD was published after quite some discussion about the lack of an actual congestion control mechanism in BFD in RFC 5880 there was agreement on the following that was included in Section 7 of RFC 5880: When BFD is used across multiple hops, a congestion control mechanism MUST be implemented, and when congestion is detected, the BFD implementation MUST reduce the amount of traffic it generates. The exact mechanism used is outside the scope of this specification, and the requirements of this mechanism may differ depending on how BFD is deployed, and how it interacts with other parts of the system (for example, exponential backoff may not be appropriate in cases where routing protocols are interacting closely with BFD). As this usage of BFD although is point to point inside the tunnel, the fact that it is a tunnel and can bridge both multisegment L2 and especially IP networks means that this document in my view need to define how it fulfills the above requirements when using BFD. I do note the security consideration do note that overload is a factor due to multiple path sharing tunnel establishments. So there are apparently risks from two types of overlad situations here. First that multiple tunnles between endpoints are established. Secondly, that there are congestion due to network cross traffic on the paths the tunnels share. 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. Something I think would have benefit all considering how wide spread use there is of BFD over various overlay networks that really are ignoring this potential issue. [XM]>>> I lean to the former one. Propose to add a new paragraph to the last of Introduction section. NEW As specified in Section 4.2 of [RFC8926], Geneve MUST be used with congestion-controlled traffic or within a traffic-managed controlled environment (TMCE) to avoid congestion, that requirement applies to BFD traffic too. Specifically, considering the complexity and immaturity of BFD congestion control mechanism, BFD for Geneve is RECOMMENDED to be used within a TMCE. 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. To conclude I am of the oppinion that this document should not be approved for publication until this issue of congestion control is handled one way of another. [XM]>>> Please check the proposed new text and let me know whether your concern is addressed. Thanks, Xiao Min _______________________________________________ nvo3 mailing list n...@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
