Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)
draft-ietf-bess-evpn-igmp-mld-proxy-21

Generally no useful comments that others haven't already made.  Thank
you for your patience, since I had pushed this out another week.

[S4, comment]

* I feel like some representative diagram to refer to throughout the
  document might be useful earlier in the document, even if it's just
  duplication of Figure 1 from section 5.

[S9.*]

* Should it be said that if the Multicast Source Length is not zero
  then it MUST be equal to the Multicast Group Length?  I.e. no
  mixing and matching IPv4 and IPv6 source/group addresses by accident?

Thanks for the work on this document.

As in draft-ietf-bess-evpn-optimized-ir, I have to comment on the overuse of abbreviations and the assumptions that the reader is familiar with all concepts and terms used make the document really hard to read for non-expert in the field. I'll also point out that having a terminology section with expansion but with no references is not as useful as one with proper descriptions and references.

Here as well, there is a several uses of SHOULD and should in a way that either is requiring more context (what are the conditions when it is acceptable to not follow the SHOULD recommendations):

   o  Reserved bits MUST be set to 0 by sender.  And receiver SHOULD
      ignore the Reserved bits.

 and cases where IMO the term would better be replaced by something else, possibly more descriptive: 

> The registration policy should be "First Come First Served".

> The registry should be initialized as follows:

I don't have any other comment that has not already been flagged by my fellow ADs: I scanned for ART issues but did not find any significant ones. (Please do fix Lars non-blocking points as well).

Francesca

Preserved from my DISCUSS on -14:

I suggest making each of the actions you want to take (there are four) into their own subsections of this section.

On revision -20:

Section 3 defines "MAC-VRF", but this term appears nowhere in the document.  It also defines "PMSI", which is not used anywhere else except in the definition of "S-PMSI", so I suggest merging these.  Lastly, the entire section is sorted alphabetically except for the last two entries.

** Section 12.  Recommend being clearer on the purpose of the long list of SecCon references (and few typos)

OLD
TThis document does not add any new security considirattions, Same
   security considerations as [RFC7432], [RFC2236], [RFC3376],
   [RFC2710], [RFC3810], [RFC6513], [RFC6514] are applicable.

NEW (feel free to polish)
This document describes a means to efficiently operate IGMP and MLD on a subnet constructed across multiple PODs or DCs via an EVPN solution.  The security considerations for the operation of the underlying EVPN and BGP substrate are described in [RFC7432], and specific multicast considerations are outlined in [RFC6513] and [RFC6514].  The EVPN and associated IGMP proxy provides a single broadcast domain so the same security considerations of IGMPv2 [RFC2246], IGMPv3 [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] apply.

** Editorial
-- Section 9.4.  Typo. s/associated associated/associated/

-- Section 11.  Typo. s/implemention/implementation/

I had number of notes on when I was reading the -13 version, I can see many of those are already addressed in -14 version. Rest are nits,skipping those.
I would however, like to know the consensus around IPR. The shepherd or chairs or AD, if any one can provide more information on that that will be great.

As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate twice the ballot status of this document and with the -19 revision all my previous blocking DISCUSS points are addressed. Thank you to the authors.

See below this line for updated version
----------------------------------------------

Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast one.

