I support WG adoption. Thanks
Gyan On Thu, Jan 14, 2021 at 3:37 PM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.raba...@nokia.com> wrote: > Appreciated Greg. > > > > Thanks. > > Jorge > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, January 14, 2021 at 9:34 PM > *To: *Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> > *Cc: *slitkows.i...@gmail.com <slitkows.i...@gmail.com>, bess@ietf.org < > bess@ietf.org>, draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org < > draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org> > *Subject: *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.raba...@nokia.com> wrote: > > Hi Greg, > > > > Thanks for reviewing it. > > Please see my comments in-line. > > > > Thanks. > > Jorge > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Wednesday, January 13, 2021 at 7:14 PM > *To: *slitkows.i...@gmail.com <slitkows.i...@gmail.com>, bess@ietf.org < > bess@ietf.org>, draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org < > draft-skr-bess-evpn-redundant-mcast-sou...@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 <gregimir...@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....@dmarc.ietf.org> wrote: > > I support the adoption. > > > > Regards, > > Tarek > > > > > > > > On 12/1/20, 4:31 AM, "BESS on behalf of slitkows.i...@gmail.com" < > bess-boun...@ietf.org on behalf of slitkows.i...@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 > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
