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

["Rabadan, Jorge (Nokia - US/Sunnyvale)" <[e-mail]>]

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) <[e-mail]>
Date: Friday, July 15, 2022 at 2:56 AM
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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