Please find below some blocking DISCUSS points (probably easy 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 Stéphane Litkowski for his shepherd's write-up about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric


== Archived DISCUSS (addressed/fixed in -19) ==

The text covers in details how to map MLD/IGMP into BGP routes but does not say a word on how to recreate the MLD/IGMP packets. Should there be any such specification (e.g., in section 4.1) ?

Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses.

-- Abstract --
While this point is pretty light for a blocking DISCUSS, let's fix it:
- the abstract should also mention MLD and not only IGMP
- what are 'the above services' ?

-- Section 1 --
In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear.

== COMMENT ==

A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ...

-- Section 1 --
When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different.

-- Section 3 --
(Addressed in -18) Is there any reason why the terminology is not alphabetically sorted ?

(Addressed in -18) Please also add 'BD'.

(Addressed in -18) Usually a terminology section is not only about acronym expansions but also about definitions.

-- Section 4.1 --
What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ?

-- Section 4.2 --
May be that I overlooked it, but what is a 'proxy querier' ?

What is the difference between "EVPN core" and "MPLS/IP core" ?

-- Section 5.1 --
(Addressed over email) What is "viz" ? (Sorry not being a native English speaker)

-- Section 8 --
(Addressed over email) Is there a difference between (*, G) and (x, G) ?

-- Section 9.1 --
(Addressed in -18) Please formally specify "IE" as "include/exclude" (if not mistaken).

I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ?

(Addressed in -18) Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST".

-- Sections 9.1, 9.2 --
The flags description appears to be different in the text while it seems to me that they have the same semantics.

Thanks for addressing my previous Discuss points.

COMMENT section originally posted on the -13 retained below, unchanged.
Some content may be stale.
=======================================================================

As one of the directorate reviewers noted (and Éric promoted to a
DISCUSS), this document does not really give any specific description of
how an EVPN PE should construct outgoing IGMP/MLD messages to send out
on its ACs as a result of receiving EVP information over BGP.  From a
brief examination of the relevant IGMP messages, it seems that the EVPN
messages might actually contain information to populate literally all
the IGMP fields, but this is probably worth mentioning explicitly.  In
particular, guidance might be interesting for (e.g.) IGMPv3, that lets
multiple Group Records be included in a single Membership Report.
(Pedantically, such IGMPv3 multiplexing might also require phrasing
changes for the reverse process, taking IGMP and constructing EVPN
routes, since we refer to (e.g) "the Group address of the IGMP
Membership Report" in places, and that is not a well-defined concept in
the absence of some text indicating group-by-group processing.)

Abstract

   This document describes how to support efficiently endpoints running
   IGMP for the above services over an EVPN network by incorporating
   IGMP proxy procedures on EVPN PEs.

I see Lars already noted the dangling reference to "above services".
That really needs to be fixed before approval, and even looking at the
diff from -12 to -13 does not give me a clear picture of what to suggest
as a rewrite.

Section 1

I strongly suggest mentioning and referencing some of the core
technologies that readers are assumed to be familiar with (e.g., RFC
7432 for EVPN, RFC 6514 for various tunnel types including Ingress
Replication).  At present the document is quite unfriendly to a reader
from an outside field, who has little to no indication as to what
background material is required in order to be able to make sense of
this document.

   In DC applications, a point of delivery (POD) can consist of a

Data Center is not marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and needs to
be expanded on first use.

   2.  Distributed anycast multicast proxy: it is desirable for the EVPN
       network to act as a distributed anycast multicast router with

I honestly don't know what a "distributed anycast multicast router" is
supposed to be.  Google finds only a handful of instances of that
(quoted) phrase, most of which can be traced back to this document.
There is a similar phrase in §4.2 that perhaps clarifies that the
collection of EVPN PEs is intended to function as a distributed
multicast router (that is perhaps in some sense transparent to the CEs).
But how does the "anycast" part come into play?  How is the anycast IP
address assigned, and which protocol messages is it conveyed in?

Section 3

I suggest adding SMET to the terminology listed here.

   o  Ethernet Segment (ES): When a customer site (device or network) is
      connected to one or more PEs via a set of Ethernet links.

That looks like an extremely unconventional definition for "Ethernet
Segment".

   Membership Report too.  Similarly, text for IGMPv2 applies to MLDv1
   and text for IGMPv3 applies to MLDv2.  IGMP / MLD version encoding in
   BGP update is stated in Section 9

I suggest stating explicitly that this equivalence is possible because
the indicated versions provide analogous functionality for IPv4 and
IPv6, respectively.

Section 4.1.1

       is considered as a new BGP route advertisement.  When different
       version of IGMP join are received, final state MUST be as per
       section 5.1 of [RFC3376].  At the end of route processing local
       and remote group record state MUST be as per section 5.1 of
       [RFC3376].

I interpret "different version of IGMP join" as "join messages from
different IGMP protocol versions", which makes this reference to RFC
3376 make no sense to me -- the referenced section does not talk about
multiple protocol versions at all.  Please clarify what behavior from
RFC 3376 is being referenced.

       logged.  If the v3 flag is set (in addition to v2), then the IE
       flag MUST indicate "exclude".  If not, then an error SHOULD be
       logged.  [...]

It's great to say that this is an error condition and should be logged.
What does the recipient actually do while processing the message?
An RFC 7606 named behavior would be nice.

Section 4.2

   As mentioned in the previous sections, each PE MUST have proxy
   querier functionality for the following reasons:

I'm not really sure which previous mentions this is supposed to refer
to.

Section 6.2.1

Just to confirm: the PE receiving a BGP Leave Synch route does *not*
produce local IGMP Query messages, on the assumption that the PE that
did receive the Leave locally has already done so?  (I don't think this
necessarily needs to be written out in the document itself; I just want
to confirm my understanding.)

Section 6.3

   A PE which has received an IGMP Membership Request would have synced
   the IGMP Join by the procedure defined in section 6.1.  If a PE with
   local join state goes down or the PE to CE link goes down, it would
   lead to a mass withdraw of multicast routes.  Remote PEs (PEs where

Can we have greater clarity on "would lead to"?  Are there actually
routes that will be withdrawn and we are just ignoring the consequences
of that for the purposes of local state, using some heuristic (as
mentioned later) for detecting whether a mass-withdraw is due to a
failure at a peer?  Or is the mass withdraw a hypothetical scenario that
the procedures described here fully avoid?

   these routes were remote IGMP Joins) SHOULD NOT remove the state
   immediately; instead General Query SHOULD be generated to refresh the
   states.  There are several ways to detect failure at a peer, e.g.
   using IGP next hop tracking or ES route withdraw.

Does each PE initiate the General Query, in this scenario?

Section 7

   Note that to facilitate state synchronization after failover, the PEs
   attached to a multihomed ES operating in Single-Active redundancy
   mode SHOULD also coordinate IGMP Join (x,G) state.  In this case all

What are the drawbacks of not performing such synchronization?
Alternately, in what cases does it make sense to not perform
synchronization (so that the guidance is SHOULD rather than MUST)?

Section 9.1

It might be nice to mention that the length fields are measured in bits
here in this section, where the NLRI format is laid out, in addition to
§9.1.1 where the procedures for constructing it are laid out.

   o  If route is used for IPv6 (MLD) then bit 7 indicates support for
      MLD version 1.  The second least significant bit, bit 6 indicates

How does the receiver know if the route is being used for IPv6?  (Also
applies in §9.2, 9.3)

Section 9.1.1

Is there any requirement for consistency about using IPv4 vs IPv6
addresses in all three address fields?  The description given here would
seem to allow mixing address families, but I don't really expect that to
work in practice.

   version and any source filtering for a given group membership.  All
   EVPN SMET routes are announced with per- EVI Route Target extended
   communities.

Is there a good reference for discussion of these associated ECs?

Section 9.1.2

   PE2 to receive multicast traffic.  In this case PE2 MUST originate a
   (*,*) SMET route to receive all of the multicast traffic in the EVPN
   domain.  To generate Wildcards (*,*) routes, the procedure from
   [RFC6625] SHOULD be used.

Is the PE expected to identify this case based on protocol messages
received at runtime (e.g., any PIM at all), or is this external
configuration?

Section 9.3.1

   Maximum Response Time is value to be used while sending query as
   defined in [RFC2236]

Is it actually right to describe this as "while sending query
[messages]"?  My understanding is that a PE receiving this route over
BGP would in fact *not* actually send IGMP Query messages, but simply
use the time to set a timer and potentially clear up state if certain
conditions are met at the end of the period in question.

Section 10

Just to confirm my understanding here: in the immediate leave case, the
Leave Synch route will be advertised just for the "delta" period of time
described in §6.2 and then withdrawn?

   IGMP MAY be configured with immediate leave option.  This allows the

Is there a suitable reference for "immediate leave"?  I did not see much
relevant in RFCs 2236 and 3376.

Section 12

I support Roman's point about detailing which aspects are covered in
which referenced RFCs.

I also noted that the "delta" value used in the Last Member Query
process must be configured on each node, and to the same value.  Such
requirement for identical configuration opens up the chance for skew,
and sometimes any such skew is security-relevant and must be documented
in the security considerations.  However, I'm not sure that that's the
case, here, as it seems that skew would mostly only serve to cause a
brief "blip" where a PE drops its group state only to recreate it when a
report shows up later.  Is there a scenario where the skew goes the
other way, and a PE leaves group state in place indefinitely that should
have been dropped?

Section 16.1

Since we only reference RFC 4684 to say that its procedures are not
applicable to what we describe, it seems like it could be classified as
only an informative reference.

NITS

We seem quite inconsistent about whether we write "BCP Leave Synch
route" or "IGMP Leave Synch route" (but I believe these are both
supposed to be the same thing).

