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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Feb 2022 17:08:45 -0800

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

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.

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

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.

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

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.

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".

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

---

From: John E Drake <[email-masked]>
Date: Mon, 7 Feb 2022 15:17:21 +0000

Ben,

Comments inline below.

Yours Irrespectively,

John

> Sent: Friday, February 4, 2022 8:09 PM
> 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...
> 
> > > Cc: The IESG <[email-masked]>;
> > > [email-masked];
> > > > > 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
> > > > > (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] Would you please review sections 4 and 5 of the -16
> 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.
> 
> 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.
> 
> % 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. 
> > > > > 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.
> > > >
> > > 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
> > > 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).
> > > >
> > > 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
> bess-evpn-igmp-mld-proxy-16*section-6__;Iw!!NEt6yMaO-gk!U0f6li3uRjd2faD-
> rySykNfIC0xL6dDVldh9DGvrvQvssauGhJcWFs1_dTYpjPA$ ) and see if it is clear
> enough?
> 
> outline above, I think this text would be much clearer with the following change
> in §6:
> 
> OLD:

[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]  Would you please review sections 8 and 9.4 of the -16 version
> 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?
> 
> §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.
> 
> expands the disclaimer in §3 to cover things like "Likewise, when there is text
> considering whether a PE indicates support for IGMP proxying, the

