Hi Donald,
Thank you for the response.Please see inline my comments tagged with [XM-2].
CC'd to nvo3@ietf.org.
Original
From: DonaldEastlake <d3e...@gmail.com>
To: 肖敏10093570;
Cc: int-...@ietf.org <int-...@ietf.org>;draft-ietf-nvo3-bfd-geneve....@ietf.org
<draft-ietf-nvo3-bfd-geneve....@ietf.org>;int-...@ietf.org
<int-...@ietf.org>;nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>;
Date: 2023年08月17日 04:44
Subject: Re: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
Xiao Min,
On Tue, Aug 15, 2023 at 4:30 AM <xiao.m...@zte.com.cn> wrote:
>
> Hi Donald,
>
> Thanks for your review and thoughtful comments.
> Please see inline.
>
> Original
> From: DonaldEastlake <d3e...@gmail.com>
> To: int-...@ietf.org
> <int-...@ietf.org>;draft-ietf-nvo3-bfd-geneve....@ietf.org
> <draft-ietf-nvo3-bfd-geneve....@ietf.org>;
> Cc: int-...@ietf.org <int-...@ietf.org>;nvo3-cha...@ietf.org
> <nvo3-cha...@ietf.org>;
> Date: 2023年08月05日 19:23
> Subject: INTDIR Review of draft-ietf-nvo3-bfd-geneve-12
> I am an assigned INT directorate reviewer for
> <draft-ietf-nvo3-geneve-12.txt>. These comments were written primarily
> for the benefit of the Internet Area Directors. Document editors and
> shepherd(s) should treat these comments just like they would treat
> comments from any other IETF contributors and resolve them along with
> any other Last Call comments that have been received. For more details
> on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
>
> Based on my review, if I was on the IESG I would ballot this document
> as DISCUSS. I have the following DISCUSS/ABSTAIN level issues:
>
> - I do not understand the second half of the last paragraph of Section
> 1. It says: "BFD for Geneve MUST be used within a TMCE unless BFD is
> congestion controlled." But then seems to specify that it be
> congestion controlled inside a TMCE. Would it be simpler to say that
> BFD for Geneve must always be congestion controlled, if that is what
> is intended?
> [XM]>>> The last paragraph of Section 1 was introduced to address comments
> from Magnus Westerlund in his Tsvart last call review [1].
>
> In Magnus's comments, it says
>
> "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."
>
> I agree with Magnus that "have provisioned capacity for the BFD" (as required
> in RFC 5881) and "a real congestion control" are two different things.
> To avoid confusion, I propose to change the text as below.
>
> OLD
>
> BFD for Geneve MUST
> be used within a TMCE unless BFD is congestion controlled. 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.
>
> NEW
>
> BFD for Geneve MUST
> be used within a TMCE unless BFD is really congestion controlled. As an
> alternative to a real congestion control, 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.
>
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/Gps8423YoowFB0lN2UudpLeGxHk/
OK.
> - The wording in Section 4.1 first paragraph seems confusing and
>
> incomplete. (I believe this has been covered in other reviews.)
> [XM]>>> Yes, this has been covered in John's review.
>
>
> - In the first paragraph of Section 6: How can it be that both "Geneve
> provides security" and "Geneve does not have any inherent security
> mechanisms" ?
> [XM]>>> Propose to change the text as below.
>
> OLD
>
> Geneve provides security between the peers and subject to the issue of
> overload described below.
>
> NEW
>
> Geneve (through IPsec, DTLS, or other means) provides security between the
> peers and subject to the issue of overload described below.
I think you are talking about wrapping Geneve in IPSEC / DTLS / etc. I
don't see how this is Geneve providing security. It's IPSEC / DTLS /
etc. providing security for whatever their payload is including where
that payload is something wrapped in Geneve.
[XM-2]>>> You're right. Let me try again.
OLDGeneve provides security between the peers and subject to the issue of
overload described below.NEWThe IP underlay network and/or the Geneve option
can provide security between the peers, which are subject to the issue of
overload described below.
> The following are other issues I found with this document that SHOULD
> be corrected before publication:
>
> - In section 4, the Inner Ethernet Header MAC addresses are in the
> wrong order. The Destination MAC comes first, followed by the Source
> MAC in an Ethernet header, the opposite of IP.
> [XM]>>> OK. Propose to change the text as below.
>
> OLD
>
> Inner Ethernet Header:¶
> Source MAC: MAC address of a VAP of the originating NVE.¶
> Destination MAC: MAC address of a VAP of the terminating NVE.
>
> NEW
>
> Inner Ethernet Header:¶
> Destination MAC: MAC address of a VAP of the terminating NVE.
> Source MAC: MAC address of a VAP of the originating NVE.¶
OK.
> The following are minor issues (typos, misspelling, minor text
> improvements) with the document:
>
> - Given the prominence of "tunnels" in the one sentence abstract, I
> think it would be good to use that word in the first paragraph of the
> Introduction. Possibly: "... an overlay network of tunnels by
> decoupling ..."
> [XM]>>> OK. Will make the change as you proposed.
>
>
> - Section 1, last line of first paragraph on page 3: payload -> payloads
> [XM]>>> I suspect you mean page 2, right?
I'm pretty sure it's page 3:
OLD
Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol
payload and variable length options.
NEW
Geneve and VXLAN [RFC7348] is that Geneve supports multi-protocol
payloads and variable length options.
[XM-2]>>> OK, I see. Will make this change.
> - Section 4.1, first paragraph: "Protocol Type" -> "Ethertype"
> [XM]>>> As defined in Geneve Header, this field is called "Protocol Type", do
> I miss something?
Probably better to maintain consistency.
[XM-2]>>> In both Section 4.1 and Section 5.1, "Protocol Type" is consistently
used, so propose to remain it as is.
Cheers,
Xiao Min
> - Section 5, last line: that -> when
> [XM]>>> Considering "Management VNI" is outside the scope of this document,
> I propose to remove the last sentence, and change SHOULD to MUST.
>
> OLD
> Virtual Network Identifier (VNI) field SHOULD be set to the VNI
> number that the originating VAP is mapped to. One exception is
> that the Management VNI is used.
>
> NEW
> Virtual Network Identifier (VNI) field MUST be set to the VNI
> number that the originating VAP is mapped to.
>
> Note that the same change applies to the last paragraph of Section 4.
OK.
> - Section 6, "not low" -> "high"
> [XM]>>> OK.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
> Best Regards,
> Xiao Min
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
