[bess] Shepherd review Comment on draft-ietf-bess-evpn-redundant-mcast-source-03

["Mankamana Mishra (mankamis)" <[e-mail]>]

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