Hi Gorry, Thank you for your comments. I missed it hence the late response. Sorry about that. Please see zzh> below. -----Original Message----- From: Gorry Fairhurst via Datatracker <noreply@xxxxxxxx> Sent: Monday, August 30, 2021 5:59 AM To: tsv-art@xxxxxxxx Cc: bess@xxxxxxxx; draft-ietf-bess-evpn-bum-procedure-updates.all@xxxxxxxx; last-call@xxxxxxxx Subject: Tsvart last call review of draft-ietf-bess-evpn-bum-procedure-updates-09 [External Email. Be cautious of content] Reviewer: Gorry Fairhurst Review result: Ready with Nits 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. This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. There is a normative reference to draft-ietf-bess-evpn-igmp-mld-proxy, which normatively refers to this spec. This draft focusses on topics beneath the transport layer. It does not appear to introduce specific transport protocol concerns. 1. A common concern for transports using tunnels is the topic of fragmentation and packet size discovery. This is not mentioned, and it could be useful to point to the relevant section of a spec (I note that path "segmentation" in this draft relates to something different, in RFC 7524). Zzh> This segmentation does not introduce addition overhead compared to non-segmented case. Tunnels are just stitched together - previous segment's encapsulation is taken off and new encapsulation is put on for the next segment. It is possible that the next segment's encap header is larger (due to different encapsulation), but that is not different from if the next segment's encapsulation is used in the non-segmented case. Zzh> I will add some text to " 2.1. Reasons for Tunnel Segmentation". 2. A general comment is that the draft section 1 states "It is expected that audience is familiar with EVPN and MVPN concepts and terminologies", I suggest it would none-the-less be very helpful to: * Include appropriate RFC references to where these terms are defined (.e.g. RFC7432?); * Check all the abbreviations and either define each in section 1 or simply expand on first use in this document; zzh> Will do. 3. Section 8. Describes a temporary IANA assignment, which I presume publication of this draft confirms? I expect an IANA note to this effect would help the IANA Team. Zzh> Yes. IANA has confirmed in their review, so it should be all set. Zzh> Thanks! Zzh> Jeffrey Juniper Business Use Only -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
