Hi Magnus,
Thank you for the review and thoughtful comments.
Please see inline.
Original
From: MagnusWesterlundviaDatatracker <noreply@xxxxxxxx>
To: tsv-art@xxxxxxxx <tsv-art@xxxxxxxx>;
Cc: draft-ietf-nvo3-bfd-geneve.all@xxxxxxxx <draft-ietf-nvo3-bfd-geneve.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;nvo3@xxxxxxxx <nvo3@xxxxxxxx>;
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-art@xxxxxxxx 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.
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.
nvo3 mailing list
nvo3@xxxxxxxx
https://www.ietf.org/mailman/listinfo/nvo3
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-art@xxxxxxxx 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.
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
nvo3@xxxxxxxx
https://www.ietf.org/mailman/listinfo/nvo3
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