Section 1

   communication and orchestration.  However, EVPN is used as standard
   way of inter-POD communication for both intra-DC and inter-DC.  A

intra-DC and inter-DC are both adjectives that need to modify some noun.
Please supply such a noun (e.g., "traffic").

   These hosts express their interests in multicast groups on a given
   subnet/VLAN by sending IGMP Membership Reports (Joins) for their
   interested multicast group(s).  [...]

I think that this phrase "IGMP Membership Reports (Joins)" is intended
to serve some cross-protocol clarification role (e.g., "Join" is used by
IGMPv3 and MLD but not IGMPv2).  Since this is the first place where we
use that formulation, some additional text to clarify the shorthand
seems in order.

Section 3

   o  BD: Broadcast Domain.  As per [RFC7432], an EVI consists of a
      single or multiple BDs.  In case of VLAN-bundle and VLAN-aware

RFC 7432 spells "VLAN Bundle" with no hyphen.

   o  Single-Active Redundancy Mode: When only a single PE, among all
      the PEs attached to an Ethernet segment, is allowed to forward
      traffic to/from that Ethernet segment for a given VLAN, then the
      Ethernet segment is defined to be operating in Single-Active
      redundancy mode.

   o  All-Active Redundancy Mode: When all PEs attached to an Ethernet
      segment are allowed to forward known unicast traffic to/from that
      Ethernet segment for a given VLAN, then the Ethernet segment is
      defined to be operating in All-Active redundancy mode.

