Hi Mankamana, Thank you for your review. We’ve published version 04, which addresses your comments. Also incorporates Greg Mirsky’s comments (thanks Greg!) about the section that talks about the optional use of BFD in the solution. By the way, this section has a reference to draft-ietf-bess-evpn-bfd-03 - EVPN Network Layer Fault Management<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/> which seems to be expired for some time. Any plans to refresh the draft and move it to WG LC soon?
Also, please check out my comments in-line with [jorge]. Thanks! Jorge From: Mankamana Mishra (mankamis) <manka...@cisco.com> Date: Friday, July 15, 2022 at 2:56 AM To: draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org <draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: Shepherd review Comment on draft-ietf-bess-evpn-redundant-mcast-source-03 Authors, Please find some initial comments . 16 Abstract 18 EVPN supports intra and inter-subnet IP multicast forwarding. 19 However, EVPN (or conventional IP multicast techniques for that 20 matter) do not have a solution for the case where: a) a given 21 multicast group carries more than one flow (i.e., more than one 22 source), and b) it is desired that each receiver gets only one of the 23 several flows. Existing multicast techniques assume there are no 24 redundant sources sending the same flow to the same IP multicast 25 group, and, in case there were redundant sources, the receiver's 26 application would deal with the received duplicated packets. This 27 document extends the existing EVPN specifications and assumes that IP 28 Multicast source redundancy may exist. Highlighted statement does not seems correct. We do carry (S1, G) and (S2, G) where same group is carrying two different flows. I assume the point which authors want to bring out that same content being sourced by different source and receiver want to receive only one of them. But this statement does not convey that message clearly. [jorge] I tried to clarify it better, let me know if the modifications help: However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. [I-D.ietf-bess-evpn-igmp-mld-proxy] Please replace this with RFC now. [jorge] done 92 1. Introduction 94 Intra and Inter-subnet IP Multicast forwarding are supported in EVPN 95 networks. [I-D.ietf-bess-evpn-igmp-mld-proxy] describes the 96 procedures required to optimize the delivery of IP Multicast flows 97 when Sources and Receivers are connected to the same EVPN BD 98 (Broadcast Domain), whereas [I-D.ietf-bess-evpn-irb-mcast] specifies 99 the procedures to support Inter-subnet IP Multicast in a tenant 100 network. Inter-subnet IP Multicast means that IP Multicast Source 101 and Receivers of the same multicast flow are connected to different 102 BDs of the same tenant. Should this also not give reference about https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mvpn-seamless-interop-04 and can mention that this document does not cover the cases about how redundant source would be handled with seamless draft. [jorge] I added this in the introduction: The procedures to handle redundant sources in solutions different than [RFC9251<https://author-tools.ietf.org/api/export/78dde478-172c-4b9e-96c7-d72e3c33aa74/draft-ietf-bess-evpn-redundant-mcast-source-04.html#RFC9251>] or [I-D.ietf-bess-evpn-irb-mcast<https://author-tools.ietf.org/api/export/78dde478-172c-4b9e-96c7-d72e3c33aa74/draft-ietf-bess-evpn-redundant-mcast-source-04.html#I-D.ietf-bess-evpn-irb-mcast>] are out of the scope of this document. 104 [I-D.ietf-bess-evpn-igmp-mld-proxy], [I-D.ietf-bess-evpn-irb-mcast] 105 or conventional IP multicast techniques do not have a solution for 106 the case where a given multicast group carries more than one flow 107 (i.e., more than one source) and it is desired that each receiver 108 gets only one of the several flows. Multicast techniques assume 109 there are no redundant sources sending the same flows to the same IP 110 multicast group, and, in case there were redundant sources, the 111 receiver's application would deal with the received duplicated 112 packets. Same comment as first section, this statement is not bringing out the case clearly. [jorge] changed along the same lines. 114 As a workaround in conventional IP multicast (PIM or MVPN networks), 115 if all the redundant sources are given the same IP address, each 116 receiver will get only one flow. The reason is that, in conventional 117 IP multicast, (S,G) state is always created by the RP (Rendezvous 118 Point), and sometimes by the Last Hop Router (LHR). Always and sometimes are contradictory here. [jorge] changed to: The reason is that, in conventional IP multicast, the RP (Rendezvous Point) always creates (S,G) state, and the Last Hop Router (LHR) sometimes creates (S,G) state. The use of an anycast address assigned to multiple sources may 124 be useful for warm standby redundancy solutions. However, on one 125 hand, it's not really helpful for hot standby redundancy solutions 126 and on the other hand, configuring the same IP address (in particular 127 IPv4 address) in multiple sources may bring issues if the sources 128 need to be reached by IP unicast traffic or if the sources are 129 attached to the same Broadcast Domain. May be point to section which defines this. This document has not spoken about what hot standby is yet. 131 In addition, in the scenario where several G-sources are attached via 132 EVPN/OISM, there is not necessarily any (S,G) state created for the Not defined yet. [jorge] added reference. Therefore, this document 135 extends the above two specifications and assumes that IP Multicast 136 source redundancy may exist. It also assumes that, in case two or 137 more sources send the same IP Multicast flows into the tenant domain, 138 the EVPN PEs need to avoid that the receivers get packet duplication. Please mention this document does not talk about how this should be handled for PIM or MVPN cases. And it mostly covers the EVPN use cases. [jorge] added this: The procedures to handle redundant sources in solutions different than [RFC9251<https://author-tools.ietf.org/api/export/78dde478-172c-4b9e-96c7-d72e3c33aa74/draft-ietf-bess-evpn-redundant-mcast-source-04.html#RFC9251>] or [I-D.ietf-bess-evpn-irb-mcast<https://author-tools.ietf.org/api/export/78dde478-172c-4b9e-96c7-d72e3c33aa74/draft-ietf-bess-evpn-redundant-mcast-source-04.html#I-D.ietf-bess-evpn-irb-mcast>] are out of the scope of this document. 42 the upstream PEs attached to the redundant sources of the same 143 tenant, make sure that only one source of the same flow can send 144 multicast to the interested downstream PEs at the same time. In HS 145 the upstream PEs forward the redundant multicast flows to the 146 downstream PEs, and the downstream PEs make sure only one flow is 147 forwarded to the interested attached receivers. Getting defined later in terminology and used here. [jorge] I think it makes sense to define the warm standby and hot standby solutions, from a high level perspective, in the introduction. The rest of the document expands on those two concepts. 190 * G-source: any system sourcing IP multicast traffic to G. Traffic to Group G. [jorge] done 192 * SFG: Single Flow Group, i.e., a multicast group address G which 193 represents traffic that contains only a single flow. However, 194 multiple sources - with the same or different IP - may be 195 transmitting an SFG. Is this statement / assumption correct ? what about the case where Group G has 4 flows where {S1, S2, S3, S4, S5} , G --- Flow 1 {S6, S7, S8, S9, S10} , G --- Flow 2 {S11, S12, S13, S14, S15} , G --- Flow 3 {S16, S17, S18, S19, S20} , G --- Flow 4 Here these group of source do represent the same multicast content. But its always not true that group will represent only 1 flow. [jorge] Good point. I changed the definition to convey the meaning in this document: · SFG: Single Flow Group, i.e., a multicast group which represents traffic that contains only a single flow. Multiple sources - with the same or different IP - may be transmitting an SFG. An SFG is represented as (*,G) if any source that issues multicast traffic to G is a redundant G-source. An SFG can also be represented as (S,G), where S is a prefix of any length. In this case, a source is considered a redundant G-source for the SFG if it is contained in the prefix. 593 As an example: 595 * PE1 is configured to know that G1 is an SFG for any source and 596 redundant G-sources for G1 may be attached to BD1 or BD2. 598 * Or PE1 can also be configured to know that G1 is an SFG for 599 the sources contained in 10.0.0.0/30, and those redundant 600 G-sources may be attached to BD1 or BD2. It may be good to point figure , if PE1 is coming from some figure . [jorge] added. 628 * The S-PMSI A-D route is triggered by the first packet of the 629 SFG and withdrawn when the flow is not received anymore. 630 Detecting when the G-source is no longer active is a local 631 implementation matter. The use of a timer is RECOMMENDED
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
