Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)
draft-ietf-bess-evpn-igmp-mld-proxy-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
21 | Gunter Van de Velde | Request closed, assignment withdrawn: Shwetha Bhandari Last Call OPSDIR review |
2024-01-26
|
21 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-06-20
|
21 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-06-10
|
21 | (System) | RFC Editor state changed to AUTH48 |
2022-05-19
|
21 | Andrew Alston | Shepherding AD changed to Andrew Alston |
2022-05-17
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-03-29
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-03-29
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-03-29
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-03-29
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-03-29
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-03-28
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-03-24
|
21 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2022-03-24
|
21 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Liang Xia was marked no-response |
2022-03-23
|
21 | (System) | RFC Editor state changed to EDIT |
2022-03-23
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-03-23
|
21 | (System) | Announcement was received by RFC Editor |
2022-03-23
|
21 | (System) | IANA Action state changed to In Progress |
2022-03-23
|
21 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-03-23
|
21 | Amy Vezza | IESG has approved the document |
2022-03-23
|
21 | Amy Vezza | Closed "Approve" ballot |
2022-03-23
|
21 | Amy Vezza | Ballot approval text was generated |
2022-03-22
|
21 | (System) | Removed all action holders (IESG state changed) |
2022-03-22
|
21 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-03-22
|
21 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-21.txt |
2022-03-22
|
21 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2022-03-22
|
21 | Mankamana Mishra | Uploaded new revision |
2022-03-22
|
20 | Murray Kucherawy | [Ballot comment] Preserved from my DISCUSS on -14: I suggest making each of the actions you want to take (there are four) into their own … [Ballot comment] Preserved from my DISCUSS on -14: I suggest making each of the actions you want to take (there are four) into their own subsections of this section. On revision -20: Section 3 defines "MAC-VRF", but this term appears nowhere in the document. It also defines "PMSI", which is not used anywhere else except in the definition of "S-PMSI", so I suggest merging these. Lastly, the entire section is sorted alphabetically except for the last two entries. |
2022-03-22
|
20 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2022-03-21
|
20 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-20.txt |
2022-03-21
|
20 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2022-03-21
|
20 | Mankamana Mishra | Uploaded new revision |
2022-03-11
|
19 | Alvaro Retana | [Ballot comment] I am changing my ballot to ABSTAIN because I still believe that requiring that IGMPv1 not be used contradicts the IGMPv3 specification, which … [Ballot comment] I am changing my ballot to ABSTAIN because I still believe that requiring that IGMPv1 not be used contradicts the IGMPv3 specification, which requires support. I will then not stand in the way of publication. ===== This is the original DISCUSS text: §11 says this: This document does not provide any detail about IGMPv1 processing. Multicast working group are in process of deprecating uses of IGMPv1. Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and above for IPv6. IGMP V1 routes MUST be considered as invalid and the PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]. Initial version of document did mention use of IGMPv1 and flag had provision to support IGMPv1. There may be an implementation which is deployed as initial version of document, to interop flag has not been changed. Note that the "Multicast working group" mentioned above is in fact the pim WG. There's no current WG to deprecate IGMPv1, but draft-ietf-pim-3376bis was recently adopted with the intent to progress IGMPv3 to Internet Standard. This text is from draft-ietf-pim-3376bis (it is the same text as in rfc3376): IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section Section 7). (Section 7/draft-ietf-pim-3376bis talks about interoperability with older versions.) All this is to say that requiring that IGMPv1 not be used contradicts the IGMPv3 specification, which requires the support. The interoperation between the different versions is already considered in rfc3376, so the extra complexity added to this document (tracking the versions in the BGP updates) is not needed from the router side. I am balloting DISCUSS because this document is not in line with other consensus documents (specifically the IGMP specification). |
2022-03-11
|
19 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to Abstain from Discuss |
2022-03-07
|
19 | Éric Vyncke | [Ballot comment] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate twice the ballot status of this document and with … [Ballot comment] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate twice the ballot status of this document and with the -19 revision all my previous blocking DISCUSS points are addressed. Thank you to the authors. See below this line for updated version ---------------------------------------------- Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast one. Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric == Archived DISCUSS (addressed/fixed in -19) == The text covers in details how to map MLD/IGMP into BGP routes but does not say a word on how to recreate the MLD/IGMP packets. Should there be any such specification (e.g., in section 4.1) ? Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses. -- Abstract -- While this point is pretty light for a blocking DISCUSS, let's fix it: - the abstract should also mention MLD and not only IGMP - what are 'the above services' ? -- Section 1 -- In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear. == COMMENT == A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ... -- Section 1 -- When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different. -- Section 3 -- (Addressed in -18) Is there any reason why the terminology is not alphabetically sorted ? (Addressed in -18) Please also add 'BD'. (Addressed in -18) Usually a terminology section is not only about acronym expansions but also about definitions. -- Section 4.1 -- What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ? -- Section 4.2 -- May be that I overlooked it, but what is a 'proxy querier' ? What is the difference between "EVPN core" and "MPLS/IP core" ? -- Section 5.1 -- (Addressed over email) What is "viz" ? (Sorry not being a native English speaker) -- Section 8 -- (Addressed over email) Is there a difference between (*, G) and (x, G) ? -- Section 9.1 -- (Addressed in -18) Please formally specify "IE" as "include/exclude" (if not mistaken). I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ? (Addressed in -18) Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST". -- Sections 9.1, 9.2 -- The flags description appears to be different in the text while it seems to me that they have the same semantics. |
2022-03-07
|
19 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2022-03-04
|
19 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-19.txt |
2022-03-04
|
19 | (System) | New version approved |
2022-03-04
|
19 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Mankamana Mishra , Samir Thoria , Wen Lin |
2022-03-04
|
19 | Mankamana Mishra | Uploaded new revision |
2022-03-04
|
18 | Éric Vyncke | [Ballot discuss] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate the ballot status of this document and clearing parts … [Ballot discuss] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate the ballot status of this document and clearing parts of my original block DISCUSS points and many of my original non-blocking COMMENT points. See below this line for updated version ---------------------------------------------- Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast one. Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 1 -- In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear. |
2022-03-04
|
18 | Éric Vyncke | [Ballot comment] == Archived DISCUSS (addressed/fixed in -18) == The text covers in details how to map MLD/IGMP into BGP routes but does not say … [Ballot comment] == Archived DISCUSS (addressed/fixed in -18) == The text covers in details how to map MLD/IGMP into BGP routes but does not say a word on how to recreate the MLD/IGMP packets. Should there be any such specification (e.g., in section 4.1) ? Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses. -- Abstract -- While this point is pretty light for a blocking DISCUSS, let's fix it: - the abstract should also mention MLD and not only IGMP - what are 'the above services' ? == COMMENT == A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ... -- Section 1 -- When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different. -- Section 3 -- (Addressed in -18) Is there any reason why the terminology is not alphabetically sorted ? (Addressed in -18) Please also add 'BD'. (Addressed in -18) Usually a terminology section is not only about acronym expansions but also about definitions. -- Section 4.1 -- What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ? -- Section 4.2 -- May be that I overlooked it, but what is a 'proxy querier' ? What is the difference between "EVPN core" and "MPLS/IP core" ? -- Section 5.1 -- (Addressed over email) What is "viz" ? (Sorry not being a native English speaker) -- Section 8 -- (Addressed over email) Is there a difference between (*, G) and (x, G) ? -- Section 9.1 -- (Addressed in -18) Please formally specify "IE" as "include/exclude" (if not mistaken). I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ? (Addressed in -18) Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST". -- Sections 9.1, 9.2 -- The flags description appears to be different in the text while it seems to me that they have the same semantics. |
2022-03-04
|
18 | Éric Vyncke | Ballot comment and discuss text updated for Éric Vyncke |
2022-03-04
|
18 | Éric Vyncke | [Ballot discuss] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate the ballot status of this document and clearing parts … [Ballot discuss] As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate the ballot status of this document and clearing parts of my original block DISCUSS points and many of my original non-blocking COMMENT points. See below this line for updated version ---------------------------------------------- Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast one. Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric == DISCUSS == The text covers in details how to map MLD/IGMP into BGP routes but does not say a word on how to recreate the MLD/IGMP packets. Should there be any such specification (e.g., in section 4.1) ? -- Section 1 -- In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear. |
2022-03-04
|
18 | Éric Vyncke | [Ballot comment] == Archived DISCUSS (addressed/fixed in -18) == Are all multicast group address treated as the same ? I would have appreciated some text … [Ballot comment] == Archived DISCUSS (addressed/fixed in -18) == Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses. -- Abstract -- While this point is pretty light for a blocking DISCUSS, let's fix it: - the abstract should also mention MLD and not only IGMP - what are 'the above services' ? == COMMENT == A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ... -- Section 1 -- When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different. -- Section 3 -- (Addressed in -18) Is there any reason why the terminology is not alphabetically sorted ? (Addressed in -18) Please also add 'BD'. (Addressed in -18) Usually a terminology section is not only about acronym expansions but also about definitions. -- Section 4.1 -- What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ? -- Section 4.2 -- May be that I overlooked it, but what is a 'proxy querier' ? What is the difference between "EVPN core" and "MPLS/IP core" ? -- Section 5.1 -- (Addressed over email) What is "viz" ? (Sorry not being a native English speaker) -- Section 8 -- (Addressed over email) Is there a difference between (*, G) and (x, G) ? -- Section 9.1 -- (Addressed in -18) Please formally specify "IE" as "include/exclude" (if not mistaken). I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ? (Addressed in -18) Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST". -- Sections 9.1, 9.2 -- The flags description appears to be different in the text while it seems to me that they have the same semantics. |
2022-03-04
|
18 | Éric Vyncke | Ballot comment and discuss text updated for Éric Vyncke |
2022-02-24
|
18 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my previous Discuss points. COMMENT section originally posted on the -13 retained below, unchanged. Some content may be stale. ======================================================================= … [Ballot comment] Thanks for addressing my previous Discuss points. COMMENT section originally posted on the -13 retained below, unchanged. Some content may be stale. ======================================================================= 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://www.rfc-editor.org/materials/abbrev.expansion.txt 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). |
2022-02-24
|
18 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2022-02-21
|
18 | Bernie Volz | Closed request for Telechat review by INTDIR with state 'Withdrawn' |
2022-02-16
|
18 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-18.txt |
2022-02-16
|
18 | (System) | New version approved |
2022-02-16
|
18 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Mankamana Mishra , Samir Thoria , Wen Lin |
2022-02-16
|
18 | Mankamana Mishra | Uploaded new revision |
2022-02-16
|
17 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-17.txt |
2022-02-16
|
17 | (System) | New version approved |
2022-02-16
|
17 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Mankamana Mishra , Samir Thoria , Wen Lin |
2022-02-16
|
17 | Mankamana Mishra | Uploaded new revision |
2022-02-04
|
16 | Benjamin Kaduk | [Ballot comment] Previous DISCUSS point (1) (from the -13): === (1) Apparently each PE is supposed to store version flags for each other PE in … [Ballot comment] Previous DISCUSS point (1) (from the -13): === (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. 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. === Demoting it to just COMMENT-level, but I still think the text is needlessly unclear here. Further commentary at https://mailarchive.ietf.org/arch/msg/bess/9R50CgjGicJqH3KGfp4AZ99M6ZM/ . COMMENT section originally posted on the -13 retained below, unchanged. Some content may be stale. ======================================================================= 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://www.rfc-editor.org/materials/abbrev.expansion.txt 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). |
2022-02-04
|
16 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2022-01-20
|
16 | Carlos Jesús Bernardos | Assignment of request for Telechat review by INTDIR to Suresh Krishnan was withdrawn |
2022-01-13
|
16 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-16.txt |
2022-01-13
|
16 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2022-01-13
|
16 | Mankamana Mishra | Uploaded new revision |
2021-12-08
|
15 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-12-08
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-12-08
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-12-08
|
15 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-15.txt |
2021-12-08
|
15 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2021-12-08
|
15 | Mankamana Mishra | Uploaded new revision |
2021-10-28
|
14 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. I have to say that I found that the heavier use of acronyms made this document somewhat harder … [Ballot comment] Hi, Thanks for this document. I have to say that I found that the heavier use of acronyms made this document somewhat harder to read. I'm also not an expert in these technologies. My main question isn't directly actionably on this document, but I wanted to check whether any updates to the EVPN YANG module are required to support this functionality, and if so, is that work in progress, or planned? Otherwise, I just had a couple of minor comments: On 4.1.1. IGMP/MLD Membership Report Advertisement in BGP When a PE wants to advertise an IGMP Membership Report (Join) using the BGP EVPN route, it follows the following rules (BGP encoding stated in Section 9): 1. .... 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. This implies to me that either the v2 or v3 flag is exclusively set, but presumably it could also be both. Would "add/or" be better than or? Does OIF need to be an acronym, it doesn't seem worth it, and makes the text harder to parse. Is this a standard term used in other related docs? 5. Operation In the paragraph of text above the diagram, perhaps more clearly indicate that S1, S2 indicate multicast sources and R1 indicates a multicast router, and Hx indicates hosts. 9.1. Selective Multicast Ethernet Tag Route Rather than writing things like "second least significant bit", just writing "bit 6" would seem to be clearer. 9.1.1. Constructing the Selective Multicast Ethernet Tag route I was surprised that the lengths are specified in bits, not bytes. I presume that bits are used for consistency with other encodings. Thanks, Rob |
2021-10-28
|
14 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-10-28
|
14 | (System) | Changed action holders to Ali Sajassi, Martin Vigoureux, John Drake, Wen Lin, Samir Thoria, Mankamana Mishra (IESG state changed) |
2021-10-28
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation - Defer |
2021-10-28
|
14 | Francesca Palombini | [Ballot comment] Thanks for the work on this document. As in draft-ietf-bess-evpn-optimized-ir, I have to comment on the overuse of abbreviations and the assumptions … [Ballot comment] Thanks for the work on this document. As in draft-ietf-bess-evpn-optimized-ir, I have to comment on the overuse of abbreviations and the assumptions that the reader is familiar with all concepts and terms used make the document really hard to read for non-expert in the field. I'll also point out that having a terminology section with expansion but with no references is not as useful as one with proper descriptions and references. Here as well, there is a several uses of SHOULD and should in a way that either is requiring more context (what are the conditions when it is acceptable to not follow the SHOULD recommendations): o Reserved bits MUST be set to 0 by sender. And receiver SHOULD ignore the Reserved bits. and cases where IMO the term would better be replaced by something else, possibly more descriptive: > The registration policy should be "First Come First Served". > The registry should be initialized as follows: I don't have any other comment that has not already been flagged by my fellow ADs: I scanned for ART issues but did not find any significant ones. (Please do fix Lars non-blocking points as well). Francesca |
2021-10-28
|
14 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-10-28
|
14 | Zaheduzzaman Sarker | [Ballot comment] I had number of notes on when I was reading the -13 version, I can see many of those are already addressed in … [Ballot comment] I had number of notes on when I was reading the -13 version, I can see many of those are already addressed in -14 version. Rest are nits,skipping those. I would however, like to know the consensus around IPR. The shepherd or chairs or AD, if any one can provide more information on that that will be great. |
2021-10-28
|
14 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-10-27
|
14 | Murray Kucherawy | [Ballot discuss] There's an IPR disclosure on this document. In the shepherd writeup, where a summary of the discussion of it is requested, it simply … [Ballot discuss] There's an IPR disclosure on this document. In the shepherd writeup, where a summary of the discussion of it is requested, it simply says "There are 3 IPRs disclosed". I'd like to hear that summary, or at least confirm the discussion was had and there were no concerns as a result. The IANA Considerations section needs some work: (0) I suggest making each of the actions you want to take (there are four) into their own subsections of this section. (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended Community Sub-Types sub-registry of the BGP Extended Communities registry", which makes it easier to find. (2) "Multicast Flags Extended Community" appears to be a new registry you're creating in the final action here. BCP 26, for a First Come First Served registry, advises that a change controller column be included. Are you intentionally omitting this here? Or if this is referring to an existing registry, I wasn't able to find it. |
2021-10-27
|
14 | Murray Kucherawy | [Ballot comment] Section 3 defines "NV" and "NVO", but these terms appear nowhere in the document. Every SHOULD in this document, other than the ones … [Ballot comment] Section 3 defines "NV" and "NVO", but these terms appear nowhere in the document. Every SHOULD in this document, other than the ones that talk about logging, left me wondering why an implementer might decide not to follow that advice. Since SHOULD presents a choice, I suggest including some guidance about why it's a SHOULD, i.e., when one might decide not to do what it says and still expect to interoperate. Or should some of these really be MUSTs? |
2021-10-27
|
14 | Murray Kucherawy | Ballot comment and discuss text updated for Murray Kucherawy |
2021-10-27
|
14 | Erik Kline | [Ballot comment] Generally no useful comments that others haven't already made. Thank you for your patience, since I had pushed this out another week. [S4, … [Ballot comment] Generally no useful comments that others haven't already made. Thank you for your patience, since I had pushed this out another week. [S4, comment] * I feel like some representative diagram to refer to throughout the document might be useful earlier in the document, even if it's just duplication of Figure 1 from section 5. [S9.*] * Should it be said that if the Multicast Source Length is not zero then it MUST be equal to the Multicast Group Length? I.e. no mixing and matching IPv4 and IPv6 source/group addresses by accident? |
2021-10-27
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-10-27
|
14 | Alvaro Retana | [Ballot discuss] First of all, I am surprised that a document related to IGMP/MLD was not sent to the pim WG for review. I can't … [Ballot discuss] First of all, I am surprised that a document related to IGMP/MLD was not sent to the pim WG for review. I can't find any mention of this draft in the pim WG's archive. §11 says this: This document does not provide any detail about IGMPv1 processing. Multicast working group are in process of deprecating uses of IGMPv1. Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and above for IPv6. IGMP V1 routes MUST be considered as invalid and the PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]. Initial version of document did mention use of IGMPv1 and flag had provision to support IGMPv1. There may be an implementation which is deployed as initial version of document, to interop flag has not been changed. Note that the "Multicast working group" mentioned above is in fact the pim WG. There's no current WG to deprecate IGMPv1, but draft-ietf-pim-3376bis was recently adopted with the intent to progress IGMPv3 to Internet Standard. This text is from draft-ietf-pim-3376bis (it is the same text as in rfc3376): IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section Section 7). (Section 7/draft-ietf-pim-3376bis talks about interoperability with older versions.) All this is to say that requiring that IGMPv1 not be used contradicts the IGMPv3 specification, which requires the support. The interoperation between the different versions is already considered in rfc3376, so the extra complexity added to this document (tracking the versions in the BGP updates) is not needed from the router side. I am balloting DISCUSS because this document is not in line with other consensus documents (specifically the IGMP specification). To clear, I will want the document reviewed by the pim WG. |
2021-10-27
|
14 | Alvaro Retana | [Ballot comment] (1) The terminology section should include IGMP/MLD-related terminology or at least a pointer to the relevant RFCs. Also, the messages are called Membership … [Ballot comment] (1) The terminology section should include IGMP/MLD-related terminology or at least a pointer to the relevant RFCs. Also, the messages are called Membership Reports, and not "Join" or "IGMP Reports". Similar comment related to "IGMP Queries" and "Membership Requests" (should be Membership Query). [I will not make other comments below about this same point.] (2) [Line numbers from idnits.] 260 1. When the first hop PE receives several IGMP Membership Reports 261 (Joins), belonging to the same IGMP version, from different 262 attached hosts for the same (*,G) or (S,G), it SHOULD send a 263 single BGP message corresponding to the very first IGMP 264 Membership Request (BGP update as soon as possible) for that 265 (*,G) or (S,G). This is because BGP is a stateful protocol and 266 no further transmission of the same report is needed. If the The behavior in this rule is not required. Under what circumstances is it ok for the PE to not wait for several Membership Reports from multiple hosts before sending a BGP message? Waiting for multiple messages can clearly result in a delay for an interested host in receiving the multicast service. Note that rfc3376 says that "Multicast routers need to know only that *at least one* system on an attached network is interested..." (3) 269 (v2 or v3) set. In case of IGMPv3, the exclude flag MUST also be 270 set to indicate that no source IP address must be excluded 271 (include all sources "*"). If the IGMP Join is for (S,G), then 272 besides setting multicast group address along with the version 273 flag v3, the source IP address and the IE flag MUST be set. It "the exclude flag MUST also be set" I think you meant to reference the Exclude Group and the IE field in the flags. Note that the second part ("IE flag MUST be set") also refers to the same field, but for a different condition. Please be consistent and call things (the IE field, in this case) by a single name. The definitions in §9.* are not consistent either. (4) 277 2. When the first hop PE receives an IGMPv3 Join for (S,G) on a 278 given BD, it SHOULD advertise the corresponding EVPN Selective 279 Multicast Ethernet Tag (SMET) route regardless of whether the 280 source (S) is attached to itself or not in order to facilitate 281 the source move in the future. When is it ok for the SMET route not to be advertised? IOW, why is it a recommendation and not a requirement? (5) 283 3. When the first hop PE receives an IGMP version-X Join first for 284 (*,G) and then later it receives an IGMP version-Y Join for the 285 same (*,G), then it MUST re-advertise the same EVPN SMET route 286 with flag for version-Y set in addition to any previously-set 287 version flag(s). In other words, the first hop PE MUST NOT 288 withdraw the EVPN route before sending the new route because the 289 flag field is not part of BGP route key processing. The requirement (MUST) to re-advertise the same SMET route assumes that there was an advertisement done already, but rule 2 doesn’t require that. (6) 291 4. When the first hop PE receives an IGMP version-X Join first for 292 (*,G) and then later it receives an IGMPv3 Join for the same 293 multicast group address but for a specific source address S, then 294 the PE MUST advertise a new EVPN SMET route with v3 flag set (and 295 v2 reset). The IE flag also need to be set accordingly. Since 296 source IP address is used as part of BGP route key processing it 297 is considered as a new BGP route advertisement. When different 298 version of IGMP join are received, final state MUST be as per 299 section 5.1 of [RFC3376]. At the end of route processing local 300 and remote group record state MUST be as per section 5.1 of 301 [RFC3376]. Receiving an IGMPv3 Membership Report for the first time, as described here, is equivalent to the case in rule 2, However, the normative language is different: sending an SMET route is required here, but only recommended in rule 2. I fail to see why the conditions are different. Also, this rule mentions that the “ IE flag also need[s] to be set accordingly” while rule 1 requires a specific setting. This section is talking about the actions of a PE when it receives IGMP messages — this is what rfc3376 refers to as a multicast router. §5.1/rfc3376 refers to the host function (group members). Both statements (which seems redundant to me) requiring compliance with rfc3376 are misplaced. BTW, these are the only references (in the specification part of the text) to rfc3376. Given that this document is about IGMP/MLD Proxy, there should be other references that make clear the normative relationship. The same comment applies to the other versions of IGMP mentioned as well as MLD. (7) §4.1.1: The set of rules in this section (IGMP/MLD Membership Report Advertisement in BGP) is preceded with: 256 When a PE wants to advertise an IGMP Membership Report (Join) using 257 the BGP EVPN route, it follows the following rules (BGP encoding 258 stated in Section 9): But rules 5-7 are about the actions related to the SMET route being received, not advertising it. Perhaps divide the list of rules so that it is clear when they apply. (8) §4.1.1: Rule 7 talks about listening to PIM Hellos. Please add a Normative reference to rfc7761. (9) §4.1.2: Rules 2-3 are about the actions after the SMET route is received, which doesn't match with the preface to the rules. Perhaps divide the list of rules... (10) 1269 IGMP MAY be configured with immediate leave option. This allows the 1270 device to remove the group entry from the multicast routing table 1271 immediately upon receiving a IGMP leave message for (x,G). In case 1272 of all active multi-homing while synchronizing the IGMP Leave state 1273 to redundancy peers, Maximum Response Time MAY be filled in as Zero. 1274 Implementations SHOULD have identical configuration across multi- 1275 homed peers. In case IGMP Leave Synch route is received with Maximum 1276 Response Time Zero, irrespective of local IGMP configuration it MAY 1277 be processed as an immediate leave. By "immediate leave" I assume you're referring to "low leave latency" (rfc2236/rfc3376), is that right? There is no "immediate leave" mentioned in whose documents. "IGMP MAY be configured with immediate leave option." This "MAY" seems to just be stating a fact. s/MAY/may When is it ok for implementations to not have the same configuration? IOW, why is that a recommendation and not a requirement? |
2021-10-27
|
14 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2021-10-27
|
14 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-10-25
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-10-25
|
14 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-14.txt |
2021-10-25
|
14 | (System) | New version approved |
2021-10-25
|
14 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Mankamana Mishra , Samir Thoria , Wen Lin |
2021-10-25
|
14 | Mankamana Mishra | Uploaded new revision |
2021-10-21
|
13 | Murray Kucherawy | [Ballot discuss] The IANA Considerations section needs some work: (0) I suggest making each of the actions you want to take (there are four) into … [Ballot discuss] The IANA Considerations section needs some work: (0) I suggest making each of the actions you want to take (there are four) into their own subsections of this section. (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended Community Sub-Types sub-registry of the BGP Extended Communities registry", which makes it easier to find. (2) "Multicast Flags Extended Community" appears to be a new registry you're creating in the final action here. BCP 26, for a First Come First Served registry, advises that a change controller column be included. Are you intentionally omitting this here? |
2021-10-21
|
13 | Murray Kucherawy | [Ballot comment] My review is not yet complete, but I was pointed to this document's IANA Considerations section from another document about which I had … [Ballot comment] My review is not yet complete, but I was pointed to this document's IANA Considerations section from another document about which I had related questions. I'll update this once my full review is done. |
2021-10-21
|
13 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2021-10-20
|
13 | Erik Kline | Telechat date has been changed to 2021-10-28 from 2021-10-21 |
2021-10-20
|
13 | Erik Kline | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2021-10-20
|
13 | Benjamin Kaduk | [Ballot 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?), … [Ballot 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. 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. (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". 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. |
2021-10-20
|
13 | Benjamin Kaduk | [Ballot comment] As one of the directorate reviewers noted (and Éric promoted to a DISCUSS), this document does not really give any specific description of … [Ballot 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://www.rfc-editor.org/materials/abbrev.expansion.txt 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). |
2021-10-20
|
13 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-10-20
|
13 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast … [Ballot discuss] Thank you for the work put into this document. I have to state that I am neither a EVPN expert not a multicast one. Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric == DISCUSS == The text covers in details how to map MLD/IGMP into BGP routes but does not say a word on how to recreate the MLD/IGMP packets. Should there be any such specification ? Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses. -- Abstract -- While this point is pretty light for a blocking DISCUSS, let's fix it: - the abstract should also mention MLD and not only IGMP - what are 'the above services' ? -- Section 1 -- In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear. |
2021-10-20
|
13 | Éric Vyncke | [Ballot comment] A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in … [Ballot comment] A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ... -- Section 1 -- When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different. -- Section 3 -- Is there any reason why the terminology is not alphabetically sorted ? Please also add 'BD'. Usually a terminology section is not only about acronym expansions but also about definitions. -- Section 4.1 -- What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ? -- Section 4.2 -- May be that I overlooked it, but what is a 'proxy querier' ? What is the difference between "EVPN core" and "MPLS/IP core" ? -- Section 5.1 -- What is "viz" ? (Sorry not being a native English speaker) -- Section 8 -- Is there a difference between (*, G) and (x, G) ? -- Section 9.1 -- Please formally specify "IE" as "include/exclude" (if not mistaken). I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ? Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST". -- Sections 9.1, 9.2 -- The flags description appears to be different in the text while it seems to me that they have the same semantics. == NITS == Is it "ToR" or "TOR" ? -- Section 4.1.2 -- Please use a consistent quoting in the document, e.g. in : IGMPv2 Leave Group (Leave) or IGMPv3 "Leave" |
2021-10-20
|
13 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2021-10-19
|
13 | Roman Danyliw | [Ballot comment] ** Section 12. Recommend being clearer on the purpose of the long list of SecCon references (and few typos) OLD TThis document does … [Ballot comment] ** Section 12. Recommend being clearer on the purpose of the long list of SecCon references (and few typos) OLD TThis document does not add any new security considirattions, Same security considerations as [RFC7432], [RFC2236], [RFC3376], [RFC2710], [RFC3810], [RFC6513], [RFC6514] are applicable. NEW (feel free to polish) This document describes a means to efficiently operate IGMP and MLD on a subnet constructed across multiple PODs or DCs via an EVPN solution. The security considerations for the operation of the underlying EVPN and BGP substrate are described in [RFC7432], and specific multicast considerations are outlined in [RFC6513] and [RFC6514]. The EVPN and associated IGMP proxy provides a single broadcast domain so the same security considerations of IGMPv2 [RFC2246], IGMPv3 [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] apply. ** Editorial -- Section 9.4. Typo. s/associated associated/associated/ -- Section 11. Typo. s/implemention/implementation/ |
2021-10-19
|
13 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-10-18
|
13 | Lars Eggert | [Ballot comment] "Abstract", paragraph 1, comment: > This document describes how to support efficiently endpoints running > IGMP for the above services over … [Ballot comment] "Abstract", paragraph 1, comment: > 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. It would be nice if acronyms were spelled out at least in the abstract (esp. since it doesn't say where to go for further reading.) Also, "for the above services"? Above where? Section 9.4. , paragraph 6, comment: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=0x06 | Sub-Type=0x09| Flags (2 Octets) |M|I| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "Type" field is only seven bits long - that seems to be an error? Section 9.5. , paragraph 20, comment: > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=0x06 | Sub-Type=n | RT associated with EVI | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RT associated with the EVI (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This diagram is only 31 bits wide? You might want to use something like https://www.luismg.com/protocol/ to make sure your header diagrams are accurate. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 11. , paragraph 2, nit: - provision to support IGMPv1. There may be an implemention which is + provision to support IGMPv1. There may be an implementation which is + ++ Section 12. , paragraph 2, nit: - TThis document does not add any new security considirattions, Same - ^ - + This document does not add any new security considerations, Same + - ^ "Table of Contents", paragraph 2, nit: > . . . . . . 18 9.2. Multicast Join Synch Route . . . . . . . . . . . . . . . > ^^^^^ Do not mix variants of the same word ("synch" and "sync") within a single text. "Table of Contents", paragraph 2, nit: > on of servers and switches are self contained and may have their own control > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 3. , paragraph 18, nit: > triggering mechanism for the PEs to setup their underlay multicast tunnels. > ^^^^^ The verb "set up" is spelled as two words. The noun "setup" is spelled as one. Section 3. , paragraph 23, nit: > sage at the recipient EVPN speaker. Thus it helps create an IGMP overlay subn > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Section 4.1.1. , paragraph 3, nit: > et (and v2 reset). The IE flag also need to be set accordingly. Since source > ^^^^ The verb form "need" does not seem to match the subject "flag". Section 5. , paragraph 4, nit: > with the v3 and exclude flag set. Finally when PE1 receives the IGMPv3 Join > ^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Finally". Section 5.2. , paragraph 2, nit: > GMP Membership Report was received. Thus it MUST only be imported by the PEs > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Section 6.1. , paragraph 4, nit: > ses an IGMP Leave Synch route for that that (ES,BD). This route notifies the > ^^^^^^^^^ Possible typo: you repeated a word. Section 9.1. , paragraph 5, nit: > hosts by TORs. Upon receiving the hosts expression of interest of a particu > ^^^^^ An apostrophe may be missing. Section 9.3. , paragraph 3, nit: > not advertise this extended community so its absence indicates that the adver > ^^^ Use a comma before "so" if it connects two independent clauses (unless they are closely connected and short). Section 9.3. , paragraph 12, nit: > for bit 15 means that PE does not supports IGMP Proxy. * Bit 14 (shown as M > ^^^^^^^^ The auxiliary verb "do" requires the base form of the verb. Section 9.3.1. , paragraph 4, nit: > re attached to the associated ES. Therefore these routes carry the ES-Import > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Therefore". Section 9.3.1. , paragraph 12, nit: > BD. The route is said to be associated associated with that BD. For each BD, > ^^^^^^^^^^^^^^^^^^^^^ Possible typo: you repeated a word. Section 9.5. , paragraph 12, nit: > registration policy should be "First Come First Served". 14. Acknowledgement > ^^^^ It seems that a comma is missing. Document references draft-ietf-bess-evpn-bum-procedure-updates-08, but -11 is the latest available revision. |
2021-10-18
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-10-13
|
13 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-10-11
|
13 | Martin Duke | [Ballot comment] - It does not appear that you have fully addressed the TSVART comments (thanks Brian Trammell). Specifically, the (S,G) (*,G) definition is still … [Ballot comment] - It does not appear that you have fully addressed the TSVART comments (thanks Brian Trammell). Specifically, the (S,G) (*,G) definition is still not there. - In the abstract, it refers to "the above services" and I have no idea what that is referring to. - Please expand MLD, NLRI, and DF on first use or in the glossary. (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). This is confusingly phrased, enough that I think it threw off the TSVART reviewer. There is no delay waiting for multiple joins; the PE just sends BGP for the first and ignores the rest. Or perhaps I've misunderstood? Please rephrase. - Relatedly, if a PE receives (S, G) and later (*, G), should it withdraw the (S, G), since the latter join is a superset of the former? (9) It appears most of the fields in 9.1 through 9.3 are identical; it would shorten things dramatically if you either had a common section defining them or simply referred to Sec 9.1. Moreover, as this appears to be cut-and-paste, there are mistakes like 9.3 referring to "joins" when it's talking about leaves. (9) as you observe that the Source Length can be zero-length for (*,G) routes, it would be useful to say that the group length can also be zero for (*,*) joins. (it might also to constrain it so that if the group length is zero, the source length MUST also be zero, unless (S, *) joins are possible). |
2021-10-11
|
13 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-10-08
|
13 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Suresh Krishnan |
2021-10-08
|
13 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Suresh Krishnan |
2021-10-07
|
13 | Éric Vyncke | Requested Telechat review by INTDIR |
2021-10-07
|
13 | Cindy Morgan | Placed on agenda for telechat - 2021-10-21 |
2021-10-07
|
13 | Martin Vigoureux | Ballot has been issued |
2021-10-07
|
13 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2021-10-07
|
13 | Martin Vigoureux | Created "Approve" ballot |
2021-10-07
|
13 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-10-07
|
13 | Martin Vigoureux | Ballot writeup was changed |
2021-09-14
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-09-14
|
13 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-13.txt |
2021-09-14
|
13 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2021-09-14
|
13 | Mankamana Mishra | Uploaded new revision |
2021-09-14
|
12 | Henning Rogge | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Henning Rogge. Sent review to list. |
2021-09-08
|
12 | Brian Trammell | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Brian Trammell. Sent review to list. |
2021-09-07
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-09-07
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-09-07
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-igmp-mld-proxy-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-igmp-mld-proxy-12. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the EVPN Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at: https://www.iana.org/assignments/bgp-extended-communities/ five existing registrations will be have their references changed to [ RFC-to-be ]. They are: Sub-Type Value: 0x09 Name: Multicast Flags Extended Community Sub-Type Value: 0x0A Name: EVI-RT Type 0 Sub-Type Value: 0x0B Nane: EVI-RT Type 1 Sub-Type Value: 0x0C Name: EVI-RT Type 2 Sub-Type Value: 0x0D Name: EVI-RT Type 3 Second, in the EVPN Route Type registry located on the Ethernet VPN (EVPN) registry page located at: https://www.iana.org/assignments/evpn/ three temporary registrations will be made permanent and their references changed to [ RFC-to-be ]. They are: Value: 6 Description: Selective Multicast Ethernet Tag Route Value: 7 Description: Multicast Join Synch Route Value: 8 Description: Multicast Leave Synch Route Third, a new registry is to be created called the Multicast Flags Extended Community registry. Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)? The new registry will have bit values between 0-15. The registry will be managed via First Come, First Served as defined in RFC8126. There are initial registrations in the new registry as follows: Bit Name Reference ------+----------------------+--------------- 0-13 Unassigned 14 MLD Proxy Support [ RFC-to-be ] 15 IGMP Proxy Support [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-09-07
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-09-02
|
12 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2021-09-02
|
12 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2021-08-30
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2021-08-30
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2021-08-27
|
12 | Matt Joras | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Matt Joras. Sent review to list. |
2021-08-26
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matt Joras |
2021-08-26
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matt Joras |
2021-08-26
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2021-08-26
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2021-08-24
|
12 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2021-08-24
|
12 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2021-08-24
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-08-24
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-09-07): From: The IESG To: IETF-Announce CC: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org, martin.vigoureux@nokia.com, slitkows.ietf@gmail.com … The following Last Call announcement was sent out (ends 2021-09-07): From: The IESG To: IETF-Announce CC: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org, martin.vigoureux@nokia.com, slitkows.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (IGMP and MLD Proxy for EVPN) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'IGMP and MLD Proxy for EVPN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-09-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3673/ https://datatracker.ietf.org/ipr/2949/ https://datatracker.ietf.org/ipr/2942/ |
2021-08-24
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-08-24
|
12 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2021-08-24
|
12 | Martin Vigoureux | Last call was requested |
2021-08-24
|
12 | Martin Vigoureux | Ballot approval text was generated |
2021-08-24
|
12 | Martin Vigoureux | Ballot writeup was generated |
2021-08-24
|
12 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-08-24
|
12 | Martin Vigoureux | Last call announcement was generated |
2021-08-23
|
12 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-12.txt |
2021-08-23
|
12 | (System) | New version accepted (logged-in submitter: Mankamana Mishra) |
2021-08-23
|
12 | Mankamana Mishra | Uploaded new revision |
2021-07-05
|
11 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-07-05
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-07-05
|
11 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-11.txt |
2021-07-05
|
11 | (System) | New version approved |
2021-07-05
|
11 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Keyur Patel , Mankamana Mishra , Samir Thoria , Wen Lin |
2021-07-05
|
11 | Mankamana Mishra | Uploaded new revision |
2021-06-15
|
10 | Martin Vigoureux | Notification list changed to none from slitkows.ietf@gmail.com |
2021-06-15
|
10 | Martin Vigoureux | Document shepherd changed to Stephane Litkowski |
2021-06-07
|
10 | Martin Vigoureux | Notification list changed to slitkows.ietf@gmail.com from slitkows@cisco.com |
2021-06-07
|
10 | Martin Vigoureux | Notification list changed to slitkows@cisco.com from litkowski |
2021-06-07
|
10 | Martin Vigoureux | Notification list changed to litkowski from Stephane Litkowski <stephane.litkowski@orange.com> |
2021-06-07
|
10 | (System) | Changed action holders to Keyur Patel, Ali Sajassi, Martin Vigoureux, John Drake, Wen Lin, Samir Thoria, Mankamana Mishra (IESG state changed) |
2021-06-07
|
10 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-05-29
|
10 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-10.txt |
2021-05-29
|
10 | (System) | New version approved |
2021-05-29
|
10 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Keyur Patel , Mankamana Mishra , Samir Thoria , Wen Lin |
2021-05-29
|
10 | Mankamana Mishra | Uploaded new revision |
2021-04-21
|
09 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-04-21
|
09 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2021-04-19
|
09 | Stephane Litkowski | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is standard track and it is the appropriate type as the document defines protocol extensions. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This draft enables in an EVPN network: flooding reduction of IGMP messages, distributed anycast multicast proxy and selective multicast (forward multicast only to PEs that have interest). Working Group Summary: The draft has been updated multiple times due to a good amount of discussions. An important change on the encoding has been introduced late in the process but this change has been agreed and has a consensus in the WG. Document Quality: There are implementations of the specification. Personnel: Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd provided multiple sets of comments to authors that have been addressed. The document is considered as ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concern (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are 3 IPRs disclosed (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a solid consensus and it s involving multiple vendors and operators. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Done (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section is properly written and early allocation has been already done. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. n/a (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. n/a (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? n/a |
2021-04-19
|
09 | Stephane Litkowski | Responsible AD changed to Martin Vigoureux |
2021-04-19
|
09 | Stephane Litkowski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-04-19
|
09 | Stephane Litkowski | IESG state changed to Publication Requested from I-D Exists |
2021-04-19
|
09 | Stephane Litkowski | IESG process started in state Publication Requested |
2021-04-19
|
09 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-09.txt |
2021-04-19
|
09 | (System) | New version approved |
2021-04-19
|
09 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Keyur Patel , Mankamana Mishra , Samir Thoria , Wen Lin |
2021-04-19
|
09 | Mankamana Mishra | Uploaded new revision |
2021-04-19
|
08 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-08.txt |
2021-04-19
|
08 | (System) | New version approved |
2021-04-19
|
08 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Keyur Patel , Mankamana Mishra , Samir Thoria , Wen Lin |
2021-04-19
|
08 | Mankamana Mishra | Uploaded new revision |
2021-04-19
|
07 | Stephane Litkowski | Changed consensus to Yes from Unknown |
2021-04-19
|
07 | Stephane Litkowski | Intended Status changed to Proposed Standard from None |
2021-04-19
|
07 | Stephane Litkowski | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is standard track and it is the appropriate type as the document defines protocol extensions. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This draft enables in an EVPN network: flooding reduction of IGMP messages, distributed anycast multicast proxy and selective multicast (forward multicast only to PEs that have interest). Working Group Summary: The draft has been updated multiple times due to a good amount of discussions. An important change on the encoding has been introduced late in the process but this change has been agreed and has a consensus in the WG. Document Quality: There are implementations of the specification. Personnel: Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd provided multiple sets of comments to authors that have been addressed. The document is considered as ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concern (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are 3 IPRs disclosed (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a solid consensus and it s involving multiple vendors and operators. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Done (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section is properly written and early allocation has been already done. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. n/a (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. n/a (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? n/a |
2021-04-12
|
07 | Stephane Litkowski | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-07.txt |
2021-04-12
|
07 | (System) | New version approved |
2021-04-12
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Samir Thoria , Wen Lin , bess-chairs@ietf.org |
2021-04-12
|
07 | Stephane Litkowski | Uploaded new revision |
2021-01-25
|
06 | Ali Sajassi | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-06.txt |
2021-01-25
|
06 | (System) | New version approved |
2021-01-25
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ali Sajassi , John Drake , Keyur Patel , Samir Thoria , Wen Lin , bess-chairs@ietf.org |
2021-01-25
|
06 | Ali Sajassi | Uploaded new revision |
2020-10-30
|
05 | (System) | Document has expired |
2020-04-28
|
05 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-05.txt |
2020-04-28
|
05 | (System) | New version approved |
2020-04-28
|
05 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Samir Thoria , Wen Lin , John Drake , Ali Sajassi |
2020-04-28
|
05 | Mankamana Mishra | Uploaded new revision |
2020-04-02
|
04 | (System) | Document has expired |
2019-09-30
|
04 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-04.txt |
2019-09-30
|
04 | (System) | New version approved |
2019-09-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: Samir Thoria , Keyur Patel , John Drake , Derek Yeung , bess-chairs@ietf.org, Ali Sajassi , … Request for posting confirmation emailed to previous authors: Samir Thoria , Keyur Patel , John Drake , Derek Yeung , bess-chairs@ietf.org, Ali Sajassi , Wen Lin |
2019-09-30
|
04 | Mankamana Mishra | Uploaded new revision |
2019-08-02
|
Jenny Bui | Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-bess-evpn-igmp-mld-proxy | |
2019-07-16
|
03 | Stephane Litkowski | Notification list changed to Stephane Litkowski <stephane.litkowski@orange.com> |
2019-07-16
|
03 | Stephane Litkowski | Document shepherd changed to Stephane Litkowski |
2019-07-16
|
03 | Stephane Litkowski | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-06-09
|
03 | Mankamana Mishra | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-03.txt |
2019-06-09
|
03 | (System) | New version approved |
2019-06-09
|
03 | (System) | Request for posting confirmation emailed to previous authors: Samir Thoria , Keyur Patel , John Drake , Derek Yeung , Ali Sajassi , Wen Lin |
2019-06-09
|
03 | Mankamana Mishra | Uploaded new revision |
2018-12-27
|
02 | (System) | Document has expired |
2018-06-25
|
02 | Ali Sajassi | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-02.txt |
2018-06-25
|
02 | (System) | New version approved |
2018-06-25
|
02 | (System) | Request for posting confirmation emailed to previous authors: Samir Thoria , Keyur Patel , John Drake , Derek Yeung , Ali Sajassi , Wen Lin |
2018-06-25
|
02 | Ali Sajassi | Uploaded new revision |
2018-03-17
|
01 | Stephane Litkowski | Added to session: IETF-101: bess Tue-1550 |
2018-03-04
|
01 | Ali Sajassi | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-01.txt |
2018-03-04
|
01 | (System) | New version approved |
2018-03-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: Samir Thoria , Keyur Patel , John Drake , Derek Yeung , Ali Sajassi , Wen Lin |
2018-03-04
|
01 | Ali Sajassi | Uploaded new revision |
2017-09-28
|
00 | (System) | Document has expired |
2017-08-03
|
00 | Martin Vigoureux | This document now replaces draft-sajassi-bess-evpn-igmp-mld-proxy instead of None |
2017-03-27
|
00 | Ali Sajassi | New version available: draft-ietf-bess-evpn-igmp-mld-proxy-00.txt |
2017-03-27
|
00 | (System) | New version approved |
2017-03-27
|
00 | Ali Sajassi | Request for posting confirmation emailed to submitter and authors: Samir Thoria , Derek Yeung , John Drake , Keyur Patel , Ali Sajassi , Wen … Request for posting confirmation emailed to submitter and authors: Samir Thoria , Derek Yeung , John Drake , Keyur Patel , Ali Sajassi , Wen Lin |
2017-03-27
|
00 | Ali Sajassi | Uploaded new revision |