Yours Irrespectively,
John
Juniper Business Use Only
> -----Original Message-----
> From: Benjamin Kaduk <ka...@mit.edu>
> Sent: Thursday, October 21, 2021 10:08 PM
> To: John E Drake <jdr...@juniper.net>
> Cc: The IESG <i...@ietf.org>; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org;
> bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
> 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 <nore...@ietf.org>
> > > Sent: Wednesday, October 20, 2021 8:49 PM
> > > To: The IESG <i...@ietf.org>
> > > Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org;
> > > bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-
> 13:
> > > (with DISCUSS and COMMENT)
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-bess-evpn-igmp-mld-proxy-13: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-
> > > ballot-
> > > positions/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSRrxQJ1U$
> > > for more information about how to handle DISCUSS and COMMENT
> positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
> > > etf-bess-
> > > evpn-igmp-mld-proxy/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSbOB2k3E$
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > (1) Apparently each PE is supposed to store version flags for each
> > > other PE in the EVI (I guess on a per-route basis?), but this is
> > > mentioned just once, in passing, in step 2 of the Leave Group procedures
> > > in
> §4.1.2.
> >
> > [JD] The first hop PE keeps track of which IGMP or MLD versions are active
> > on
> the ESes to which it is attached and announces this via the BGP SMET route.
>
> Yes. Should this statement (or something like it) be in the document itself?
> (Where?)
[JD] Would you please review sections 4 and 5 of the -16
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-4,
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-5)
and see if they are is clear enough?
>
> > > Similarly, §6.1 defines, somewhat in passing, some "local IGMP
> > > Membership Request (x,G) state" that must be maintained in some cases.
> > > Let's discuss whether it's appropriate/useful to have a general
> > > introductory section that covers what new state PEs are expected to
> > > retain as part of supporting IGMP/MLD proxying. Maybe the answer is
> > > "no", but I would like to have the conversation.
> >
> > [JD] Section 6 generalizes the notion of a first hop PE to be the set of
> > multi-
> homed PEs attached to a given ES. Section 6
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> bess-evpn-igmp-mld-proxy-13*section-6__;Iw!!NEt6yMaO-
> gk!WAMtLTp8pHMhjeyfDY13FOVPAqTuQaEqcCu8hQOf-
> GMscsBgaRFDzERgy6ZEfS8$ ) explains why the multi-homed PEs need to
> synchronize state and section 6.1 explains what is that state:
>
> Rereading it, it does explain the need for state synchronization; thanks for
> pointing that out. However, it does not appear to use or introduce the
> specific
> term that the subsequent subsections are using to refer to that state. It
> seems
> like it could be useful to have a defined term for this state, to help
> readers make
> the connection between the need to track the state and where that state is
> referenced in the subsequent procedures.
>
> > If the PE doesn't already have local IGMP Membership Request (x,G) state
> > for
> that BD on that ES, it MUST instantiate local IGMP Membership Request (x,G)
> state and MUST advertise a BGP IGMP Join Synch route for that (ES,BD). Local
> IGMP Membership Request (x,G) state refers to IGMP Membership Request (x,G)
> state that is created as a result of processing an IGMP Membership Report for
> (x,G).
> >
> > i.e., IGMP Membership Request (x,G) state is the union of the local IGMP
> > Join
> (x,G) state and the installed IGMP Join Synch route.
>
> This would be a great start to a definition for such a defined term that I
> propose
> above.
[JD] Would you please review section 6 of the -16 version
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-6)
and see if it is clear enough?
>
> > >
> > > (2) I am not sure if the body text is consistent with what is being
> > > allocated from IANA. §8 describes PEs that are not using ingress
> > > replication as being identifiable as """any PE that has advertised
> > > an Inclusive Multicast Tag route for the BD without the "IGMP Proxy
> > > Support" flag""", but the IANA considerations allocate flags for
> > > both IGMP Proxy Support and MLD Proxy Support. Is a PE that
> > > advertises MLD Proxy Support but not IGMP Proxy Support to be treated as
> not using ingress replication, as the literal interpretation of this text
> would
> require?
> > > Similarly, §9.2.1 and §9.3.1 include restrictions on indication of
> > > support for "IGMP Proxy" with no mention of "MLD Proxy".
> >
> > [JD] It should be either IGMP or MLD Proxy Support
>
> Yes. Hopefully this is easy to insert into the document itself.
[JD] Would you please review sections 8 and 9.4 of the -16 version
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-8,
and
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9.4)
and see if they are is clear enough?
>
> Thanks again,
>
> Ben
>
> > > I do see that there is a generic disclaimer at the end of Section 3
> > > but the way it is written does not actually seem to cover this usage.
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > As one of the directorate reviewers noted (and Éric promoted to a
> > > DISCUSS), this document does not really give any specific
> > > description of how an EVPN PE should construct outgoing IGMP/MLD
> > > messages to send out on its ACs as a result of receiving EVP
> > > information over BGP. From a brief examination of the relevant IGMP
> > > messages, it seems that the EVPN messages might actually contain
> > > information to populate literally all the IGMP fields, but this is
> > > probably worth mentioning explicitly. In particular, guidance might
> > > be interesting for
> > > (e.g.) IGMPv3, that lets multiple Group Records be included in a
> > > single Membership Report.
> > > (Pedantically, such IGMPv3 multiplexing might also require phrasing
> > > changes for the reverse process, taking IGMP and constructing EVPN
> > > routes, since we refer to (e.g) "the Group address of the IGMP
> > > Membership Report" in places, and that is not a well-defined concept
> > > in the absence of some text indicating group-by- group processing.)
> > >
> > > Abstract
> > >
> > > This document describes how to support efficiently endpoints running
> > > IGMP for the above services over an EVPN network by incorporating
> > > IGMP proxy procedures on EVPN PEs.
> > >
> > > I see Lars already noted the dangling reference to "above services".
> > > That really needs to be fixed before approval, and even looking at
> > > the diff from -
> > > 12 to -13 does not give me a clear picture of what to suggest as a
> > > rewrite.
> > >
> > > Section 1
> > >
> > > I strongly suggest mentioning and referencing some of the core
> > > technologies that readers are assumed to be familiar with (e.g., RFC
> > > 7432 for EVPN, RFC 6514 for various tunnel types including Ingress
> Replication).
> > > At present the document is quite unfriendly to a reader from an
> > > outside field, who has little to no indication as to what background
> > > material is required in order to be able to make sense of this document.
> > >
> > > In DC applications, a point of delivery (POD) can consist of a
> > >
> > > Data Center is not marked as "well-known" at
> > > https://urldefense.com/v3/__https://www.rfc-
> > > editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSLlJ3XlU$
> > > and needs to be expanded on first use.
> > >
> > > 2. Distributed anycast multicast proxy: it is desirable for the EVPN
> > > network to act as a distributed anycast multicast router with
> > >
> > > I honestly don't know what a "distributed anycast multicast router"
> > > is supposed to be. Google finds only a handful of instances of that
> > > (quoted) phrase, most of which can be traced back to this document.
> > > There is a similar phrase in §4.2 that perhaps clarifies that the
> > > collection of EVPN PEs is intended to function as a distributed
> > > multicast router (that is perhaps in some sense transparent to the CEs).
> > > But how does the "anycast" part come into play? How is the anycast
> > > IP address assigned, and which protocol messages is it conveyed in?
> > >
> > > Section 3
> > >
> > > I suggest adding SMET to the terminology listed here.
> > >
> > > o Ethernet Segment (ES): When a customer site (device or network) is
> > > connected to one or more PEs via a set of Ethernet links.
> > >
> > > That looks like an extremely unconventional definition for "Ethernet
> Segment".
> > >
> > > Membership Report too. Similarly, text for IGMPv2 applies to MLDv1
> > > and text for IGMPv3 applies to MLDv2. IGMP / MLD version encoding in
> > > BGP update is stated in Section 9
> > >
> > > I suggest stating explicitly that this equivalence is possible
> > > because the indicated versions provide analogous functionality for IPv4
> > > and
> IPv6, respectively.
> > >
> > > Section 4.1.1
> > >
> > > is considered as a new BGP route advertisement. When different
> > > version of IGMP join are received, final state MUST be as per
> > > section 5.1 of [RFC3376]. At the end of route processing local
> > > and remote group record state MUST be as per section 5.1 of
> > > [RFC3376].
> > >
> > > I interpret "different version of IGMP join" as "join messages from
> > > different IGMP protocol versions", which makes this reference to RFC
> > > 3376 make no sense to me -- the referenced section does not talk
> > > about multiple protocol versions at all. Please clarify what
> > > behavior from RFC 3376 is being referenced.
> > >
> > > logged. If the v3 flag is set (in addition to v2), then the IE
> > > flag MUST indicate "exclude". If not, then an error SHOULD be
> > > logged. [...]
> > >
> > > It's great to say that this is an error condition and should be logged.
> > > What does the recipient actually do while processing the message?
> > > An RFC 7606 named behavior would be nice.
> > >
> > > Section 4.2
> > >
> > > As mentioned in the previous sections, each PE MUST have proxy
> > > querier functionality for the following reasons:
> > >
> > > I'm not really sure which previous mentions this is supposed to refer to.
> > >
> > > Section 6.2.1
> > >
> > > Just to confirm: the PE receiving a BGP Leave Synch route does *not*
> > > produce local IGMP Query messages, on the assumption that the PE
> > > that did receive the Leave locally has already done so? (I don't
> > > think this necessarily needs to be written out in the document
> > > itself; I just want to confirm my understanding.)
> > >
> > > Section 6.3
> > >
> > > A PE which has received an IGMP Membership Request would have synced
> > > the IGMP Join by the procedure defined in section 6.1. If a PE with
> > > local join state goes down or the PE to CE link goes down, it would
> > > lead to a mass withdraw of multicast routes. Remote PEs (PEs
> > > where
> > >
> > > Can we have greater clarity on "would lead to"? Are there actually
> > > routes that will be withdrawn and we are just ignoring the
> > > consequences of that for the purposes of local state, using some
> > > heuristic (as mentioned later) for detecting whether a mass-withdraw
> > > is due to a failure at a peer? Or is the mass withdraw a hypothetical
> > > scenario
> that the procedures described here fully avoid?
> > >
> > > these routes were remote IGMP Joins) SHOULD NOT remove the state
> > > immediately; instead General Query SHOULD be generated to refresh the
> > > states. There are several ways to detect failure at a peer, e.g.
> > > using IGP next hop tracking or ES route withdraw.
> > >
> > > Does each PE initiate the General Query, in this scenario?
> > >
> > > Section 7
> > >
> > > Note that to facilitate state synchronization after failover, the PEs
> > > attached to a multihomed ES operating in Single-Active redundancy
> > > mode SHOULD also coordinate IGMP Join (x,G) state. In this case
> > > all
> > >
> > > What are the drawbacks of not performing such synchronization?
> > > Alternately, in what cases does it make sense to not perform
> > > synchronization (so that the guidance is SHOULD rather than MUST)?
> > >
> > > Section 9.1
> > >
> > > It might be nice to mention that the length fields are measured in
> > > bits here in this section, where the NLRI format is laid out, in
> > > addition to
> > > §9.1.1 where the procedures for constructing it are laid out.
> > >
> > > o If route is used for IPv6 (MLD) then bit 7 indicates support for
> > > MLD version 1. The second least significant bit, bit 6
> > > indicates
> > >
> > > How does the receiver know if the route is being used for IPv6?
> > > (Also applies in §9.2, 9.3)
> > >
> > > Section 9.1.1
> > >
> > > Is there any requirement for consistency about using IPv4 vs IPv6
> > > addresses in all three address fields? The description given here
> > > would seem to allow mixing address families, but I don't really expect
> > > that to
> work in practice.
> > >
> > > version and any source filtering for a given group membership. All
> > > EVPN SMET routes are announced with per- EVI Route Target extended
> > > communities.
> > >
> > > Is there a good reference for discussion of these associated ECs?
> > >
> > > Section 9.1.2
> > >
> > > PE2 to receive multicast traffic. In this case PE2 MUST originate a
> > > (*,*) SMET route to receive all of the multicast traffic in the EVPN
> > > domain. To generate Wildcards (*,*) routes, the procedure from
> > > [RFC6625] SHOULD be used.
> > >
> > > Is the PE expected to identify this case based on protocol messages
> > > received at runtime (e.g., any PIM at all), or is this external
> > > configuration?
> > >
> > > Section 9.3.1
> > >
> > > Maximum Response Time is value to be used while sending query as
> > > defined in [RFC2236]
> > >
> > > Is it actually right to describe this as "while sending query
> > > [messages]"? My understanding is that a PE receiving this route
> > > over BGP would in fact *not* actually send IGMP Query messages, but
> > > simply use the time to set a timer and potentially clear up state if
> > > certain conditions are met at the end of the period in question.
> > >
> > > Section 10
> > >
> > > Just to confirm my understanding here: in the immediate leave case,
> > > the Leave Synch route will be advertised just for the "delta" period
> > > of time described in
> > > §6.2 and then withdrawn?
> > >
> > > IGMP MAY be configured with immediate leave option. This allows
> > > the
> > >
> > > Is there a suitable reference for "immediate leave"? I did not see
> > > much relevant in RFCs 2236 and 3376.
> > >
> > > Section 12
> > >
> > > I support Roman's point about detailing which aspects are covered in
> > > which referenced RFCs.
> > >
> > > I also noted that the "delta" value used in the Last Member Query
> > > process must be configured on each node, and to the same value.
> > > Such requirement for identical configuration opens up the chance for
> > > skew, and sometimes any such skew is security-relevant and must be
> > > documented in the security considerations. However, I'm not sure
> > > that that's the case, here, as it seems that skew would mostly only
> > > serve to cause a brief "blip" where a PE drops its group state only
> > > to recreate it when a report shows up later. Is there a scenario
> > > where the skew goes the other way, and a PE leaves group state in place
> indefinitely that should have been dropped?
> > >
> > > Section 16.1
> > >
> > > Since we only reference RFC 4684 to say that its procedures are not
> > > applicable to what we describe, it seems like it could be classified
> > > as only an informative reference.
> > >
> > > NITS
> > >
> > > We seem quite inconsistent about whether we write "BCP Leave Synch
> > > route" or "IGMP Leave Synch route" (but I believe these are both
> > > supposed to be the same thing).
> > >
> > > Section 1
> > >
> > > communication and orchestration. However, EVPN is used as standard
> > > way of inter-POD communication for both intra-DC and inter-DC. A
> > >
> > > intra-DC and inter-DC are both adjectives that need to modify some noun.
> > > Please supply such a noun (e.g., "traffic").
> > >
> > > These hosts express their interests in multicast groups on a given
> > > subnet/VLAN by sending IGMP Membership Reports (Joins) for their
> > > interested multicast group(s). [...]
> > >
> > > I think that this phrase "IGMP Membership Reports (Joins)" is
> > > intended to serve some cross-protocol clarification role (e.g.,
> > > "Join" is used by
> > > IGMPv3 and MLD but not IGMPv2). Since this is the first place where
> > > we use that formulation, some additional text to clarify the shorthand
> > > seems
> in order.
> > >
> > > Section 3
> > >
> > > o BD: Broadcast Domain. As per [RFC7432], an EVI consists of a
> > > single or multiple BDs. In case of VLAN-bundle and VLAN-aware
> > >
> > > RFC 7432 spells "VLAN Bundle" with no hyphen.
> > >
> > > o Single-Active Redundancy Mode: When only a single PE, among all
> > > the PEs attached to an Ethernet segment, is allowed to forward
> > > traffic to/from that Ethernet segment for a given VLAN, then the
> > > Ethernet segment is defined to be operating in Single-Active
> > > redundancy mode.
> > >
> > > o All-Active Redundancy Mode: When all PEs attached to an Ethernet
> > > segment are allowed to forward known unicast traffic to/from that
> > > Ethernet segment for a given VLAN, then the Ethernet segment is
> > > defined to be operating in All-Active redundancy mode.
> > >
> > > Is it important that the second definition only covers "unicast traffic"
> > > but the former uses the unqualified term "traffic"?
> > >
> > > o OIF: Outgoing Interface for multicast. It can be physical
> > > interface, virtual interface or tunnel.
> > >
> > > s/physical/a physical/
> > >
> > > Section 4
> > >
> > > The IGMP Proxy mechanism is used to reduce the flooding of IGMP
> > > messages over an EVPN network similar to ARP proxy used in
> > > reducing
> > >
> > > "similarly to how ARP proxy is used"
> > >
> > > speakers. The information is again translated back to IGMP message
> > > at the recipient EVPN speaker. Thus it helps create an IGMP
> > > overlay
> > >
> > > "IGMP messages" plural, to match the previous sentence.
> > >
> > > Section 4.1.1
> > >
> > > 1. When the first hop PE receives several IGMP Membership Reports
> > > (Joins), belonging to the same IGMP version, from different
> > > attached hosts for the same (*,G) or (S,G), it SHOULD send a
> > > single BGP message corresponding to the very first IGMP
> > > Membership Request (BGP update as soon as possible) for that
> > > (*,G) or (S,G). [...]
> > >
> > > What is an "IGMP Membership Request"? Is this just a typo for Report?
> > >
> > > This is because BGP is a stateful protocol and
> > > no further transmission of the same report is needed. If the
> > > IGMP Membership Request is for (*,G), then multicast group
> > > address MUST be sent along with the corresponding version flag
> > > (v2 or v3) set. [...]
> > >
> > > (ditto)
> > >
> > > If the IGMP Join is for (S,G), then
> > > besides setting multicast group address along with the version
> > > flag v3, the source IP address and the IE flag MUST be set.
> > > It
> > >
> > > "setting the multicast group address" (add "the").
> > >
> > > 2. When the first hop PE receives an IGMPv3 Join for (S,G) on a
> > > given BD, it SHOULD advertise the corresponding EVPN Selective
> > > Multicast Ethernet Tag (SMET) route regardless of whether the
> > >
> > > Forward reference Section 9.1, please?
> > >
> > > 4. When the first hop PE receives an IGMP version-X Join first for
> > > (*,G) and then later it receives an IGMPv3 Join for the same
> > > multicast group address but for a specific source address S, then
> > > the PE MUST advertise a new EVPN SMET route with v3 flag set (and
> > > v2 reset). The IE flag also need to be set accordingly.
> > > Since
> > >
> > > What does "v2 reset" mean? "The v2 flag is not set" or "the v2 flag is
> cleared"?
> > > I recommend not using the word "reset" in this context as it's ambiguous.
> > >
> > > 7. Upon receiving EVPN SMET route(s) and before generating the
> > > corresponding IGMP Membership Request(s), the PE checks to
> > > see
> > >
> > > "Membership Request" again.
> > >
> > > whether it has any CE multicast router for that BD on any of its
> > > ES's . The PE provides such a check by listening for PIM Hello
> > > messages on that AC (i.e, ES,BD). If the PE does have the
> > > router's ACs, then the generated IGMP Membership Request(s) are
> > > sent to those ACs. If it doesn't have any of the router's AC,
> > > then no IGMP Membership Request(s) needs to be generated.
> > > [...]
> > >
> > > The writing here seems rather jumbled, though perhaps I just
> > > misunderstand the terminology in question. Assuming that a PE
> > > router has one or more ACs connecting it to one or more CE routers
> > > (possibly in a many-to-many fashion), then I don't see how we can
> > > write about the PE "have[ing] [any of] the router's ACs" -- wouldn't
> > > the relevant criterion be that the AC has CE routers participating in
> multicast?
> > >
> > > Section 4.1.2
> > >
> > > 2. When a PE receives an EVPN SMET route for a given (*,G), it
> > > compares the received version flags from the route with its per-
> > > PE stored version flags. If the PE finds that a version flag
> > > associated with the (*,G) for the remote PE is reset, then
> > > the PE
> > >
> > > [same comment about the word "reset" as above]
> > >
> > > MUST generate IGMP Leave for that (*,G) toward its local
> > > interface (if any) attached to the multicast router for that
> > >
> > > Probably "router(s)" since there could be more than one.
> > > And "interface(s)" as well?
> > >
> > > multicast group. It should be noted that the received EVPN route
> > > MUST at least have one version flag set. If all version flags
> > > are reset, it is an error because the PE should have received
> > > an
> > >
> > > ["reset" again]
> > >
> > > Section 5
> > >
> > > Consider the EVPN network of Figure-1, where there is an EVPN
> > > instance configured across the PEs shown in this figure (namely PE1,
> > > PE2, and PE3). Let's consider that this EVPN instance consists of a
> > > single bridge domain (single subnet) with all the hosts, sources,
> > > and
> > >
> > > This is the only instance of the word "bridge" in this document (but
> > > "broadcast domain" appears as a defined term). Is "BD" intended?
> > >
> > > Section 5.1
> > >
> > > all these local ports are associated with the hosts. PE1 sends an
> > > EVPN Multicast Group route corresponding to this join for (*,G1) and
> > > setting v2 flag. This EVPN route is received by PE2 and PE3 that
> > > are
> > >
> > > s/setting/sets the/
> > >
> > > information. However, when it receives the IGMPv3 Join from H3 for
> > > the same (*,G1). Besides adding the corresponding port to its
> > > OIF
> > >
> > > incomplete sentence; could add ", EVPN messaging is required" to
> > > connect to the next sentence.
> > >
> > > Section 6
> > >
> > > either DF or non-DF; i.e., different IGMP Membership Request
> > > messages
> > >
> > > "Membership Request" again.
> > >
> > > needed. All-Active multihoming PEs for a given ES MUST support IGMP
> > > synchronization procedures described in this section if they need to
> > > perform IGMP proxy for hosts connected to that ES.
> > >
> > > Can we unpack the actual requirement here? Is it: "if a given ES
> > > uses all-active multihoming, in order for IGMP proxying to be used
> > > on that ES, all the PEs on that segment must support the
> > > synchronization procedures described in the following subsections"?
> > > The analogous text in §6.2 seems more clear to me on what the
> > > preconditions are.
> > >
> > > Also, s/MUST support/MUST support the/ and s/IGMP proxy/IGMP
> > > proxying/
> > >
> > > Section 6.1
> > >
> > > belongs. If the PE doesn't already have local IGMP Membership
> > > Request (x,G) state for that BD on that ES, it MUST instantiate local
> > > IGMP Membership Request (x,G) state and MUST advertise a BGP IGMP
> > >
> > > "Membership Request", albeit perhaps defensible since it is "state"
> > > and not a message being sent.
> > >
> > > Join Synch route for that (ES,BD). Local IGMP Membership Request
> > > (x,G) state refers to IGMP Membership Request (x,G) state that is
> > > created as a result of processing an IGMP Membership Report for
> > > (x,G).
> > >
> > > It's typically easier for the reader when the new term is defined
> > > before it is used, rather than after. Especially so when the
> > > defined term is similar to an existing, well-established, term that means
> something else.
> > >
> > > Section 9.1
> > >
> > > o This EVPN route type is used to carry tenant IGMP multicast group
> > > information. The flag field assists in distributing IGMP
> > > Membership Report of a given host for a given multicast route.
> > > The version bits help associate IGMP version of receivers
> > > participating within the EVPN domain.
> > >
> > > o The include/exclude bit helps in creating filters for a given
> > > multicast route.
> > >
> > > Is "assists" and "helps" really the terminology we want to use when
> > > this information is literally required in order to construct the
> > > relevant IGMP messages? (Similarly for the subsequent subsections.)
> > >
> > > Section 9.1.1
> > >
> > > The Originator Router Address is the IP address of router originating
> > > this route. The SMET Originator Router IP address MUST match that of
> > > the IMET (or S-PMSI AD) route originated for the same EVI by the same
> > > downstream PE.
> > >
> > > References for IMET and S-PMSI AD might be nice.
> > >
> > > The Flags field indicates the version of IGMP protocol from which the
> > > Membership Report was received. It also indicates whether the
> > >
> > > Probably "version(s)" and "Report(s)" since we encourage coalescing.
> > >
> > > Section 9.3.1
> > >
> > > Maximum Response Time is value to be used while sending query as
> > > defined in [RFC2236]
> > >
> > > "the value to be used while sending queries" (though see the non-nit
> comment).
> > >
> > >
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
