[Bier] John Scudder's No Objection on draft-ietf-bier-evpn-11: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Wed, 29 November 2023 03:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bier@ietf.org
Delivered-To: bier@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EACC14CF13; Tue, 28 Nov 2023 19:06:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bier-evpn@ietf.org, bier-chairs@ietf.org, bier@ietf.org, mankamis@cisco.com, mankamis@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 11.15.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <170122717301.11719.17104341214716762832@ietfa.amsl.com>
Date: Tue, 28 Nov 2023 19:06:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/ovrtRpJYdbGP9sJLdDC1P5DvgW4>
Subject: [Bier] John Scudder's No Objection on draft-ietf-bier-evpn-11: (with COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Nov 2023 03:06:13 -0000

John Scudder has entered the following ballot position for
draft-ietf-bier-evpn-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# John Scudder, RTG AD, comments for draft-ietf-bier-evpn-11
CC @jgscudder

Thanks for this document. As usual with multicast documents, I largely am
taking it on faith that the authors and WG know what they're doing, but I still
have a few non-blocking comments, below.

## COMMENTS

### Section 1.1

- You define "AC", but only use it once, IMO the definition isn't needed in
this case (for that matter the abbreviation isn't needed in Section 2.2.2.1,
you can just use your words).

- "Sets of C-flows can be identified by the use of the "C-*" wildcard" -- I
wonder if "denoted" would be a better term than "identified" in this context.

- "A multicast tunnel through the network of one or more SPs" -- presumably by
"SPs" you mean "service providers". Probably better to write it out.

### Section 2.2.1

I can't understand what this sentence means: "Only when selectively forwarding
is for all flows without tunnel segmentation, SMET routes are used without the
need for S-PMSI A-D routes." Specifically, I can't parse the first clause. I
would propose a rewrite if I had a solid guess as to what it meant, but alas.

### Section 2.2.2.1

I'm guessing that when you write, "It may be desired that SMET routes are not
used to reduce the burden of explicit tracking", what you mean is "It may be
desired that SMET routes are not used, in order to reduce the burden of
explicit tracking"?

(See also https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves)

### Section 3

Please expand "DF".

### Section 4.1.1, best match

I trust/hope that other documents in the BIER/EVPN/MVPN set clearly define what
"best match" means in this context. It's not intuitively obvious what things
like "best match the source and destination IP address" mean, absent a
definition.

### Section 4.1.2

"Each instance of the re-advertised route for a downstream region has a PTA
that specifies tunnel information that is the same as or different from that of
the route for a different region."

Possibly this is just my lack of expertise in the subject area and appreciation
for your subtlety, but I don't see how the second half of the sentence conveys
any information. Couldn't you rewrite it as "Each instance of the re-advertised
route for a downstream region has a PTA."?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments