Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-irb-mcast-10: (with COMMENT)

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

Hi Eric,

Thanks for your review and comments. I posted -11 that addresses most of your comments: https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-evpn-irb-mcast-10&url2=draft-ietf-bess-evpn-irb-mcast-11&difftype=--html.

Please see zzh> below for some clarfications.


Juniper Business Use Only
-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Monday, March 4, 2024 5:20 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-irb-mcast-10: (with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-10: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRCEMrYgs$
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-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRkpiq_7Y$



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


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-irb-mcast-10

Thank you for the work put into this document.

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

Special thanks to Mankamana Mishra for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. The use of the old template was a trip to the past ;-) (but this is OK).

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-bess-evpn-irb-mcast-09-intdir-telechat-haberman-2024-02-22/__;!!NEt6yMaO-gk!DhD7utIBY1vYH8I6IZ-ox9QnO5417w-hM2_79mAuuG1tuAnmpU8_FHmV8LwOOSBhg3VEPCoRknVNCiM$
(and I have read Jeffrey's replies, thanks)

I hope that this review helps to improve the document,

Zzh> It definitely helps!

Regards,

-éric

# COMMENTS (non-blocking)

## Author count

Just a minor comment, there are 6 authors while the limit is usually 5. Not a big deal at all for me, and it is justified in the shepherd's write-up.

## Readability

In several sections, a network diagram would help the reader.

Zzh> I had added one diagram per Brian's comment. If you can point me to more sections, I can try to add more.

This I-D solves a hard-problem, and it is not an easy read. I sincerely hope that the existing implementations (per shepherd's write-up) are interoperable and follow this specification.

Zzh> There was an interop testing done just last week as part of EANTC.

## Section 1.1

The abstract mentions MPLS and IP as backbone while this section is only about IP. Which one is correct ?

Zzh> I changed to "IP or MPLS backbone". The emphasis is that the backbone is L3 (not L2).

Please move the BCP 14 template outside of `background`

Zzh> Done.

## Section 1.1.1

Is having TS1 and TS2 on the same BD enough to ensure that mcast traffic is received ? Should the layer-2 infrastructure also be aware of the mcast traffic (i.e., MLD snooping)? After all, the "B" in "BD" is only for broadcast.

Zzh> Yes. By default, multicast traffic is treated as broadcast and flooded everywhere. With snooping, the flooding is turned into selective forwarding (only to where it needs to go).

Would the infinite loop also happen with plain broadcast frames ?

Zzh> Yes. I think "This is particularly important for multicast" is to compare to unicast, not to broadcast.

## Section 1.1.2

`The TTL field of the IP datagram` let's rather use "hop limit" in 2024.

Zzh> I was planning to do a whole change of TTL to "hop limit" but it does not read well in some places. Given that TTL is a well know term, I'd like to stay with it.

## Section 1.1.3

The readers would probably welcome some explanations of why PIM/MLD is not enough in the case of inter-subnet mcast traffic. Or a promise that the explanations are deferred to section 1.2. Or the leading text moved to section 1.2.

Zzh> IGMP/MLD is only used for hosts on a subnet to signal to routers that they need to receive certain multicast traffic. Inter-subnet multicast traffic requires PIM. I'll see if I could add some text somewhere.

## Section 1.3

Which header is it in `header checksum is not changed` ? (IPv6 header has not checksum or is it the L4 checksum ?)

Zzh> I think it's Ether header checksum. I don't think IPv4 header checksum is changed.

The whole section appears like WG requirements for a solution, unsure whether this text belongs to the solution document as these points are no more requirements, but properties of the solution described in this I-D.

Zzh> They're the requirements that the authors imposed when they designed the solution. Over the course, they have been debated in the WG even though there is no official seal of approval (other than that the doc has progressed so far - so I would say they are reasonable requirements).

## Section 1.4

Any reason why deviate from RFC 5952 in `FF02/16` ? (applies in other places as
well)

zzh> RFC5952 is for address examples used in documents and it does not talk about multicast at all. Here FF02/16 is specifically for an assigned block of IPv6 multicast address with the link-local scope. I do notice that the IPv4 link-local block is 224/24 not 224/8. I've fixed that.

Unsure how to change the document but isn't it a little weird to have terminology so late in the document after so many acronyms have been defined?
Probably a matter of taste.

Zzh> I don't know how we ended up with this 😊 But I moved it to the very beginning.

Suggest to also define "EVI" on its own rather than being hidden in the definition of another term.

Zzh> Done.

## Section 1.5.1

Where is IMET specified ? The text would benefit of indicated what it is (and adding a clear source of definition == RFC 7432).

Zzh> The text does say "[RFC7432] specifies that PE1 must originate an Inclusive Multicast Ethernet Tag (IMET) route for that BD ...".

Is `Selective Multicast Ethernet Tag` specified by this document. It is unclear from the text.

Zzh> I added reference to RFC9251.

## Section 3.2.3

Should the "AR" acronym be expanded first (even if guessable).

Zzh> Done.

## Section 3.3

Only IGMP is used in this section, should it be stated in the intro that "MLD"
is used everywhere as a shorthand of "MLD or IGMP" ?

zzh> I changed all lone "IGMP" to "IGMP/MLD".

## Section 4.1

Should there be an expansion for RPF ?

Zzh> Done. I also addressed the NITs below.
Zzh> Thanks!
Zzh> Jeffrey

# NITS (non-blocking / cosmetic)

## ethernet vs. Ethernet

Usually Ethernet is capitalised.

## Link-local

Usually, when used as an adjective, "link-local" is written with an hyphen.