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

[John E Drake <[e-mail]>]

Ben,

Comments inline below.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Friday, February 4, 2022 8:09 PM
> To: John E Drake <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> 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,
> 
> My apologies for taking a few weeks to reply; I was sick when this came in and a
> bunch of stuff piled up, which has taken some time to get back to.
> I can only take a small amount of solace by noting that at least this is not the
> last DISCUSS blocking the document from approval.
> 
> Inline...
> 
> On Tue, Jan 18, 2022 at 03:28:11PM +0000, John E Drake wrote:
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <[e-mail]>
> > > Sent: Thursday, October 21, 2021 10:08 PM
> > > To: John E Drake <[e-mail]>
> > > Cc: The IESG <[e-mail]>;
> > > [e-mail];
> > > [e-mail]; [e-mail]; [e-mail]
> > > 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 <[e-mail]>
> > > > > Sent: Wednesday, October 20, 2021 8:49 PM
> > > > > To: The IESG <[e-mail]>
> > > > > Cc: [e-mail];
> > > > > [e-mail]; [e-mail]; [e-mail]
> > > > > 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-i
> > > > > esg-
> > > > > 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/dra
> > > > > ft-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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-16*section-4__;Iw!!NEt6yMaO-gk!U0f6li3uRjd2faD-
> rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_GYAo7RM$ ,
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-16*section-5__;Iw!!NEt6yMaO-gk!U0f6li3uRjd2faD-
> rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_8b_wkkE$ ) and see if they are is
> clear enough?
> 
> You ask if they are "clear enough?"  The changes to clarify which steps are done
> by which PEs are quite helpful, and thank you for that.  But they are not really
> addressing the issue that was bothering me.  Nevertheless, in light of this discuss
> point being raised in order to have a conversation, I guess they are clear
> *enough*, but just barely, and there's plenty of room to make them more clear.
> 
> In short, what bothers me here is that we say something like "compare ...
> with its per-PE stored version flags", but we never concretely say "store some
> per-PE version flags" anywhere.  Now, this is BGP, so of course you're storing
> what you got and from whom, but writing it in the way it's currently stated
> makes the reader work pretty hard to figure out what's going on.  If we said
> something like (with the caveat that I am surely using the wrong terminology)
> "compare ... with the version flags from the corresponding saved EVPN SMET
> route in the BGP session with this PE", that would be very clear about what was
> saved and why.
> 
> We could also go further and talk about the information model concretely, a la:
> 
> % The goal of IGMP and MLD proxying is to make the EVPN behave seamlessly
> for % the tenant systems with respect to multicast operations, while using a
> more % efficient delivery system for signaling and delivery across the VPN.
> % Accordingly, group state must be tracked synchronously among the PEs %
> serving the VPN, with join and leave events propagated to the peer PEs, and %
> each PE tracking the state of each of its peer PEs with respect whether % there
> are locally attached group members (and in some cases, senders), what %
> version(s) of IGMP/MLD are in use for those locally attached group members, %
> etc.  In order to perform this translation, each PE acts as an IGMP router % for
> the locally attached domain, and maintains the requisite state on % locally
> attached nodes, sends periodic membership queries, etc.  The role % of EVPN
> SMET route propagation is to ensure that each PE's local state is % propagated
> to the other PEs so that they share a consistent view of the % overall IGMP
> Membership Request and Leave Group state.  It is important to % note that the
> need to keep such local state can be triggered by either % local IGMP traffic or
> BGP EVPN signaling.  In most cases a local IGMP event % will need to be signaled
> over EVPN, though state initiated by received EVPN % traffic will not always
> need to be relayed to the locally attached domain.

[JD]  We can add this text to section 4. 
> 
> > >
> > > > > 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/d
> > > raft-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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-16*section-6__;Iw!!NEt6yMaO-gk!U0f6li3uRjd2faD-
> rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_dTYpjPA$ ) and see if it is clear
> enough?
> 
> Even if you don't want to use the "concrete information model" approach I
> outline above, I think this text would be much clearer with the following change
> in §6:
> 
> OLD:
>    Therefore, all PEs attached to a given ES must coordinate IGMP
>    Membership Request and Leave Group (x,G) state, where x may be either
>    '*' or a particular source S, for each BD on that ES. [...]
> 
> NEW:
>    Therefore, all PEs attached to a given ES must coordinate IGMP
>    Membership Request and Leave Group (x,G) state, where x may be either
>    '*' or a particular source S, for each BD on that ES.  Each PE has a
>    local copy of that state, and the EVPN signaling serves to synchronize
>    state across PEs.

[JD]  This is fine. 

> 
> But is it "clear enough" as-is?  Again, just barely, and I will demote this topic to a
> COMMENT-level remark.
> 
> > >
> > > > >
> > > > > (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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-16*section-8__;Iw!!NEt6yMaO-gk!U0f6li3uRjd2faD-
> rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_U63FOVo$ , and
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-16*section-9.4__;Iw!!NEt6yMaO-
> gk!U0f6li3uRjd2faD-rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_QXUa-Og$ )
> and see if they are is clear enough?
> 
> I think they are still problematic in this regard.
> 
> §8 now talks about an "IGMP or MLD Proxy Support" flag, but we actually have
> separate "IGMP Proxy Support" and "MLD Proxy Support" flags.
[
JD]  We will fix this. 

> 
> The §9.2.1 and 9.3.1 text still has discussion relating to "indicate that it
> supports" proxying of one or the other multicast protocols, and §9.4 has a
> paragraph that I paraphrase as "if it supports IGMP proxy, it MUST set the IGMP
> proxy flag to 1".  But the disclaimer in §3 is specifically worded to only cover
> "IGMP Membership Report" as including MLD Membership Report, and to have
> version genericity within IGMP and within MLD.  Being specific to the
> Membership Report in this way means that it does *not* come into effect for
> discussions of "support for IGMP proxy" or "support for MLD proxy", which is
> what seems problematic to me, here.
> 
> It seems like it ought to be pretty straightforward to craft some text that
> expands the disclaimer in §3 to cover things like "Likewise, when there is text
> considering whether a PE indicates support for IGMP proxying, the
> corresponding behavior has a natural analogue for indication of support for
> MLD proxying, and the analogous requirements apply as well".

[JD]  We will add this. 

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