Ben, Comments inline below.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Friday, February 4, 2022 8:09 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, > > 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 <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-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). > > > > > > > > > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