Is it important that the second definition only covers "unicast traffic"
but the former uses the unqualified term "traffic"?

   o  OIF: Outgoing Interface for multicast.  It can be physical
      interface, virtual interface or tunnel.

s/physical/a physical/

Section 4

   The IGMP Proxy mechanism is used to reduce the flooding of IGMP
   messages over an EVPN network similar to ARP proxy used in reducing

"similarly to how ARP proxy is used"

   speakers.  The information is again translated back to IGMP message
   at the recipient EVPN speaker.  Thus it helps create an IGMP overlay

"IGMP messages" plural, to match the previous sentence.

Section 4.1.1

   1.  When the first hop PE receives several IGMP Membership Reports
       (Joins), belonging to the same IGMP version, from different
       attached hosts for the same (*,G) or (S,G), it SHOULD send a
       single BGP message corresponding to the very first IGMP
       Membership Request (BGP update as soon as possible) for that
       (*,G) or (S,G).  [...]

What is an "IGMP Membership Request"?  Is this just a typo for Report?

                        This is because BGP is a stateful protocol and
       no further transmission of the same report is needed.  If the
       IGMP Membership Request is for (*,G), then multicast group
       address MUST be sent along with the corresponding version flag
       (v2 or v3) set.  [...]

(ditto)

                                   If the IGMP Join is for (S,G), then
       besides setting multicast group address along with the version
       flag v3, the source IP address and the IE flag MUST be set.  It

"setting the multicast group address" (add "the").

   2.  When the first hop PE receives an IGMPv3 Join for (S,G) on a
       given BD, it SHOULD advertise the corresponding EVPN Selective
       Multicast Ethernet Tag (SMET) route regardless of whether the