[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.
> > > > >
> > > > >
> > > > > As one of the directorate reviewers noted (and Éric promoted to
> > > > > a DISCUSS), this document does not really give any specific
> > > > > 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
> > > > > (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
> > > > >
> > > > > That really needs to be fixed before approval, and even looking
> > > > > at the diff from -
> > > > > 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.
> > > > >
> > > > > 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 interpret "different version of IGMP join" as "join messages
> > > > > from different IGMP protocol versions", which makes this
> > > > > reference to RFC
> > > > > 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
> > > > >
> > > > > 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
> > > > >    mode SHOULD also coordinate IGMP Join (x,G) state.  In this
> > > > > case all
> > > > >
> > > > > 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
> > > > > 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.
> > > > >
> > > > > 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
> > > > >
> > > > > 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
> > > > > 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
> > > > >
> > > > > 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
> > > > >
> > > > >        corresponding IGMP Membership Request(s), the PE checks
> > > > > to see
> > > > >
> > > > > 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
> > > > >
> > > > >        associated with the (*,G) for the remote PE is reset,
> > > > > then the PE
> > > > >
> > > > >        are reset, it is an error because the PE should have
> > > > > received an
> > > > >
> > > > > ["reset" again]
> > > > >
> > > > > Section 5
> > > > >
> > > > >    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
> > > > >
> > > > >    setting v2 flag.  This EVPN route is received by PE2 and PE3
> > > > > that are
> > > > >
> > > > > s/setting/sets the/
> > > > >
> > > > >    the same (*,G1).  Besides adding the corresponding port to
> > > > > its OIF
> > > > >
> > > > > 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
> > > > > 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
> > > > >
> > > > > 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
> > > > >

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Fri, 11 Feb 2022 16:01:51 +0000

Hi Ben,
Making the changes as you suggested. Attached diff which I would be pushing today.

One question

> separate "IGMP Proxy Support" and "MLD Proxy Support" flags.

Does IGMP or MLD Proxy Support not mean that either of them can be set / unset. Any thing specific you want to be added here ?

Mankamana

From: John E Drake <[email-masked]>
Date: Monday, February 7, 2022 at 7:17 AM
To: Benjamin Kaduk <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[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)
Ben,

Comments inline below.

Yours Irrespectively,

John

> > > > > https://urldefense.com/v3/__https://www.ietf.org/blog/handling-i<https://urldefense.com/v3/__https:/www.ietf.org/blog/handling-i>
> > > > > esg-
> > > > > ballot-
> > > > > positions/__;!!NEt6yMaO-
> > > > >
> > >
> > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/dra>
> > > > > ft-i
> > > > > etf-bess-
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->

[JD]  This is fine.

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->
[
JD]  We will fix this.

[JD]  We will add this.

> > > > > https://urldefense.com/v3/__https://www.rfc-<https://urldefense.com/v3/__https:/www.rfc->
> > > > >        flag v3, the source IP address and the IE flag MUST be set

---

From: John E Drake <[email-masked]>
Date: Fri, 11 Feb 2022 16:12:59 +0000

Hi,

Here are my proposed changes:

8<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-06#section-8>.  Selective Multicast Procedures for IR tunnels

   If an ingress PE uses ingress replication, then for a given (x,G)
   group in a given BD:

   1.  It sends (x,G) traffic to the set of PEs not supporting IGMP
       Proxy.  This set consists of any PE that has advertised an
       Inclusive Multicast Tag route for the BD without the "IGMP Proxy
       Support" flag.

*****JD  This set consists of any PE that has advertised an IMET route for the BD
without a  Multicast Flags extended community or with a Multicast Flags extended
community in which neither the IGMP Proxy support nor the  MLD Proxy support
flags are set.

   2.  It sends (x,G) traffic to the set of PEs supporting IGMP Proxy
       and having listeners for that (x,G) group in that BD.  This set
       consists of any PE that has advertised an Inclusive Multicast Tag
       route for the BD with the "IGMP Proxy Support" flag and that has
       advertised a SMET route for that (x,G) group in that BD.

*****JD  This set consists of any PE that has advertised an IMET route for the BD
with a Multicast Flags extended community in which the IGMP Proxy support and/or
the  MLD Proxy support flags are set and that has advertised a SMET route for that (x,G)
group in that BD.

   If an ingress PE's Selective P-Tunnel for a given BD uses P2MP and
   all of the PEs in the BD support that tunnel type and IGMP proxy,

*****JD and IGMP and/or MLD proxy,

   then for a given (x,G) group in a given BD it sends (x,G) traffic
   using the Selective P-Tunnel for that (x,G) group in that BD.  This
   tunnel includes those PEs that have advertised a SMET route for that
   (x,G) group on that BD (for Selective P-tunnel) but it may include
   other PEs as well (for Aggregate Selective P-tunnel).

9.4<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-06#section-9.4>.  Multicast Flags Extended Community

   The 'Multicast Flags' extended community is a new EVPN extended
   community.  EVPN extended communities are transitive extended
   communities with a Type field value of 6.  IANA will assign a Sub-
   Type from the 'EVPN Extended Community Sub-Types' registry.

   A PE that supports IGMP proxy on a given BD MUST attach this extended
   community to the Inclusive Multicast Ethernet Tag (IMET) route it
   advertises for that BD and it MUST set the IGMP Proxy Support flag to
   1.  Note that an [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] compliant PE will not advertise this
   extended community so its absence indicates that the advertising PE
   does not support IGMP Proxy.

*****JD     A PE that supports IGMP and/or MLD Proxy on a given BD
MUST attach this extended community to the IMET route it advertises
advertises for that BD and it MUST set the IGMP and/or MLD Proxy
Support flags to 1.  Note that an [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] compliant PE will not advertise this
extended community so its absence indicates that the advertising PE
does not support either IGMP or MLD Proxy.

Yours Irrespectively,

John

Juniper Business Use Only
From: Mankamana Mishra (mankamis) <[email-masked]>
Sent: Friday, February 11, 2022 11:02 AM
To: John E Drake <[email-masked]>; Benjamin Kaduk <[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)

Hi Ben,

One question

Mankamana

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 7, 2022 at 7:17 AM
To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)
Ben,

Comments inline below.

Yours Irrespectively,

John

> From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
> To: John E Drake <[email-masked]<mailto:[email-masked]>>
> Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
> > > To: John E Drake <[email-masked]<mailto:[email-masked]>>
> > > Cc: The IESG <[email-masked]<mailto:[email-masked]>>;
> > > [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > > > From: Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>>
> > > > > To: The IESG <[email-masked]<mailto:[email-masked]>>
> > > > > Cc: [email-masked]<mailto:[email-masked]>;
> > > > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->

> > > (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/d<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/d>
> > > raft-ietf-
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->

[JD]  This is fine.

> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->
[
JD]  We will fix this.

[JD]  We will add this.

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 17 Feb 2022 07:01:35 +0000

Thanks john for providing input. New version of draft accommodated all of these changes.

Mankamana

From: John E Drake <[email-masked]>
Date: Friday, February 11, 2022 at 8:13 AM
To: Mankamana Mishra (mankamis) <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[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)
Hi,

Yours Irrespectively,

John

Hi Ben,

One question

Mankamana

Comments inline below.

Yours Irrespectively,

John

[JD]  This is fine.

[
JD]  We will fix this.

[JD]  We will add this.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Feb 2022 18:59:56 -0800

> Thanks john for providing input. New version of draft accommodated all of these changes.

Thanks John, thanks Mankamana.

I have balloted No Objection on the -18.

-Ben