Re: [bess] WG adoption for draft-skr-bess-evpn-redundant-mcast-source

Hi Jorge,
thank you for your detailed answers to my questions. I'm looking forward to
discussing the applicability of BFD in scenarios addressed by this draft.

Dear All,
I support the adoption of this draft by the BESS WG.

Regards,
Greg

On Thu, Jan 14, 2021 at 3:10 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> Hi Greg,
>
>
>
> Thanks for reviewing it.
>
> Please see my comments in-line.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>
> *Date: *Wednesday, January 13, 2021 at 7:14 PM
> *To: *slitkows.ietf@gmail.com <slitkows.ietf@gmail.com>, bess@ietf.org <
> bess@ietf.org>, draft-skr-bess-evpn-redundant-mcast-source@ietf.org <
> draft-skr-bess-evpn-redundant-mcast-source@ietf.org>
> *Subject: *Re: [bess] WG adoption for
> draft-skr-bess-evpn-redundant-mcast-source
>
> Hi,
>
> I haven't seen any response to my questions from the authors. I'd greatly
> appreciate answers to help me understand this draft better and if I support
> the adoption by the BESS WG.
>
> [jorge] it would be great if you can support the adoption. Please see
> below.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jan 7, 2021 at 2:19 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Authors,
>
> thank you for the well-written and very interesting document. I read it
> and have some questions:
>
> · the Abstract states that
>
>    Existing multicast techniques assume there are no
>    redundant sources sending the same flow to the same IP multicast
>    group, and, in case there were redundant sources, the receiver's
>    application would deal with the received duplicated packets.
>
> That doesn't seem to be entirely accurate considering the content and
> scope of draft-ietf-bess-mvpn-fast-failover
> <https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/>.
>
> [jorge] we can modify the text to clarify better, but I think the
> mvpn-fast-failover draft does not change the way MVPN or PIM interpret
> redundant sources. MVPN assumes multiple PEs can be multi-homed to the same
> source, and the downstream PEs perform UMH to select the upstream PE to
> where to send the join route. It is also possible have separate physical
> sources with the same IP as explained in the following text in the draft,
> but no separate sources with different IPs sending the same multicast flow.
>
>
>
> As a workaround in conventional IP multicast (PIM or MVPN networks),
>
>    if all the redundant sources are given the same IP address, each
>
>    receiver will get only one flow.  The reason is that, in conventional
>
>    IP multicast, (S,G) state is always created by the RP (Rendezvous
>
>    Point), and sometimes by the Last Hop Router (LHR).  The (S,G) state
>
>    always binds the (S,G) flow to a source-specific tree, rooted at the
>
>    source IP address.  If multiple sources have the same IP address, one
>
>    may end up with multiple (S,G) trees.  However, the way the trees are
>
>    constructed ensures that any given LHR or RP is on at most one of
>
>    them.  The use of an anycast address assigned to multiple sources may
>
>    be useful for warm standby redundancy solutions.  However, on one
>
>    hand, it's not really helpful for hot standby redundancy solutions
>
>    and on the other hand, configuring the same IP address (in particular
>
>    IPv4 address) in multiple sources may bring issues if the sources
>
>    need to be reached by IP unicast traffic or if the sources are
>
>    attached to the same Broadcast Domain.
>
>
>
> · Section 3 defines the BGP extension is the support of the redundant
> multicast source. How these are related to the Standby PE Community,
> defined in draft-ietf-bess-mvpn-fast-failover?
>
> [jorge] there is no need for standby PE community here. The procedures are
> defined for EVPN family. The standby PE community is defined for the
> mvpn-ip c-mcast routes. Note that in EVPN the procedures are different,
> there are no c-mcast routes that are “targeted” to a specific upstream PE
> (carry vrf-import ext communities), but rather SMET routes that use regular
> route-targets and are imported by all the upstream PEs.
>
> · Section 5.1 points to an optional use of BFD to detect the failure in a
> multicast tunnel. Do you see any differences with how RFC 8562 being
> applied to monitor the status of a multicast tunnel in MVPN, as described
> in draft-ietf-bess-mvpn-fast-failover? Could procedures defined in the
> latter document be used for multicast services in EVPN networks and, in
> particular, when there is a redundant multicast source?
>
> [jorge] as already discussed/requested in the past we would appreciate
> your feedback for this section. In previous versions we had a reference to
> draft-ietf-bess-mvpn-fast-failover, but we changed it since
> ietf-bess-evpn-bfd-01 is focused on EVPN and seems more appropriate, but
> again I hope we can get this section right with your help once the document
> is adopted.
>
> Much appreciate your consideration and looking forward to your response.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jan 7, 2021 at 9:56 AM Tarek Saad <tsaad=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> I support the adoption.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
>
>
> On 12/1/20, 4:31 AM, "BESS on behalf of slitkows.ietf@gmail.com" <
> bess-bounces@ietf.org on behalf of slitkows.ietf@gmail.com> wrote:
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-skr-bess-evpn-redundant-mcast-source
> <http://tools.ietf.org/html/draft-skr-bess-evpn-redundant-mcast-source>
> [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 15th December 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>