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

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Jan 2021 17:38:37 +0000

support

Juniper Business Use Only
From: BESS <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, December 1, 2020 4:31 AM
To: [email-masked]; [email-masked]
Subject: [bess] WG adoption for draft-skr-bess-evpn-redundant-mcast-source

[External Email. Be cautious of content]

Hello,

This email begins a two-weeks WG adoption poll for draft-skr-bess-evpn-redundant-mcast-source<https://urldefense.com/v3/__http:/tools.ietf.org/html/draft-skr-bess-evpn-redundant-mcast-source__;!!NEt6yMaO-gk!QuPLjhAMf6LDa73zYFklOwXbbCw3BWkKs_Q2PJ8HJGwEodpSrG4DT7l2r_XLJM49$> [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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/__;!!NEt6yMaO-gk!QuPLjhAMf6LDa73zYFklOwXbbCw3BWkKs_Q2PJ8HJGwEodpSrG4DT7l2r6Alo_XN$>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 7 Jan 2021 09:40:10 -0800

yes/support

Cheers,
Jeff
On Dec 1, 2020, 4:31 AM -0800, [email-masked], wrote:
> This email begins a two-weeks WG adoption poll for draft-skr-bess-evpn-redundant-mcast-source [1].
>
> [1]  https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/
>
>
>
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> www.ietf.org/mailman/listinfo/bess

---

From: Tarek Saad <[email-masked]>
Date: Thu, 7 Jan 2021 17:55:50 +0000

I support the adoption.

Regards,
Tarek

On 12/1/20, 4:31 AM, "BESS on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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].

Regards,
Matthew and Stephane

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Jan 2021 14:19:00 -0800

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/>.

   - 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?
   - 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?

Much appreciate your consideration and looking forward to your response.

Regards,
Greg

On Thu, Jan 7, 2021 at 9:56 AM Tarek Saad <tsaad=
[email-masked]> wrote:

> I support the adoption.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
>
>
> On 12/1/20, 4:31 AM, "BESS on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> 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].
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/
>
>
>
>
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Jan 2021 10:14:32 -0800

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.

Regards,
Greg

On Thu, Jan 7, 2021 at 2:19 PM Greg Mirsky <[email-masked]> wrote:

> Dear Authors,
> thank you for the well-written and very interesting document. I read it
> and have some questions:
>
> That doesn't seem to be entirely accurate considering the content and
> scope of draft-ietf-bess-mvpn-fast-failover
>    - 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?
>

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 14 Jan 2021 11:10:16 +0000

Hi Greg,

Thanks for reviewing it.
Please see my comments in-line.

Thanks.
Jorge

From: Greg Mirsky <[email-masked]>
Date: Wednesday, January 13, 2021 at 7:14 PM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> wrote:
I support the adoption.

Regards,
Tarek

Hello,

Regards,
Matthew and Stephane

Juniper Business Use Only
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 14 Jan 2021 12:34:17 -0800

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) <
[email-masked]> wrote:

> *From: *Greg Mirsky <[email-masked]>
> *Date: *Wednesday, January 13, 2021 at 7:14 PM
> *To: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [bess] WG adoption for
> [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.
>
>
>
> · Section 3 defines the BGP extension is the support of the redundant
> [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
> [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.
>

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 14 Jan 2021 20:36:55 +0000

Appreciated Greg.

Thanks.
Jorge

From: Greg Mirsky <[email-masked]>
Date: Thursday, January 14, 2021 at 9:34 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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,

Regards,
Greg

On Thu, Jan 14, 2021 at 3:10 AM Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks for reviewing it.

Thanks.
Jorge

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 13, 2021 at 7:14 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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

• the Abstract states that

• 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

Regards,
Tarek

Hello,

Regards,
Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 Jan 2021 23:06:12 -0500

I support WG adoption.

Thanks

Gyan

On Thu, Jan 14, 2021 at 3:37 PM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> *Date: *Thursday, January 14, 2021 at 9:34 PM
> *To: *Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> 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,
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD