[Bier] Éric Vyncke's Discuss on draft-ietf-bier-evpn-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-bier-evpn-10: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Éric Vyncke, INT AD, comments for draft-ietf-bier-evpn-10

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy & trivial to address),
some non-blocking COMMENT points (but replies would be appreciated even if only
for my own education), and some nits.

Special thanks to Mankamana Prasad Mishra for the shepherd's very succinct
write-up even if I wonder what a "YES" answer means to a question about the WG
consensus (as it has two clauses linked by a "OR"), it also *lacks* the
justification for the intended status.

Other thanks to Haoyu Song, the Internet directorate reviewer (at my request),
please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-bier-evpn-10-intdir-telechat-song-2023-11-20/
(just a nit and I have read Jeffrey's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is simply a request to have a discussion on the following topics:

## BCP 14

Very similar to Roman's review, but I do think that it is DISCUSS level, i.e.,
please use the correct BCP14 template (including the reference to RFC 8174).

## IANA considerations

Please also have an IPv6 clause in `Preferably this is assigned from the Local
Network Control Block (224.0.0/24).`. I.e., in section 2.1 there is normative
text that requires this multicast address `A well-known IP multicast address
(to be assigned by IANA)`.

## Section 2.2.1

The RFC editor abbreviation list has multiple expansions for "AC", which one is
the correct one in this document? Suggest to expand "AC" on the first use as
not every reader may have the context (in this case, guessing attachment
circuit).


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


# COMMENTS (non-blocking)

## Sections 1 & 2.2.2.2

The reference to draft-zzhang-bess-mvpn-evpn-cmcast-enhancements is about a
non-adopted expired I-D, is this reference still useful?

## Section 1.1

Suggest to explicitly write that in "C-" the "C" stands for customer, similar
comment for "P-tunnel".

Is it a prefix or an address in `BFR-Prefix: An IP address` ?

## Section 2.1

Even if "PHP" is a recognised RFC editor acronym, please expand "PHP" at first
use for the less familiar readers.

Please expand "BD" at first use.

## Section 2.2.1

Expansion of SMET is already defined before, no need to expand it again.

Not being a BIER expert, I wonder whether `For a selective PMSI, the set of
BFERs to deliver traffic to includes the originators of corresponding SMET
routes.` is descriptive enough for an implementor.

## Section 4.1.1

In `a VXLAN/NVGRE/GENEVE header is prepended to the packet with the VNI/VSID
set to the value in the PTA's label field` is it specified where the VNI/VSID
is located in a NVGRE header ? My understanding (and happy to be corrected) is
that NVGRE uses the same encapsulation as GRE, i.e., RFC 2784 does not have any
VNI/VSID field. I was about to raise a discuss-discuss level (i.e., just a
normal question) but I am trusting the responsible AD on this one.

## Section 5

Suggest to add reference to GENEVE/NVGRE/VXLAN.

## Section 6 (security considerations)

I will let the Security ADs chime in, but I wonder whether there should be
recommendations to rate throttle the traffic to those BUM destinations, they
are easily generated, can be faked, and will impact several BEFRs (including
some shared by other customers). Or is it implicit in the list of references ?

# NITS (non-blocking / cosmetic)

## Section 1

`provider/underlay tunnels (referred to as P-tunnels)` the "P-tunnels" is
already defined in section 1.1

## Section 2

Is it really useful to state the length of addresses in `This will either be a
/32 IPv4 address or a /128 IPv6 address` ?

## Section 2.1

s/VXLAN/GENVE/VXLAN/GENEVE/ ?

## Section 3 (and other places)

Several acronyms are used without prior extension (e.g., "ES" and "ESI" in
section 3), while most of them are included in
https://www.rfc-editor.org/materials/abbrev.expansion.txt, it would help the
reader to provide expansions for less known (to me at least ;-) ) acronyms.
Thank you.