Forward reference Section 9.1, please?

   4.  When the first hop PE receives an IGMP version-X Join first for
       (*,G) and then later it receives an IGMPv3 Join for the same
       multicast group address but for a specific source address S, then
       the PE MUST advertise a new EVPN SMET route with v3 flag set (and
       v2 reset).  The IE flag also need to be set accordingly.  Since

What does "v2 reset" mean?  "The v2 flag is not set" or "the v2 flag is
cleared"?  I recommend not using the word "reset" in this context as
it's ambiguous.

   7.  Upon receiving EVPN SMET route(s) and before generating the
       corresponding IGMP Membership Request(s), the PE checks to see

"Membership Request" again.

       whether it has any CE multicast router for that BD on any of its
       ES's . The PE provides such a check by listening for PIM Hello
       messages on that AC (i.e, ES,BD).  If the PE does have the
       router's ACs, then the generated IGMP Membership Request(s) are
       sent to those ACs.  If it doesn't have any of the router's AC,
       then no IGMP Membership Request(s) needs to be generated.  [...]

The writing here seems rather jumbled, though perhaps I just
misunderstand the terminology in question.  Assuming that a PE router
has one or more ACs connecting it to one or more CE routers (possibly in
a many-to-many fashion), then I don't see how we can write about
the PE "have[ing] [any of] the router's ACs" -- wouldn't the relevant
criterion be that the AC has CE routers participating in multicast?

Section 4.1.2

   2.  When a PE receives an EVPN SMET route for a given (*,G), it
       compares the received version flags from the route with its per-
       PE stored version flags.  If the PE finds that a version flag
       associated with the (*,G) for the remote PE is reset, then the PE

[same comment about the word "reset" as above]

       MUST generate IGMP Leave for that (*,G) toward its local
       interface (if any) attached to the multicast router for that

Probably "router(s)" since there could be more than one.
And "interface(s)" as well?

       multicast group.  It should be noted that the received EVPN route
       MUST at least have one version flag set.  If all version flags
       are reset, it is an error because the PE should have received an

["reset" again]

Section 5

   Consider the EVPN network of Figure-1, where there is an EVPN
   instance configured across the PEs shown in this figure (namely PE1,
   PE2, and PE3).  Let's consider that this EVPN instance consists of a
   single bridge domain (single subnet) with all the hosts, sources, and

This is the only instance of the word "bridge" in this document (but
"broadcast domain" appears as a defined term).  Is "BD" intended?

Section 5.1

   all these local ports are associated with the hosts.  PE1 sends an
   EVPN Multicast Group route corresponding to this join for (*,G1) and
   setting v2 flag.  This EVPN route is received by PE2 and PE3 that are

s/setting/sets the/

   information.  However, when it receives the IGMPv3 Join from H3 for
   the same (*,G1).  Besides adding the corresponding port to its OIF

incomplete sentence; could add ", EVPN messaging is required" to connect
to the next sentence.

Section 6

   either DF or non-DF; i.e., different IGMP Membership Request messages

"Membership Request" again.

   needed.  All-Active multihoming PEs for a given ES MUST support IGMP
   synchronization procedures described in this section if they need to
   perform IGMP proxy for hosts connected to that ES.

Can we unpack the actual requirement here?  Is it: "if a given ES uses
all-active multihoming, in order for IGMP proxying to be used on that
ES, all the PEs on that segment must support the synchronization
procedures described in the following subsections"?
The analogous text in §6.2 seems more clear to me on what the
preconditions are.

Also, s/MUST support/MUST support the/ and s/IGMP proxy/IGMP proxying/

Section 6.1

   belongs.  If the PE doesn't already have local IGMP Membership
   Request (x,G) state for that BD on that ES, it MUST instantiate local
   IGMP Membership Request (x,G) state and MUST advertise a BGP IGMP

"Membership Request", albeit perhaps defensible since it is "state" and
not a message being sent.

   Join Synch route for that (ES,BD).  Local IGMP Membership Request
   (x,G) state refers to IGMP Membership Request (x,G) state that is
   created as a result of processing an IGMP Membership Report for
   (x,G).

