Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

From: John E Drake <[email-masked]>
Date: Tue, 18 Jan 2022 15:28:11 +0000

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, October 21, 2021 10:08 PM
> To: John E Drake <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-
> 13: (with DISCUSS and COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> Thanks for helping clarify.  Also inline.
> 
> On Thu, Oct 21, 2021 at 06:35:43PM +0000, John E Drake wrote:
> > Ben,
> >
> > Comments inline.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk via Datatracker <[email-masked]>
> > > Sent: Wednesday, October 20, 2021 8:49 PM
> > > To: The IESG <[email-masked]>
> > > Cc: [email-masked];
> > > [email-masked]; [email-masked]; [email-masked]
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-
> 13:
> > > (with DISCUSS and COMMENT)
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-
> > > ballot-
> > > positions/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSRrxQJ1U$
> > > 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-i
> > > etf-bess-
> > > evpn-igmp-mld-proxy/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSbOB2k3E$
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > (1) Apparently each PE is supposed to store version flags for each
> > > other PE in the EVI (I guess on a per-route basis?), but this is
> > > mentioned just once, in passing, in step 2 of the Leave Group procedures in
> §4.1.2.
> >
> > [JD]  The first hop PE keeps track of which IGMP or MLD versions are active on
> the ESes to which it is attached and announces this via the BGP SMET route.
> 
> Yes.  Should this statement (or something like it) be in the document itself?
> (Where?)

[JD] Would you please review sections 4 and 5 of the -16 (https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-4, https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-5) and see if they are is clear enough?

> 
> > > Similarly, §6.1 defines, somewhat in passing, some "local IGMP
> > > Membership Request (x,G) state" that must be maintained in some cases.
> > > Let's discuss whether it's appropriate/useful to have a general
> > > introductory section that covers what new state PEs are expected to
> > > retain as part of supporting IGMP/MLD proxying.  Maybe the answer is
> > > "no", but I would like to have the conversation.
> >
> > [JD]  Section 6 generalizes the notion of a first hop PE to be the set of multi-
> homed PEs attached to a given ES.  Section 6
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-13*section-6__;Iw!!NEt6yMaO-
> gk!WAMtLTp8pHMhjeyfDY13FOVPAqTuQaEqcCu8hQOf-
> GMscsBgaRFDzERgy6ZEfS8$ ) explains why the multi-homed PEs need to
> synchronize state and section 6.1 explains what is that state:
> 
> Rereading it, it does explain the need for state synchronization; thanks for
> pointing that out.  However, it does not appear to use or introduce the specific
> term that the subsequent subsections are using to refer to that state.  It seems
> like it could be useful to have a defined term for this state, to help readers make
> the connection between the need to track the state and where that state is
> referenced in the subsequent procedures.
> 
> >  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 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).
> >
> > i.e., IGMP Membership Request (x,G) state is the union of the local IGMP Join
> (x,G) state and the installed IGMP Join Synch route.
> 
> This would be a great start to a definition for such a defined term that I propose
> above.

[JD]  Would you please review section 6 of the -16 version (https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-6) and see if it is clear enough? 

> 
> > >
> > > (2) I am not sure if the body text is consistent with what is being
> > > allocated from IANA.  §8 describes PEs that are not using ingress
> > > replication as being identifiable as """any PE that has advertised
> > > an Inclusive Multicast Tag route for the BD without the "IGMP Proxy
> > > Support" flag""", but the IANA considerations allocate flags for
> > > both IGMP Proxy Support and MLD Proxy Support.  Is a PE that
> > > advertises MLD Proxy Support but not IGMP Proxy Support to be treated as
> not using ingress replication, as the literal interpretation of this text would
> require?
> > > Similarly, §9.2.1 and §9.3.1 include restrictions on indication of
> > > support for "IGMP Proxy" with no mention of "MLD Proxy".
> >
> > [JD]  It should be either IGMP or MLD Proxy Support
> 
> Yes.  Hopefully this is easy to insert into the document itself.

[JD]  Would you please review sections 8 and 9.4 of the -16 version (https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-8, and https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9.4) and see if they are is clear enough?

> 
> Thanks again,
> 
> Ben
> 
> > > I do see that there is a generic disclaimer at the end of Section 3
> > > but the way it is written does not actually seem to cover this usage.
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > 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://urldefense.com/v3/__https://www.rfc-
> > > editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSLlJ3XlU$
> > > 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).
> > >
> > >