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

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

Hi Eric,

Thanks for your review and comments. I posted the -011 revision that addresses your DISCUSS/COMMENTs and comments from others: https://author-tools.ietf.org/iddiff?url1=draft-ietf-bier-evpn-10&url2=draft-ietf-bier-evpn-11&difftype=--html

Please see zzh> below for some clarifications.


Juniper Business Use Only
-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Thursday, November 23, 2023 8:56 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's Discuss on draft-ietf-bier-evpn-10: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


É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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FT6T4v3ec2G1wWS8ir2IZq0t2U-WXVvRWAERxV1KfPpiH46-3-oYIgXrGawJvlNpPH0sfDWNh_4r4SA$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/__;!!NEt6yMaO-gk!FT6T4v3ec2G1wWS8ir2IZq0t2U-WXVvRWAERxV1KfPpiH46-3-oYIgXrGawJvlNpPH0sfDWN-aUKjJI$



----------------------------------------------------------------------
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-bier-evpn-10-intdir-telechat-song-2023-11-20/__;!!NEt6yMaO-gk!FT6T4v3ec2G1wWS8ir2IZq0t2U-WXVvRWAERxV1KfPpiH46-3-oYIgXrGawJvlNpPH0sfDWNn5dS8ps$
(just a nit and I have read Jeffrey's reply)

I hope that this review helps to improve the document,

Zzh> Definitely - it does help a lot!

Regards,

-éric

# DISCUSS (blocking)

As noted in https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!FT6T4v3ec2G1wWS8ir2IZq0t2U-WXVvRWAERxV1KfPpiH46-3-oYIgXrGawJvlNpPH0sfDWNFAr5ghg$ , 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).

Zzh> This has been fixed.

## 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)`.

Zzh> Yes, I added that.

## 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).

Zzh> I added it to the terminology section as well.

----------------------------------------------------------------------
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?

Zzh> That document is in the adoption queue. It'll take some time to progress, and the reference in this document is informational. It is useful but I can remove it if that's better.

## Section 1.1

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

Zzh> Done.

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

Zzh> It is an address, but the "prefix" wording is used in all BIER documents.

## Section 2.1

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

Zzh> Done.

Please expand "BD" at first use.

Zzh> Done.

## Section 2.2.1

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

Zzh> Fixed.

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.

Zzh> This is actually more on the EVPN side. I did update the text per Haoyu's comment - it should be clear enough now for an EVPN 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.

Zzh> RFC 7637 for NVGRE has the following:

   In NVGRE, every virtual Layer 2 network is associated with a 24-bit
   identifier, called a Virtual Subnet Identifier (VSID).  A VSID is
   carried in an outer header as defined in Section 3.2.

   ...

   GRE Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| |1|0|   Reserved0     | Ver |   Protocol Type 0x6558        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Virtual Subnet ID (VSID)        |    FlowID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



## Section 5

Suggest to add reference to GENEVE/NVGRE/VXLAN.

Zzh> Added.

## 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 ?

Zzh> It's implicit. This document does not introduce BUM - it is just another P-tunnel that is used to deliver BUM.

# NITS (non-blocking / cosmetic)

## Section 1

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

Zzh> Removed.

## 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` ?

Zzh> I guess it is useful given the earlier question about "BFR-prefix" being a prefix or host 😊

## Section 2.1

s/VXLAN/GENVE/VXLAN/GENEVE/ ?

Zzh> Fixed.

## 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://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!FT6T4v3ec2G1wWS8ir2IZq0t2U-WXVvRWAERxV1KfPpiH46-3-oYIgXrGawJvlNpPH0sfDWNbcN-ek8$ , it would help the reader to provide expansions for less known (to me at least ;-) ) acronyms.
Thank you.

Zzh> I added ES/ESI to the terminology section. Is there a tool to identify all unexpanded acronyms? It'll be a great help find missed ones 😊
Zzh> Thanks a lot!
Zzh> Jeffrey