It's typically easier for the reader when the new term is defined before
it is used, rather than after.  Especially so when the defined term is
similar to an existing, well-established, term that means something
else.

Section 9.1

   o  This EVPN route type is used to carry tenant IGMP multicast group
      information.  The flag field assists in distributing IGMP
      Membership Report of a given host for a given multicast route.
      The version bits help associate IGMP version of receivers
      participating within the EVPN domain.

   o  The include/exclude bit helps in creating filters for a given
      multicast route.

Is "assists" and "helps" really the terminology we want to use when this
information is literally required in order to construct the relevant
IGMP messages?  (Similarly for the subsequent subsections.)

Section 9.1.1

   The Originator Router Address is the IP address of router originating
   this route.  The SMET Originator Router IP address MUST match that of
   the IMET (or S-PMSI AD) route originated for the same EVI by the same
   downstream PE.

References for IMET and S-PMSI AD might be nice.

   The Flags field indicates the version of IGMP protocol from which the
   Membership Report was received.  It also indicates whether the

Probably "version(s)" and "Report(s)" since we encourage coalescing.

Section 9.3.1

   Maximum Response Time is value to be used while sending query as
   defined in [RFC2236]

"the value to be used while sending queries" (though see the non-nit
comment).

"Abstract", paragraph 1, comment:
>    This document describes how to support efficiently endpoints running
>    IGMP for the above services over an EVPN network by incorporating
>    IGMP proxy procedures on EVPN PEs.

