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. [I-D.ietf-bess-evpn-igmp-mld-proxy] Please replace this with RFC now. 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. 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. 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. 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. 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. 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. 190 * G-source: any system sourcing IP multicast traffic to G. Traffic to Group G. 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. 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 . 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. 632 The timer is started when the traffic to G1 is not received. 633 Upon expiration of the timer, the PE will withdraw the route Do we have any recommendations for default timer value too ? 819 Even for single-homed redundant G-sources the HS procedure relies 820 on the ESI labels for the RPF check on downstream PEs. The term 821 "S-ESI" is used in this document to refer to an ESI associated to 822 a redundant G-source. Not defined what it is, how to derive . what value it would be . Rest commets to follow. Mankamana
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
