Hi Greg, Thanks for reviewing it. Please see my comments in-line.
Thanks. Jorge From: Greg Mirsky <[email protected]> Date: Wednesday, January 13, 2021 at 7:14 PM To: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: I support the adoption. Regards, Tarek On 12/1/20, 4:31 AM, "BESS on behalf of [email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
