Re: [bess] Tsvart last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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 <[e-mail]>
Sent: Monday, August 30, 2021 5:59 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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
[e-mail] 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