It would be nice if acronyms were spelled out at least in the abstract (esp.
since it doesn't say where to go for further reading.) Also, "for the above
services"? Above where?

Section 9.4. , paragraph 6, comment:
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Type=0x06   |  Sub-Type=0x09|       Flags (2 Octets)      |M|I|
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                           Reserved=0                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Type" field is only seven bits long - that seems to be an error?

Section 9.5. , paragraph 20, comment:
>                              1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          | Type=0x06   |  Sub-Type=n   |       RT associated with EVI  |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |             RT associated with the EVI  (cont.)             |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram is only 31 bits wide?

You might want to use something like https://www.luismg.com/protocol/ to make
sure your header diagrams are accurate.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 11. , paragraph 2, nit:
-    provision to support IGMPv1.  There may be an implemention which is
+    provision to support IGMPv1.  There may be an implementation which is
+                                                           ++

Section 12. , paragraph 2, nit:
-    TThis document does not add any new security considirattions, Same
-                                                       ^  -
+     This document does not add any new security considerations, Same
+    -                                                  ^

"Table of Contents", paragraph 2, nit:
>  . . . . . . 18 9.2. Multicast Join Synch Route . . . . . . . . . . . . . . .
>                                     ^^^^^
Do not mix variants of the same word ("synch" and "sync") within a single text.

"Table of Contents", paragraph 2, nit:
> on of servers and switches are self contained and may have their own control
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3. , paragraph 18, nit:
> triggering mechanism for the PEs to setup their underlay multicast tunnels.
>                                     ^^^^^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 3. , paragraph 23, nit:
> sage at the recipient EVPN speaker. Thus it helps create an IGMP overlay subn
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 4.1.1. , paragraph 3, nit:
> et (and v2 reset). The IE flag also need to be set accordingly. Since source
>                                     ^^^^
The verb form "need" does not seem to match the subject "flag".

Section 5. , paragraph 4, nit:
> with the v3 and exclude flag set. Finally when PE1 receives the IGMPv3 Join
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Finally".

Section 5.2. , paragraph 2, nit:
> GMP Membership Report was received. Thus it MUST only be imported by the PEs
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 6.1. , paragraph 4, nit:
> ses an IGMP Leave Synch route for that that (ES,BD). This route notifies the
>                                   ^^^^^^^^^
Possible typo: you repeated a word.

Section 9.1. , paragraph 5, nit:
>  hosts by TORs. Upon receiving the hosts expression of interest of a particu
>                                    ^^^^^
An apostrophe may be missing.

Section 9.3. , paragraph 3, nit:
> not advertise this extended community so its absence indicates that the adver
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 9.3. , paragraph 12, nit:
>  for bit 15 means that PE does not supports IGMP Proxy. * Bit 14 (shown as M
>                                    ^^^^^^^^
The auxiliary verb "do" requires the base form of the verb.

Section 9.3.1. , paragraph 4, nit:
> re attached to the associated ES. Therefore these routes carry the ES-Import
>                                   ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 9.3.1. , paragraph 12, nit:
> BD. The route is said to be associated associated with that BD. For each BD,
>                             ^^^^^^^^^^^^^^^^^^^^^
Possible typo: you repeated a word.

Section 9.5. , paragraph 12, nit:
>  registration policy should be "First Come First Served". 14. Acknowledgement
>                                       ^^^^
It seems that a comma is missing.

Document references draft-ietf-bess-evpn-bum-procedure-updates-08, but -11 is
the latest available revision.

- It does not appear that you have fully addressed the TSVART comments (thanks Brian Trammell). Specifically, the (S,G) (*,G) definition is still not there.

- In the abstract, it refers to "the above services" and I have no idea what that is referring to.

- Please expand MLD, NLRI, and DF on first use or in the glossary.

(4.1.1) 1.  When the first hop PE receives several IGMP Membership Reports
       (Joins), belonging to the same IGMP version, from different
       attached hosts for the same (*,G) or (S,G), it SHOULD send a
       single BGP message corresponding to the very first IGMP
       Membership Request (BGP update as soon as possible) for that
       (*,G) or (S,G).

This is confusingly phrased, enough that I think it threw off the TSVART reviewer. There is no delay waiting for multiple joins; the PE just sends BGP for the first and ignores the rest. Or perhaps I've misunderstood? Please rephrase.

- Relatedly, if a PE receives (S, G) and later (*, G), should it withdraw the (S, G), since the latter join is a superset of the former?

(9) It appears most of the fields in 9.1 through 9.3 are identical; it would shorten things dramatically if you either had a common section defining them or simply referred to Sec 9.1. Moreover, as this appears to be cut-and-paste, there are mistakes like 9.3 referring to "joins" when it's talking about leaves.

(9) as you observe that the Source Length can be zero-length for (*,G) routes, it would be useful to say that the group length can also be zero for (*,*) joins. (it might also to constrain it so that if the group length is zero, the source length MUST also be zero, unless (S, *) joins are possible).

Hi,

Thanks for this document.  I have to say that I found that the heavier use of acronyms made this document somewhat harder to read.  I'm also not an expert in these technologies.


My main question isn't directly actionably on this document, but I wanted to check whether any updates to the EVPN YANG module are required to support this functionality, and if so, is that work in progress, or planned?


Otherwise, I just had a couple of minor comments:

On 4.1.1.  IGMP/MLD Membership Report Advertisement in BGP

   When a PE wants to advertise an IGMP Membership Report (Join) using
   the BGP EVPN route, it follows the following rules (BGP encoding
   stated in Section 9):

   1.  ....  This is because BGP is a stateful protocol and
       no further transmission of the same report is needed.  If the
       IGMP Membership Request is for (*,G), then multicast group
       address MUST be sent along with the corresponding version flag
       (v2 or v3) set.
	   
This implies to me that either the v2 or v3 flag is exclusively set, but presumably it could also be both.  Would "add/or" be better than or?


Does OIF need to be an acronym, it doesn't seem worth it, and makes the text harder to parse.  Is this a standard term used in other related docs?


5.  Operation

In the paragraph of text above the diagram, perhaps more clearly indicate that S1, S2 indicate multicast sources and R1 indicates a multicast router, and Hx indicates hosts.



9.1.  Selective Multicast Ethernet Tag Route

Rather than writing things like "second least significant bit", just writing "bit 6" would seem to be clearer.



9.1.1.  Constructing the Selective Multicast Ethernet Tag route

I was surprised that the lengths are specified in bits, not bytes.  I presume that bits are used for consistency with other encodings.

Thanks,
Rob