Subject: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

From: <[email-masked]>
Date: Mon, 6 Jan 2020 15:14:49 +0100

Hello,

This email begins a two-weeks WG adoption poll for and
draft-zzhang-bess-bgp-multicast-03 [1] .

For information, it's companion document
(draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG
adoption in a separate email.

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 won't
progress without answers from all 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 *** 20th January 2020 ***  

Regards,

Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 6 Jan 2020 14:47:43 +0000

I support WG adoption.
Thanks,
Acee

From: BESS <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, January 6, 2020 at 9:15 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Hello,

This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-03 [1] ..
For information, it’s companion document (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption in a separate email.

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 won't progress without answers from all 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.

Regards,
Matthew and Stephane

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 6 Jan 2020 17:13:40 +0000

Support.

From: "[email-masked]" <[email-masked]>
Date: Monday, January 6, 2020 at 6:15 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Monday, January 6, 2020 at 6:14 AM

Hello,

This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-03 [1] .
For information, it’s companion document (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption in a separate email.

Regards,
Matthew and Stephane

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 6 Jan 2020 17:21:14 +0000

To add, not aware of any IPR related to this .

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Monday, January 6, 2020 at 9:14 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Monday, January 6, 2020 at 9:13 AM

Support.

Hello,

Regards,
Matthew and Stephane

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 6 Jan 2020 12:00:28 -0800

I am not aware of any IPR related to this draft.

-Lenny

On Mon, 6 Jan 2020, [email-masked] wrote:

| 
| Hello,
| 
|  
| 
| This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-03 [1] .
| 
| For information, it’s companion document (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption in a separate email.
| 
|  
| 
| 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 won't progress without answers from all 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 *** 20th January 2020 ***  
| 
|  
| 
| Regards,
| 
| Matthew and Stephane
| 
|  
| 
| [1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast
| 
|  
| 
| 
|

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 6 Jan 2020 20:41:49 +0000

Support as co-author.
Not aware of relevant IPRs.

Jeffrey

From: [email-masked] <[email-masked]>
Sent: Monday, January 6, 2020 9:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Hello,

This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-03 [1] .
For information, it's companion document (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption in a separate email.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast__;!!NEt6yMaO-gk!SSDeYY6gVkJEhok7Gc8ipeZK48M1l21fYa63URcJ9DLp-i72s_nUvdHVRUSAsgOi$>

---

From: Julian Lucek <[email-masked]>
Date: Mon, 6 Jan 2020 21:49:01 +0000

support

From: "[email-masked]" <[email-masked]>
Date: Monday, 6 January 2020 at 14:14
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
Resent from: <[email-masked]>

Hello,

Regards,
Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 6 Jan 2020 19:09:46 -0500

Authors

Would this draft also provide a move towards a stateless core migration of
inband signaling provided by mLDP to now be provided by BGP.

Cisco and other vendors may support BGP C-Multicast signaling out of band
signaling type 6 and 7 mVPN routes today.

I thought this was covered in one of the other MVPN RFCs but maybe not.

Could BGP also be used for SR SR-MPLS and SRv6 use cases to carry MVPN
services out of band via BGP that was traditionally carried over mLDP or
PIM.

Kind regards,

Gyan

On Mon, Jan 6, 2020 at 9:15 AM <[email-masked]> wrote:

> draft-zzhang-bess-bgp-multicast-03 [1] ..
>
> For information, it’s companion document
> 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 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.
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 7 Jan 2020 01:09:45 +0000

Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[email-masked]>
Sent: Monday, January 6, 2020 7:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Authors

Would this draft also provide a move towards a stateless core migration of inband signaling provided by mLDP to now be provided by BGP.

Zzh> This will still have per-tree state in the core. The only way to do efficient replication w/o per-tree state is BIER, at least so far.

Cisco and other vendors may support BGP C-Multicast signaling out of band signaling type 6 and 7 mVPN routes today.

Zzh> MVPN type 6/7 routes (RFC 6514) routes are for signaling multicast over a “virtual LAN” (overlaid on top of the provider core). This draft is for signaling multicast through a network (of many hops) using BGP. In some way it is similar to mLDP inband signaling but nowadays in the SR era some people want to remove LDP/RSVP entirely.

Could BGP also be used for SR SR-MPLS and SRv6 use cases to carry MVPN services out of band via BGP that was traditionally carried over mLDP or PIM.

Zzh> Not exactly sure what you’re asking; but this draft is about establishing a multicast tree (native or labeled PIM-like tree or mLDP-like P2MP tunnel), which could be used however/wherever it makes sense – e.g. w/ or w/o MVPN.
Zzh> Jeffrey

Kind regards,

Gyan

On Mon, Jan 6, 2020 at 9:15 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ7EDvK3Y$>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ6wWVdFQ$>
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZxMOqhNO$>

---

From: "Gulko, Arkadiy (Refinitiv)" <[email-masked]>
Date: Tue, 7 Jan 2020 02:38:38 +0000

Support as a co-author. I am not aware of any undisclosed IPR related to this draft.
Regards,
Arkadiy

Resent-Date: Monday, January 6, 2020 at 9:14 AM

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zzhang-bess-bgp-multicast&data=02%7C01%7Carkadiy.gulko%40refinitiv.com%7Ca55ef10e648140186c4308d792b2cfe1%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637139168999229658&sdata=tK%2FenKHLQi8r6e%2BOao0cXXLILWDO%2Fwoh1WNxDQWKNO8%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 7 Jan 2020 00:38:51 -0500

Jeffrey

I would like to comment on Introduction motivation section.

1st paragraph comments

”This section provides some motivation for BGP signaling for native and
labeled multicast. One target deployment would be a Data Center that
requires multicast but uses BGP as its only routing protocol [RFC7938]. In
such a deployment, it would be desirable to support multicast by extending
the deployed routing protocol, without requiring the deployment of tree
building protocols such as PIM, mLDP, RSVP-TE P2MP, and without requiring
an IGP.
Additionally, compared to PIM, BGP based signaling has several advantage as
described in the following section, and may be desired in non-DC deployment
scenarios as well.”

In the data center typically almost 99.99% of the time it would be PIM and
I don’t know of anywhere that  MPLS is deployed within the single data
center.  I think the reference to MPLS mLDP, TE should be removed in
context of data center. Maybe you are trying to show every possibility I am
guessing or I think depict relevant use case showing replacement of mLDP or
PIM Rosen or P2MP TE.

I don’t see how you would deploy BGP only architecture in a data center
without an IGP.

Let’s say If you had a vxlan evpn super spine with 8 nodes and so now each
node would now sit in a different AS and each spine node would as well sit
in a separate AS.

I have tried building in Cisco VIRL vxlan evpn architecture carving up the
data center pods into separate BGP ASs and its very very complex to say the
least.

In a data center there maybe typical use cases which I have deployed -
let’s say where you have a single BGP AS that spans a single data center or
you have chopped up the data center into multiple PODs fault domains that
are BGP ASs onto themselves that are inter connected.   Further in either
scenario you have deployed vxlan evpn within each Pod and build a super
spine and leaf vxlan architecture with border leaf for your vxlan VNI NVE
anycast tunnels - typical vxlan design.  In that design you deploy SSM in
your underlay as well as use SSM in your overlay. In this typical vxlan
evpn design you use the centralized or distributed multicast model to build
your trees.

I don’t see a problem that is being solved replacinf SSM as your inter or
intra domain multicast routing protocol.

What would be the advantage of using bgp for signaling the trees with a
vxlan evpn architecture over using SSM in the overlay.

2nd paragraph comments

“PIM-SSM removes much of the complexity of PIM-ASM by moving source
discovery to the application layer. However, for various reasons, many
legacy applications and devices still rely upon network-based source
discovery. PIM-Port (PIM over Reliable Transport) solves the soft state
issue, though its deployment has also been limited for two reasons:”

I disagree with the SSM issues you raised as a motivation for this draft.

As you know ASM even with its complexity and pitfalls has been around since
Day 1 and it definitely has its drawbacks for sure.  I would say the
biggest drawback of ASM is that you have to maintain an RP control plane
mechanism for source discovery and propagation of the source SAs so the
shortest path tree switchover can occur.  Complexity in ASM which can be
enormous in an enterprise arena moreso then from a SP perspective.  ASM
complexity lies in building of a MSDP mesh topology.  I have built ASM
Anycast/MSDP topologies that have had over 10k peers.  The ASM complexity
is with source discovery for large enterprises.

SSM works very well and is now the definitive best practice with PIM WG ASM
mboned being shelved as historical.  The beauty of SSM is with the
elimination of the RP control plane and Anycast/MSDP for inter domain
multicast to work.

ASM deprecated for inter domain multicast:

https://tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf

Within an enterprise migrating from ASM to SSM since RPs are eliminated and
MSDP source distribution is not needed with SSM you can collapse all of
your Multicast domains that has their own anycast RP can now all sit in the
single unified multicast domain across all administrative boundaries.

For inter domain SSM  if you really have to - BGP multicast NLRI can be
used for source propagation if necessary.

I have designed and deployed massive ASM architecture within Verizon
internally which I migrated to SSM and collapsed all the domains onto a
single multicast routing domain.

I think the draft had merit and I like the idea but I think the motivation
section needs to be cleaned up.

I really can’t see this being used in an enterprise data center scenario.
I think we have to first find a valid issue with SSM to look to replace it
or even propose an alternative.

Could this be used in an SP scenario providing EVPN services vxlan evpn or
pbb over MPLS core or even with SR SR-MPLS or SRv6. Integrate this solution
into existing MVPN mLDP, PIM, P2MP TE as an alternative solution.  This
sits in the vxlan evpn VRF overlay over the MPLS core so I think you could
apply the same end to end BGP signaling concepts for customers as a value
added service.

See forwarded below as well - inline comments.

Kind regards,

Gyan

On Mon, Jan 6, 2020 at 8:09 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Monday, January 6, 2020 7:10 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [bess] WG adoption and IPR poll for
> draft-zzhang-bess-bgp-multicast-03
>
>
>
>
>
> Authors
>
>
>
> Zzh> This will still have per-tree state in the core. The only way to do
> efficient replication w/o per-tree state is BIER, at least so far.
>
> Understood. State issues are worse with in band and  better with out of
> band MVPN deployments for both PMSI-S and PMSI-I.  It would be nice to not
> have any  state and then BIER as you stated is the only option.
>

> Zzh> MVPN type 6/7 routes (RFC 6514) routes are for signaling multicast
> over a “virtual LAN” (overlaid on top of the provider core). This draft is
> for signaling multicast through a network (of many hops) using BGP. In some
> way it is similar to mLDP inband signaling but nowadays in the SR era some
> people want to remove LDP/RSVP entirely.
>
>  Understood.  This draft is an attempt to eliminate the c-tree and p-tree
> created using Next Gen MVPN trees using  PIM Rosen, mLDP, P2MP TE and use
> BGP based trees using the similar “core tree” procedures.
>
> Zzh> Not exactly sure what you’re asking; but this draft is about
> establishing a multicast tree (native or labeled PIM-like tree or mLDP-like
> P2MP tunnel), which could be used however/wherever it makes sense – e.g. w/
> or w/o MVPN.
>
    In the draft was mentioned mLDP replacement so for that i was thinking
SR maybe a use case.

> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ7EDvK3Y$>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ6wWVdFQ$>
>
> --
>
> Gyan S. Mishra
>
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZxMOqhNO$>
>
>
>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 7 Jan 2020 14:49:47 +0000

Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[email-masked]>
Sent: Tuesday, January 7, 2020 12:39 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Jeffrey

1st paragraph comments

”This section provides some motivation for BGP signaling for native and labeled multicast. One target deployment would be a Data Center that requires multicast but uses BGP as its only routing protocol [RFC7938]. In such a deployment, it would be desirable to support multicast by extending the deployed routing protocol, without requiring the deployment of tree building protocols such as PIM, mLDP, RSVP-TE P2MP, and without requiring an IGP.
Additionally, compared to PIM, BGP based signaling has several advantage as described in the following section, and may be desired in non-DC deployment scenarios as well.”

In the data center typically almost 99.99% of the time it would be PIM and I don’t know of anywhere that  MPLS is deployed within the single data center.  I think the reference to MPLS mLDP, TE should be removed in context of data center. Maybe you are trying to show every possibility I am guessing or I think depict relevant use case showing replacement of mLDP or PIM Rosen or P2MP TE.

Zzh> Sure I can keep PIM only in this.

I don’t see how you would deploy BGP only architecture in a data center without an IGP.

Zzh> That is outside the scope of this document; the rational and practice is well documented in RFC7938 (that the above quoted paragraph refers to).

Let’s say If you had a vxlan evpn super spine with 8 nodes and so now each node would now sit in a different AS and each spine node would as well sit in a separate AS.

I have tried building in Cisco VIRL vxlan evpn architecture carving up the data center pods into separate BGP ASs and its very very complex to say the least.

In a data center there maybe typical use cases which I have deployed - let’s say where you have a single BGP AS that spans a single data center or you have chopped up the data center into multiple PODs fault domains that are BGP ASs onto themselves that are inter connected.   Further in either scenario you have deployed vxlan evpn within each Pod and build a super spine and leaf vxlan architecture with border leaf for your vxlan VNI NVE anycast tunnels - typical vxlan design.  In that design you deploy SSM in your underlay as well as use SSM in your overlay. In this typical vxlan evpn design you use the centralized or distributed multicast model to build your trees.

I don’t see a problem that is being solved replacinf SSM as your inter or intra domain multicast routing protocol.

What would be the advantage of using bgp for signaling the trees with a vxlan evpn architecture over using SSM in the overlay.

Zzh> Let’s put aside underlay/overlay thing but only look at multicast trees itself (a tree could be in the underlay itself, or the EVPN overlay is just “one hop” – a simulated LAN – of the tree).
Zzh> Some people don’t like to run PIM at all in their network. Some accept PIM, but want to consolidate to BGP after they deploy RFC7938.
Zzh> BGP signaling replacing PIM-SSM removes PIM refreshes and removes the PIM protocol. The latter matters only for those who really care about “removing another protocol”.
Zzh> BGP signaling replacing PIM-ASM removes the complexity of PIM-AS complexity and corresponding fragility in some implementations. More below on this.

2nd paragraph comments

“PIM-SSM removes much of the complexity of PIM-ASM by moving source discovery to the application layer. However, for various reasons, many legacy applications and devices still rely upon network-based source discovery. PIM-Port (PIM over Reliable Transport) solves the soft state issue, though its deployment has also been limited for two reasons:”

As you know ASM even with its complexity and pitfalls has been around since Day 1 and it definitely has its drawbacks for sure.  I would say the biggest drawback of ASM is that you have to maintain an RP control plane mechanism for source discovery and propagation of the source SAs so the shortest path tree switchover can occur.  Complexity in ASM which can be enormous in an enterprise arena moreso then from a SP perspective.  ASM complexity lies in building of a MSDP mesh topology.  I have built ASM Anycast/MSDP topologies that have had over 10k peers.  The ASM complexity is with source discovery for large enterprises.

SSM works very well and is now the definitive best practice with PIM WG ASM mboned being shelved as historical.  The beauty of SSM is with the elimination of the RP control plane and Anycast/MSDP for inter domain multicast to work.

Zzh> The above two paragraphs of yours endorses the first sentence in the paragraph that you quoted 😊 BTW – even if MSDP is not used, PIM-ASM still has its complexities.
Zzh> The quoted paragraph then further points out many deployments still relies on “network-based source discovery” (i.e., RPT->SPT switching or MSDP), laying the foundation that this draft introduces BGP-based source discovery mechanism for those who still need network-based source discovery.
Zzh> Notice that we’re not saying SSM is bad. Rather, SSM is what we want to do, but the draft is about BGP-SSM (a step up from PIM-SSM) with BGP-based source discovery.

https://tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf<https://urldefense.com/v3/__https:/tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83lmj4OL$>

Within an enterprise migrating from ASM to SSM since RPs are eliminated and MSDP source distribution is not needed with SSM you can collapse all of your Multicast domains that has their own anycast RP can now all sit in the single unified multicast domain across all administrative boundaries.

For inter domain SSM  if you really have to - BGP multicast NLRI can be used for source propagation if necessary.

I have designed and deployed massive ASM architecture within Verizon internally which I migrated to SSM and collapsed all the domains onto a single multicast routing domain.

Zzh> One important motivation of the draft is to provide means of supporting SSM even when there is no application-based source discovery.

I think the draft had merit and I like the idea but I think the motivation section needs to be cleaned up.

Zzh> I thought our motives are perfectly aligned? 😊

I really can’t see this being used in an enterprise data center scenario.  I think we have to first find a valid issue with SSM to look to replace it or even propose an alternative.

zzh> DC was mentioned because it is a perfect starting point scenario, at least for those operators who deploy RFC7938 and don’t want to run PIM in their DC (even though they have multicast need).
Zzh> Of course it can be used for any scenario where: 1. The operator is open to run BGP on every node (could be for multicast purpose only) 2. The operator wants to remove the complexity of PIM-ASM and inefficiency of PIM, or the operator wants to replace mLDP protocol.

Could this be used in an SP scenario providing EVPN services vxlan evpn or pbb over MPLS core or even with SR SR-MPLS or SRv6. Integrate this solution into existing MVPN mLDP, PIM, P2MP TE as an alternative solution.  This sits in the vxlan evpn VRF overlay over the MPLS core so I think you could apply the same end to end BGP signaling concepts for customers as a value added service.

Zzh> The highlighted red text in your paragraph is the key (and mentioned in the first paragraph you quoted 😊). The before/after sentences are orthogonal (whatever service is fine) 😊

Zzh> More zzh2> below.

Kind regards,

Gyan

On Mon, Jan 6, 2020 at 8:09 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 6, 2020 7:10 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

Authors

Zzh> This will still have per-tree state in the core. The only way to do efficient replication w/o per-tree state is BIER, at least so far.
Understood. State issues are worse with in band and  better with out of band MVPN deployments for both PMSI-S and PMSI-I.  It would be nice to not have any  state and then BIER as you stated is the only option.

Zzh> MVPN type 6/7 routes (RFC 6514) routes are for signaling multicast over a “virtual LAN” (overlaid on top of the provider core). This draft is for signaling multicast through a network (of many hops) using BGP. In some way it is similar to mLDP inband signaling but nowadays in the SR era some people want to remove LDP/RSVP entirely.
 Gyan> Understood.  This draft is an attempt to eliminate the c-tree and p-tree created using Next Gen MVPN trees using  PIM Rosen, mLDP, P2MP TE and use BGP based trees using the similar “core tree” procedures.
Zzh2> This draft is only about establishing multicast trees/tunnels using BGP signaling. The resulting trees/tunnels can be used for whatever purposes.
I thought this was covered in one of the other MVPN RFCs but maybe not.

Zzh> Not exactly sure what you’re asking; but this draft is about establishing a multicast tree (native or labeled PIM-like tree or mLDP-like P2MP tunnel), which could be used however/wherever it makes sense – e.g. w/ or w/o MVPN.
Gyan> In the draft was mentioned mLDP replacement so for that i was thinking SR maybe a use case.
   Zzh2> It can certainly be used in an SR network (if the operator wants to remove PIM/mLDP/RSVP-TE P2MP).
   Zzh2> Thanks!
Zzh> Jeffrey

Kind regards,

Gyan

Regards,
Matthew and Stephane

13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike?entry=gmail&source=g__;Kys!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83pxKc0T$> FDC1 3rd Floor

www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI89SlT2YC$>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 Jan 2020 02:50:10 -0500

Hi Jeffery

Pleas see in line Gyan>

On Tue, Jan 7, 2020 at 9:49 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Tuesday, January 7, 2020 12:39 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Additionally, compared to PIM, BGP based signaling has several advantage
> as described in the following section, and may be desired in non-DC
> deployment scenarios as well.”
>
>
>
     Gyan> Maybe you can reword and say without requiring the deployment of
tree building protocols such as PIM for Data Center & mLDP, RSVP-TE P2MP
for Non Data Center networks inclusive such as for Segment Routing.

> Zzh> That is outside the scope of this document; the rational and practice
> is well documented in RFC7938 (that the above quoted paragraph refers to).
>
>
    Gyan> I actually read RFC 7938 when I was redesigning a data center
architecture for stability using a L3 smaller fault domain design.  This
BGP signaling of trees feature has to be used with eBGP and not iBGP as
that requires IGP which would now be in the RIB for RPF path so would not
work thus the "no IGP" requirement as per RFC 7938.  If you had directly
connected iBGP peers and not loop-loop so that you don't need an IGP, could
the BGP signaled tree feature still work. In theory your spine & leaf could
all be directly connected iBGP peers and all now sit in one AS and not have
an IGP.  This would eliminate the need to have ASNs deployed.  So with this
feature the last hop router signals join similar to mLDP inband via BGP and
the join is sent via BGP signalled tree.  With the BGP trees using the same
MVPN mLDP procedures is their a concept of PMSI-I inclusive trees c-tree
p-tree so a single tree  P2MP or MP2MP can be shared by all groups or is it
1-1 mapping group to tree.  Is their any way to minimize per GDA state with
BGP trees.  For the BGP trees is it possible use the same MVPN BGP A-D and
c-tree p-tree Type 6 & 7 routes BGP multicast c-signalling.   Doing so
could you leverage the PMSI-I inclusive tree MVPN feature so you don't have
per GDA state

> Zzh> Let’s put aside underlay/overlay thing but only look at multicast
> trees itself (a tree could be in the underlay itself, or the EVPN overlay
> is just “one hop” – a simulated LAN – of the tree).
>
> Zzh> Some people don’t like to run PIM at all in their network. Some
> accept PIM, but want to consolidate to BGP after they deploy RFC7938.
>
> Zzh> BGP signaling replacing PIM-SSM removes PIM refreshes and removes the
> PIM protocol. The latter matters only for those who really care about
> “removing another protocol”.
>
> Zzh> BGP signaling replacing PIM-ASM removes the complexity of PIM-AS
> complexity and corresponding fragility in some implementations. More below
> on this.
>
>
>
> 2nd paragraph comments
>
>
>
> As you know ASM even with its complexity and pitfalls has been around
> since Day 1 and it definitely has its drawbacks for sure.  I would say the
> SSM works very well and is now the definitive best practice with PIM WG
> ASM mboned being shelved as historical.  The beauty of SSM is with the
> Zzh> The above two paragraphs of yours endorses the first sentence in the
> paragraph that you quoted 😊 BTW – even if MSDP is not used, PIM-ASM
> still has its complexities.
>
> Zzh> The quoted paragraph then further points out many deployments still
> relies on “network-based source discovery” (i.e., RPT->SPT switching or
> MSDP), laying the foundation that this draft introduces BGP-based source
> discovery mechanism for those who still need network-based source
> discovery.
>
    Gyan> Source discovery is only necessary with ASM not SSM. With SSM the
receiver is "source" aware so does not require any discovery mechanism.
So with SSM which requires IGMPv3 enabled on the receiver last hop router
subnets and on the source first hop router subnet for the both to be
"source aware" ; for the receiver now to send the (S,G) join for the
channel since it is now source aware. How the receiver gets that source
awareness is from the server URI that the user connects to which has the
S,G information ; server has to be also  source aware and has S,G channel
available that can be joined. With IGMPv3 the packet  accommodate the
Source information in the S,G join sent along the RPF path to the source.
You mention that SSM deployment has been limited but in fact the opposite
and reason why ASM is being officially deprecated by the IETF for inter
domain multicast routing. IPv6 does not even have MSDP support since with
ASM MSDP source discovery and propagation is not necessary since no RPs
exist all disparate ASM multicast domains can now be collapsed into a
single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6
nixed the idea of integrating MSDP into the architecture. Thus IPv6 only
supports SSM for inter-domain multicast routing. I would keep the comment
about ASM complexity which is true but remove mention of SSM.  I would not
mention any gains with less state as you would still have to maintain IGMP
join state with BGP with 1-1 mappings of GDA to tree so the tree state is
not being eliminated.

> Zzh> Notice that we’re not saying SSM is bad. Rather, SSM is what we want
> to do, but the draft is about BGP-SSM (a step up from PIM-SSM) with
> BGP-based source discovery.
>
>
   Gyan> "While PIM-SSM removes the complexity of PIM-ASM, it requires that

   multicast sources are known apriori.  There have not been a good way
   of discovering sources, so its deployment has been limited."

> <https://urldefense.com/v3/__https:/tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83lmj4OL$>
>
>
>
>
>
> Within an enterprise migrating from ASM to SSM since RPs are eliminated
> and MSDP source distribution is not needed with SSM you can collapse all of
> Zzh> One important motivation of the draft is to provide means of
> supporting SSM even when there is no application-based source discovery.
>
>
>
> zzh> DC was mentioned because it is a perfect starting point scenario, at
> least for those operators who deploy RFC7938 and don’t want to run PIM in
> their DC (even though they have multicast need).
>
> Zzh> Of course it can be used for any scenario where: 1. The operator is
> open to run BGP on every node (could be for multicast purpose only) 2. The
> operator wants to remove the complexity of PIM-ASM and inefficiency of PIM,
> or the operator wants to replace mLDP protocol.
>
>
>
> pbb over MPLS core or even with SR SR-MPLS or SRv6. Integrate this
> solution into existing MVPN mLDP, PIM, P2MP TE as an alternative solution.
> This sits in the vxlan evpn VRF overlay over the MPLS core so I think you
> could apply the same end to end BGP signaling concepts for customers as a
> value added service.
>
>
>
> Zzh> The highlighted red text in your paragraph is the key (and mentioned
> in the first paragraph you quoted 😊). The before/after sentences are
> orthogonal (whatever service is fine) 😊
>
>
>
>  Gyan> Understood.  This draft is an attempt to eliminate the c-tree and
> p-tree created using Next Gen MVPN trees using  PIM Rosen, mLDP, P2MP TE
> and use BGP based trees using the similar “core tree” procedures.
>
> Zzh2> This draft is only about establishing multicast trees/tunnels using
> BGP signaling. The resulting trees/tunnels can be used for whatever
> purposes.
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike?entry=gmail&source=g__;Kys!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83pxKc0T$>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI89SlT2YC$>
>
>
>

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 8 Jan 2020 18:48:48 +0000

Hi Gyan,

Please see zzh3> below. I trimmed some text.

Sent: Wednesday, January 8, 2020 2:50 AM

Hi Jeffery

Pleas see in line Gyan>

Gyan> I actually read RFC 7938 when I was redesigning a data center architecture for stability using a L3 smaller fault domain design.  This BGP signaling of trees feature has to be used with eBGP and not iBGP as that requires IGP which would now be in the RIB for RPF path so would not work thus the "no IGP" requirement as per RFC 7938.  If you had directly connected iBGP peers and not loop-loop so that you don't need an IGP, could the BGP signaled tree feature still work. In theory your spine & leaf could all be directly connected iBGP peers and all now sit in one AS and not have an IGP.  This would eliminate the need to have ASNs deployed.

Zzh3> This draft does work for both eBGP and iBGP:

   How the BGP peer sessions are provisioned, whether EBGP or IBGP,
   whether statically, automatically (e.g., based on IGP neighbor
   discovery), or programmably via an external controller, is outside
   the scope of this document.

   In case of IBGP, it could be that every router peering with Route
   Reflectors, or hop by hop IBGP sessions could be used to exchange
   C-MCAST NLRIs for joins.  In the latter case, unless desired
   otherwise for reasons outside of the scope of this document, the hop
   by hop IBGP sessions SHOULD only be used to exchange C-MCAST NLRIs.

Zzh3> RFC 7938 uses eBGP which does not require IGP, so the following text is perfect (after removing P2MP tunnel wording):

   This section provides some motivation for BGP signaling for native
   and labeld multicast.  One target deployment would be a Data Center
   that requires multicast but uses BGP as its only routing protocol
   [RFC7938<https://tools.ietf.org/html/rfc7938>].  In such a deployment, it would be desirable to support
   multicast by extending the deployed routing protocol, without
   requiring the deployment of tree building protocols such as PIM,
   mLDP, RSVP-TE P2MP, and without requiring an IGP.

Zzh3> Then the following talks about other scenarios beyond DC:

   Additionally, compared to PIM, BGP based signaling has several
   advantage as described in the following section, and may be desired
   in non-DC deployment scenarios as well.

Zzh3> I will change “compared to PIM” to “compared to PIM/mLDP”.

Gyan> So with this feature the last hop router signals join similar to mLDP inband via BGP and the join is sent via BGP signalled tree.

Zzh3> It’s the PIM joins from LHRs or mLDP label mappings from leaves replaced with BGP messages, not that “the join is sent via BGP signalled tree”.

 Gyan>  With the BGP trees using the same MVPN mLDP procedures is their a concept of PMSI-I inclusive trees c-tree p-tree so a single tree  P2MP or MP2MP can be shared by all groups or is it 1-1 mapping group to tree.

Zzh3> MVPN/EVPN is for overlay – multiple C-flows can be transported over a single I/S-PMSI which are instantiated by underlay tunnels. This draft is about establish trees/tunnels, which can instantiate MVPN/EVPN I/S-PMSI (among other things).

Gyan>  Is their any way to minimize per GDA state with BGP trees.

Zzh3> What does GDA mean? Group Destination Address?
Zzh3> Anyway, so far the only efficient replication solution w/o incurring per-tree/tunnel state is BIER. BGP-signaled multicast does still have per-tree/tunnel state just like with PIM/mLDP. The only difference is how the state is signaled.

 Gyan> For the BGP trees is it possible use the same MVPN BGP A-D and c-tree p-tree Type 6 & 7 routes BGP multicast c-signalling.

Zzh3> This draft uses a different address family and new route types similar to MVPN type-3/4 routes instead of type-6/7 routes:

   The joins are carried in BGP Updates with MCAST-TREE SAFI and S-PMSI/
   Leaf A-D routes defined in this document.  The updates are targeted
   at the upstream neighbor by use of Route Targets.  [Note - earlier
   version of this draft uses C-multicast route to send joins.  We're
   now switching to S-PMSI/Leaf routes for three reasons. a) when the
   routes go through RRs, we have to distinguish different routes based
   on upstream router and downstream router.  This leads to Leaf routes.
   b) for labeled bidirectional trees, we need to signal "upstream fec".
   S-PMSI suits this very well. c) we may want to allow the option of
   setting up trees from the roots instead of from the leaves.  S-PMSI
   suits that very well.]

   Gyan> Doing so could you leverage the PMSI-I inclusive tree MVPN feature so you don't have per GDA state

Zzh3> As explained earlier, I-PMSI is irrelevant.

    Gyan> Source discovery is only necessary with ASM not SSM. With SSM the receiver is "source" aware so does not require any discovery mechanism.
So with SSM which requires IGMPv3 enabled on the receiver last hop router subnets and on the source first hop router subnet for the both to be "source aware" ; for the receiver now to send the (S,G) join for the channel since it is now source aware. How the receiver gets that source awareness is from the server URI that the user connects to which has the S,G information ; server has to be also  source aware and has S,G channel available that can be joined. With IGMPv3 the packet  accommodate the Source information in the S,G join sent along the RPF path to the source. You mention that SSM deployment has been limited but in fact the opposite and reason why ASM is being officially deprecated by the IETF for inter domain multicast routing. IPv6 does not even have MSDP support since with ASM MSDP source discovery and propagation is not necessary since no RPs exist all disparate ASM multicast domains can now be collapsed into a single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6 nixed the idea of integrating MSDP into the architecture. Thus IPv6 only supports SSM for inter-domain multicast routing. I would keep the comment about ASM complexity which is true but remove mention of SSM.  I would not mention any gains with less state as you would still have to maintain IGMP join state with BGP with 1-1 mappings of GDA to tree so the tree state is not being eliminated.

Zzh3> To do SSM you need to know sources ahead of time.
Zzh3> In a true ASM scenario, there are multiple sources sending to the same group and receivers don’t necessarily know which sources will be sending. Even though for some applications the receivers can get that source information from some servers/URIs (which is what I refer to as “application based source discovery”), there are still many situations where the receivers just want to do (*,g) IGMP join and leave the source discover to the network.
Zzh3> As for deprecating inter-domain ASM, please note the following:

   This document does not make any statement on the use of ASM within a
   single domain or organisation, and therefore does not preclude its
   use.  Indeed, there are application contexts for which ASM is
   currently still widely considered well-suited within a single domain.

Zzh3> More importantly, to use SSM you need to know sources first – either the receivers somehow learns/knows the sources or the network will figure it out. This draft provides a way for the LHRs to figure out where the sources are and then apply SSM procedures.
Zzh> Notice that we’re not saying SSM is bad. Rather, SSM is what we want to do, but the draft is about BGP-SSM (a step up from PIM-SSM) with BGP-based source discovery.

Zzh3> To clarify, the above text is not implying to move away from SSM. Rather, it is to explain why we introduce network-based source discovery via BGP in this draft so that SSM can be used w/o requiring application-based source discovery.

Zzh3> Thanks!
Zzh3> Jeffrey

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 8 Jan 2020 14:15:40 -0800

On Wed, 8 Jan 2020, Gyan Mishra wrote:

<trimmed>

|     Gyan> Source discovery is only necessary with ASM not SSM. With SSM the receiver is "source" aware so does not require any discovery mechanism.  
| So with SSM which requires IGMPv3 enabled on the receiver last hop router subnets and on the source first hop router subnet for the both to be "source aware" ; for the receiver now to
| send the (S,G) join for the channel since it is now source aware. How the receiver gets that source awareness is from the server URI that the user connects to which has the S,G
| information ; server has to be also  source aware and has S,G channel available that can be joined. With IGMPv3 the packet  accommodate the Source information in the S,G join sent
| along the RPF path to the source. You mention that SSM deployment has been limited but in fact the opposite and reason why ASM is being officially deprecated by the IETF for inter
| domain multicast routing. IPv6 does not even have MSDP support since with ASM MSDP source discovery and propagation is not necessary since no RPs exist all disparate ASM multicast
| domains can now be collapsed into a single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6 nixed the idea of integrating MSDP into the architecture. Thus IPv6 only
| supports SSM for inter-domain multicast routing. I would keep the comment about ASM complexity which is true but remove mention of SSM.  I would not mention any gains with less state

Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason 
there is no need for MSDP in IPv6.

No one would disagree that SSM is simpler and the ideal way to go, hence 
draft-ietf-mboned-deprecate-interdomain-asm recommends SSM-only for 
interdomain deployments.  Unfortunately, for various (and sometimes 
somewhat valid) reasons, ASM lives on, at least in intradomain 
deployments.  Hence, BGP would still need to cover ASM scenarios, at 
least for these intradomain deployments that still rely on ASM to work.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Jan 2020 11:31:44 -0500

In-line comment

On Wed, Jan 8, 2020 at 5:15 PM Leonard Giuliano <[email-masked]> wrote:

> |     Gyan> Source discovery is only necessary with ASM not SSM. With SSM
> the receiver is "source" aware so does not require any discovery
> mechanism.
> | So with SSM which requires IGMPv3 enabled on the receiver last hop
> router subnets and on the source first hop router subnet for the both to be
> "source aware" ; for the receiver now to
> | send the (S,G) join for the channel since it is now source aware. How
> the receiver gets that source awareness is from the server URI that the
> user connects to which has the S,G
> | information ; server has to be also  source aware and has S,G channel
> Source information in the S,G join sent
> | along the RPF path to the source. You mention that SSM deployment has
> been limited but in fact the opposite and reason why ASM is being
> officially deprecated by the IETF for inter
> | domain multicast routing. IPv6 does not even have MSDP support since
> with ASM MSDP source discovery and propagation is not necessary since no
> RPs exist all disparate ASM multicast
> | domains can now be collapsed into a single SSM domain. ASM MSDP/Anycast
> has its complexities which is why IPv6 nixed the idea of integrating MSDP
> into the architecture. Thus IPv6 only
> | supports SSM for inter-domain multicast routing. I would keep the
> comment about ASM complexity which is true but remove mention of SSM.  I
> would not mention any gains with less state
>

  Gyan> With embedded RP how is the “source” SA propagated as is done by
MSDP with IPv4 accomplished with IPv6.  The only alternative and is a way
that SSM for both IPv4 and IPv6 can provide network discovery that I know
of and not have to rely on app based discovery ; is via BGP multicast NLRI
AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information.
This is also used when migration from ASM to SSM and want to maintain inter
domain boundaries you can use SAFI 2 for multicast NLRI source propagation.

> least for these intradomain deployments that still rely on ASM to work.

  Gyan> Agreed ASM must be supported for intra domain

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 9 Jan 2020 09:05:56 -0800

On Thu, 9 Jan 2020, Gyan Mishra wrote:

<trimmed>

| 
|       Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason
|       there is no need for MSDP in IPv6.
| 
| 
|   Gyan> With embedded RP how is the “source” SA propagated as is done by MSDP with IPv4 accomplished with IPv6.  The only alternative and is a way that SSM for both IPv4 and IPv6 can
| provide network discovery that I know of and not have to rely on app based discovery ; is via BGP multicast NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information. 
| This is also used when migration from ASM to SSM and want to maintain inter domain boundaries you can use SAFI 2 for multicast NLRI source propagation.

With Embedded RP, the address of the RP is "embedded" in the group 
address, so just by looking at the group address, routers can derive the 
RP address and know where to send their (*,g) joins.  Hence there is no 
need for RPs to "talk" to one another as they do in IPv4 with MSDP.  See 
RFC 3956 for more details.

| 
| 
|       No one would disagree that SSM is simpler and the ideal way to go, hence
|       draft-ietf-mboned-deprecate-interdomain-asm recommends SSM-only for
|       interdomain deployments.  Unfortunately, for various (and sometimes
|       somewhat valid) reasons, ASM lives on, at least in intradomain
|       deployments.  Hence, BGP would still need to cover ASM scenarios, at
|       least for these intradomain deployments that still rely on ASM to work.
| 
|    
|   Gyan> Agreed ASM must be supported for intra domain 

Then I suspect we are all in violent agreement.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 9 Jan 2020 17:41:37 +0000

Gyan,

What embedded RP gives you is that you don't need to configure RP addresses. Once the RP is known for a group (however it is done - static config in case of IPv4/IPv6, dynamic learning via BSR/Auto-RP in case of v4, or embedded RP in case of IPv6), the rest is all the same: source sends register towards the RP and LHRs sends (*,g) join towards the RP. In case a set of RPs are used for a single group, the RPs learn the sources from each other either via MSDP (IPv4 only) or via PIM registers sent among themselves.

Once the traffic arrives at the LHR routers they learn the sources and can send (s,g) joins. When we say network-based source discovery we refer to the learning of sources by the LHRs (so that they can send (s,g) joins).

> via BGP multicast NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information

That is not for source learning. It is for learning of the non-congruent routes to the sources. In many cases you only need to originate a few routes (in extreme cases a default route is enough), and it has no group information.

Jeffrey

-----Original Message-----
From: Lenny Giuliano <[email-masked]> 
Sent: Thursday, January 9, 2020 12:06 PM
To: Gyan Mishra <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

<trimmed>

| 
|       Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason
|       there is no need for MSDP in IPv6.
| 
| 
|   Gyan> With embedded RP how is the “source” SA propagated as is done 
| by MSDP with IPv4 accomplished with IPv6.  The only alternative and is a way that SSM for both IPv4 and IPv6 can provide network discovery that I know of and not have to rely on app based discovery ; is via BGP multicast NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information.
| This is also used when migration from ASM to SSM and want to maintain inter domain boundaries you can use SAFI 2 for multicast NLRI source propagation.

With Embedded RP, the address of the RP is "embedded" in the group address, so just by looking at the group address, routers can derive the RP address and know where to send their (*,g) joins.  Hence there is no need for RPs to "talk" to one another as they do in IPv4 with MSDP.  See RFC 3956 for more details.

| 
|

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Jan 2020 13:24:46 -0500

On Thu, Jan 9, 2020 at 12:41 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Gyan,
>
> What embedded RP gives you is that you don't need to configure RP
> addresses. Once the RP is known for a group (however it is done - static
> config in case of IPv4/IPv6, dynamic learning via BSR/Auto-RP in case of
> v4, or embedded RP in case of IPv6), the rest is all the same: source sends
> register towards the RP and LHRs sends (*,g) join towards the RP. In case a
> set of RPs are used for a single group, the RPs learn the sources from each
> other either via MSDP (IPv4 only) or via PIM registers sent among
> themselves.
>
> Once the traffic arrives at the LHR routers they learn the sources and can
> send (s,g) joins. When we say network-based source discovery we refer to
> the learning of sources by the LHRs (so that they can send (s,g) joins).
>

    Gyan> I understand the IPv4 scenario.  I was referring to the IPv6
scenario that the embedded RP provides the RP address to build the group RP
map which is fine but you still need a LHR mechanism to discover the source
which does not exist with SSM.  There are reasons for that and I am
drafting reply to the other thread I will explain.

> That is not for source learning. It is for learning of the non-congruent
> routes to the sources. In many cases you only need to originate a few
> routes (in extreme cases a default route is enough), and it has no group
> information.
>

  Gyan> I understand that non congruent routes is one use case for
multicast NLRI ; If the LHR was BGP connected and its RPF path to the
source was now  via BGP multicast NLRI you could use this method to
discover all SSM sources via the network.   Imagine if you decided you
wanted to augment you SSM infrastructure with a multicast NLRI for source
propagation you could do this on your source FHR and receiver LHR and with
all intermediate hops including the core now providing congruent reach
ability to the SSM multicast sources ; you now have solved the SSM gap
mentioned related to LHR network based source discovery.  I don’t think
their is a draft on this but I think it’s a worthwhile I-D.

> Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> | by MSDP with IPv4 accomplished with IPv6.  The only alternative and is a
> way that SSM for both IPv4 and IPv6 can provide network discovery that I
> know of and not have to rely on app based discovery ; is via BGP multicast
> NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information.
> | This is also used when migration from ASM to SSM and want to maintain
> inter domain boundaries you can use SAFI 2 for multicast NLRI source
> propagation.
>
> address, so just by looking at the group address, routers can derive the RP
> address and know where to send their (*,g) joins.  Hence there is no need
> for RPs to "talk" to one another as they do in IPv4 with MSDP.  See RFC
> 3956 for more details.
>
> |
> |
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 9 Jan 2020 18:29:53 +0000

Please see zzh> below.

From: Gyan Mishra <[email-masked]>
Sent: Thursday, January 9, 2020 1:25 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Lenny Giuliano <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

On Thu, Jan 9, 2020 at 12:41 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

Gyan> I understand the IPv4 scenario.  I was referring to the IPv6 scenario that the embedded RP provides the RP address to build the group RP map which is fine but you still need a LHR mechanism to discover the source which does not exist with SSM.  There are reasons for that and I am drafting reply to the other thread I will explain.

Zzh> That’s why the draft has relevant text: 1) SSM needs source discovery and will not totally succeed unless the source discovery problem is solved 2) this draft provides a BGP based source discovery mechanism (in addition to BGP based join/prune).

  Gyan> I understand that non congruent routes is one use case for multicast NLRI ; If the LHR was BGP connected and its RPF path to the source was now  via BGP multicast NLRI you could use this method to discover all SSM sources via the network.   Imagine if you decided you wanted to augment you SSM infrastructure with a multicast NLRI for source propagation you could do this on your source FHR and receiver LHR and with all intermediate hops including the core now providing congruent reach ability to the SSM multicast sources ; you now have solved the SSM gap mentioned related to LHR network based source discovery.  I don’t think their is a draft on this but I think it’s a worthwhile I-D.

Zzh> Source discovery is about (s,g), and SAFI 2 does not have group information.
Zzh> Jeffrey

Jeffrey

-----Original Message-----
From: Lenny Giuliano <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 9, 2020 12:06 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <[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 and IPR poll for draft-zzhang-bess-bgp-multicast-03

<trimmed>

|

|
|

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Jan 2020 14:58:22 -0500

On Thu, Jan 9, 2020 at 1:30 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Thursday, January 9, 2020 1:25 PM
> *Cc:* Lenny Giuliano <[email-masked]>; [email-masked];
> On Thu, Jan 9, 2020 at 12:41 PM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> Gyan,
>
> Zzh> That’s why the draft has relevant text: 1) SSM needs source discovery
> and will not totally succeed unless the source discovery problem is solved
> 2) this draft provides a BGP based source discovery mechanism (in addition
> to BGP based join/prune).
>
>
>
>
> Gyan> Understood.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Jan 2020 19:22:11 -0500

In-line comments

On Wed, Jan 8, 2020 at 1:48 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Wednesday, January 8, 2020 2:50 AM
> an IGP.  This would eliminate the need to have ASNs deployed.
>
>
>
   Gyan> I am on the same page with you on the draft as it has a lot of
merit.  I like the concept of leveraging BGP for multicast and using the
proven MVPN procedures to instantiate PMSI trees now with hard stare end to
end.

Few comments below:

The main objectives of this draft which should be incorporated in the
Introduction is to provide an option for both service providers and
enterprises that do not want to maintain soft state of multicast trees ;
native PIM ASM or SSM based trees ; or MPLS based instantiated S-PMSI trees
; to use BGP multicast hard state to send joins/prune using proven service
provider MVPN procedures.  Provide a means of network based source
discovery for both ASM and SSM.

Would Default MDT UI/MI PMSI instantiated tree type 1 and 2 be considered
hard state since the default MDT tree is always UP.  They could be an
example to give to describe what is meant by hard state.

What is confusing is the mention in the introduction of the target
deployment being for data centers BGP-only RFC 7938 deployments.  Since BGP
multicast procedure can use both eBGP or IBGP with or w/o RR ; I would put
the target deployments or use case in a separate section.  I think the
reason why 7938 is mentioned is that in cases where BGP is solely used and
protocol elimination is the goal, similar to P router “BGP free core” ;
this allows for the elimination of PIM as well.  Does add confusion as part
of intro since it makes the reader think that this is a eBGP only option
for this feature  which it is not.

Some operators don’t have an issue with the IP or labeled soft state with
tree based models

Since the objective of this draft is to provide an alternative solution for
operators  and not that this would provide a means to that end to eliminate
tree based protocols such as pim or mldp but as an “option” if so desired.
  I would stare as such.

I don’t think tree based protocols are going away any time soon but I think
it’s good to clarify that the direction from a standards perspective is not
to eliminate but provide the optional flexibility for operators.

I think it’s a good idea to define what is meant by hard state and soft
state.

There maybe reason that operators may desire to keep the soft state if they
don’t have much native or labeled state.  Or for telemetry or tracking
purposes desire to maintain tree state to see how many trees are active
within the network.  For scalability in cases of where soft state
management is an issue now they have an option.

ASM was built with LHR network based source discovery with MSDP and to that
end it did add complexity but did allow a lot of flexibility that the MRIB
contained all available groups so any receiver could join and group and any
source could start streaming if they so desired.  Controls were built into
ASM for that reason to limit what groups could be serviced  by an RP via
ACL and what sources could stream with PIM accept register.  Controls were
also put in place with MSDP SA propagation with SA filtering.  So the added
flexibility of network based discovery was nice with ASM however with a
major trade off of complexity as well as now added controls as to what
valid sources can steam and what receivers can join what what steam.

SSM was designed w/o network based discovery to eliminate the complexity of
all the knobs to provide those controls that were built into ASM for the
gain of simplicity : thus application based network discovery.  With SSM
now all the controls are with the application /  server layer and removed
from the network.  With application based source discovery at the
application layer a channel list can now be provided which was done
previously by legacy multicast apps such as SDR which detected the active
groups on the network.

I think it maybe worthwhile mentioning reasons why SSM was built without
network based discovery since now this draft will be adding the capability
to SSM for network based source discovery.

Regarding the multicast NLRI I was thinking how that would work and reason
why the group is not needed is that the group is known with ASM model and
if you have ASM and SSM overlay the  group is known by the app layer and so
the network just needs the source to be learned for the LHR S,G join. Maybe
worth mentioning in the draft.

In the introduction I would remove that soft state and tree building
protocols as a reason why data centers avoid enabling multicast on the
network.  There maybe some isolated corner cases however predominantly PIM
soft state ASM or SSM has never been an issue.  To that end most data
centers server deployments rely on multicast for clustering and data
replication.  Also server based applications that can utilize multicast
save on high bandwidth server to server east to west intra data center
flows.  I do think BGP multicast would be an improvement and would add
stability for data centers requiring multicast.

In the draft it mentions that earlier versions of this draft user
C-Multicast for signaling which was change to S-PMSI leaf Type 4 routes so
we can set up the tree from FEC root instead of leaves.  This is similar to
P2MP TE P-Tunnel where the root advertises BGP route type 3 with “leaf info
required” bit set ; when the receiver PE gets the route it responds with
type 4 leaf-ad.  Is that correct?

For labeled use case can this be used for all P-tunnel types MP2MP P2MP
mLDP, P2MP TE.  Would PIM Rosen GRE still be valid P tunnel supported.
Maybe good to mention all the P tunnels supported for labeled BGP multicast.

As far as the MVPN procedures instantiation of S-PMSI trees is that being
completed reused from RFC 6513 6514  - all the same route types supporting
ASM and SSM types 3-7.  Only type 1 and 2 for default MDT instantiation of
I-PMSI trees is not supported.

Correct?

Kind regards,

Gyan

Zzh3> RFC 7938 uses eBGP which does not require IGP, so the following text
> is perfect (after removing P2MP tunnel wording):
>
>
>
>    [RFC7938 <https://tools.ietf.org/html/rfc7938>].  In such a
> deployment, it would be desirable to support
>
> Gyan> So with this feature the last hop router signals join similar to
> mLDP inband via BGP and the join is sent via BGP signalled tree.
>
>
>
> Zzh3> It’s the PIM joins from LHRs or mLDP label mappings from leaves
> replaced with BGP messages, not that “the join is sent via BGP signalled
> tree”.
>
>
>
>  Gyan>  With the BGP trees using the same MVPN mLDP procedures is their a
> concept of PMSI-I inclusive trees c-tree p-tree so a single tree  P2MP or
> MP2MP can be shared by all groups or is it 1-1 mapping group to tree.
>
>
>
> Zzh3> MVPN/EVPN is for overlay – multiple C-flows can be transported over
> a single I/S-PMSI which are instantiated by underlay tunnels. This draft is
> about establish trees/tunnels, which can instantiate MVPN/EVPN I/S-PMSI
> (among other things).
>
>
>
> Zzh3> Anyway, so far the only efficient replication solution w/o incurring
> per-tree/tunnel state is BIER. BGP-signaled multicast does still have
> per-tree/tunnel state just like with PIM/mLDP. The only difference is how
> the state is signaled.
>
>
>
>  Gyan> For the BGP trees is it possible use the same MVPN BGP A-D and
> c-tree p-tree Type 6 & 7 routes BGP multicast c-signalling.
>
>
>
> Zzh3> This draft uses a different address family and new route types
> similar to MVPN type-3/4 routes instead of type-6/7 routes:
>
>
>
>     Gyan> Source discovery is only necessary with ASM not SSM. With SSM
> Zzh3> In a true ASM scenario, there are multiple sources sending to the
> same group and receivers don’t necessarily know which sources will be
> sending. Even though for some applications the receivers can get that
> source information from some servers/URIs (which is what I refer to as
> “application based source discovery”), there are still many situations
> where the receivers just want to do (*,g) IGMP join and leave the source
> discover to the network.
>
> Zzh3> More importantly, to use SSM you need to know sources first – either
> the receivers somehow learns/knows the sources or the network will figure
> it out. This draft provides a way for the LHRs to figure out where the
> sources are and then apply SSM procedures.
>
> Zzh3> To clarify, the above text is not implying to move away from SSM.
> Rather, it is to explain why we introduce network-based source discovery
> via BGP in this draft so that SSM can be used w/o requiring
> application-based source discovery.
>
>
>
> Zzh3> Thanks!
>
> Zzh3> Jeffrey
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 16 Jan 2020 10:04:15 -0500

Hi Jeffrey & Mankamana

Just following up on my comments and if you had any questions.

Kind Regards

Gyan

On Thu, Jan 9, 2020 at 7:22 PM Gyan Mishra <[email-masked]> wrote:

> Since the objective of this draft is to provide an alternative solution
> for operators  and not that this would provide a means to that end to
> eliminate tree based protocols such as pim or mldp but as an “option” if so
> desired.   I would stare as such.
>
> I don’t think tree based protocols are going away any time soon but I
> think it’s good to clarify that the direction from a standards perspective
> is not to eliminate but provide the optional flexibility for operators.
>
> There maybe reason that operators may desire to keep the soft state if
> they don’t have much native or labeled state.  Or for telemetry or tracking
> ASM was built with LHR network based source discovery with MSDP and to
> that end it did add complexity but did allow a lot of flexibility that the
> MRIB contained all available groups so any receiver could join and group
> and any source could start streaming if they so desired.  Controls were
> built into ASM for that reason to limit what groups could be serviced  by
> an RP via ACL and what sources could stream with PIM accept register.
> Controls were also put in place with MSDP SA propagation with SA
> filtering.  So the added flexibility of network based discovery was nice
> with ASM however with a major trade off of complexity as well as now added
> controls as to what valid sources can steam and what receivers can join
> what what steam.
>
> SSM was designed w/o network based discovery to eliminate the complexity
> of all the knobs to provide those controls that were built into ASM for the
>> Zzh3> Anyway, so far the only efficient replication solution w/o
>> incurring per-tree/tunnel state is BIER. BGP-signaled multicast does still
>> have per-tree/tunnel state just like with PIM/mLDP. The only difference is
>> how the state is signaled.
>>
>>
>>
>> Zzh3> More importantly, to use SSM you need to know sources first –
>> either the receivers somehow learns/knows the sources or the network will
>> figure it out. This draft provides a way for the LHRs to figure out where
>> the sources are and then apply SSM procedures.
>>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 20 Jan 2020 20:37:47 +0000

Dear WG,

I’m unaware of any IPR for this draft,

Thx,

Ice.

Sent from my iPhone

On 6 Jan 2020, at 15:15, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Regards,
Matthew and Stephane

---

From: Keyur Patel <[email-masked]>
Date: Mon, 20 Jan 2020 20:41:19 +0000

Support as a co-author. Not aware of any undisclosed IPRs related to this draft.

Regards,
Keyur

On Jan 6, 2020, at 6:43 PM, Gulko, Arkadiy (Refinitiv) <[email-masked]> wrote:

Hello,

Regards,
Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 20 Jan 2020 18:15:13 -0500

I support.

Kind regards

Gyan

On Mon, Jan 20, 2020 at 3:41 PM Keyur Patel <[email-masked]> wrote:

> *From: *"[email-masked]" <[email-masked]>
> *Date: *Monday, January 6, 2020 at 9:15 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> *Subject: *WG adoption and IPR poll for
> *Resent-From: *<[email-masked]>
> *Resent-To: *<[email-masked]>, <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, <[email-masked]>
> *Resent-Date: *Monday, January 6, 2020 at 9:14 AM
>
>
>
> Hello,
>
>
>
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zzhang-bess-bgp-multicast&data=02%7C01%7Carkadiy.gulko%40refinitiv.com%7Ca55ef10e648140186c4308d792b2cfe1%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637139168999229658&sdata=tK%2FenKHLQi8r6e%2BOao0cXXLILWDO%2Fwoh1WNxDQWKNO8%3D&reserved=0>
>
>
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: <[email-masked]>
Date: Thu, 23 Jan 2020 14:47:48 +0100

The document is adopted.

Authors please republish using -ietf-

From: [email-masked] <[email-masked]> 
Sent: lundi 6 janvier 2020 15:15
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03 

Hello,

Regards,

Matthew and Stephane

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 24 Jan 2020 18:32:32 +0000

Hi Gyan,

Please zzh4> below.

Sent: Thursday, January 9, 2020 7:22 PM

In-line comments

On Wed, Jan 8, 2020 at 1:48 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 8, 2020 2:50 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: [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 and IPR poll for draft-zzhang-bess-bgp-multicast-03

Hi Jeffery

Pleas see in line Gyan>

   Gyan> I am on the same page with you on the draft as it has a lot of merit.  I like the concept of leveraging BGP for multicast and using the proven MVPN procedures to instantiate PMSI trees now with hard stare end to end.

Few comments below:

The main objectives of this draft which should be incorporated in the Introduction is to provide an option for both service providers and enterprises that do not want to maintain soft state of multicast trees ; native PIM ASM or SSM based trees ; or MPLS based instantiated S-PMSI trees ; to use BGP multicast hard state to send joins/prune using proven service provider MVPN procedures.  Provide a means of network based source discovery for both ASM and SSM.

Zzh4> The introduction section has the following:

   1<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#section-1>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#page-3>
     1.1<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#section-1.1>.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#page-3>
      1.1.1<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#section-1.1.1>.  Native/unlabeled Multicast  . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#page-3>
       1.1.2<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#section-1.1.2>.  Labeled Multicast . . . . . . . . . . . . . . . . . .   4<https://tools.ietf.org/html/draft-zzhang-bess-bgp-multicast-02#page-4>

Zzh4> It does cover the above points.

Would Default MDT UI/MI PMSI instantiated tree type 1 and 2 be considered hard state since the default MDT tree is always UP.  They could be an example to give to describe what is meant by hard state.

Zzh4>. Hard state vs. soft state means whether the state needs to be refreshed.

What is confusing is the mention in the introduction of the target deployment being for data centers BGP-only RFC 7938 deployments.  Since BGP multicast procedure can use both eBGP or IBGP with or w/o RR ; I would put the target deployments or use case in a separate section.  I think the reason why 7938 is mentioned is that in cases where BGP is solely used and protocol elimination is the goal, similar to P router “BGP free core” ; this allows for the elimination of PIM as well.  Does add confusion as part of intro since it makes the reader think that this is a eBGP only option for this feature  which it is not.

Zzh4> The text says “ONE target deployment”. There could be more. But I will change the wording to “one deployment scenario”. The following paragraph and sub-sections expand to other motivations.

Some operators don’t have an issue with the IP or labeled soft state with tree based models

Zzh4> Right – that’s why it says “some Data Center operators have been avoiding deploying multicast in their networks”.

Since the objective of this draft is to provide an alternative solution for operators  and not that this would provide a means to that end to eliminate tree based protocols such as pim or mldp but as an “option” if so desired.   I would stare as such.

Zzh4> This document has no mentioning of segment routing (where people talk about eliminating core state) and has the following in the abstract:

   This document specifies a BGP address family and related procedures
   that allow BGP to be used for setting up multicast distribution
   trees.

I don’t think tree based protocols are going away any time soon but I think it’s good to clarify that the direction from a standards perspective is not to eliminate but provide the optional flexibility for operators.

I think it’s a good idea to define what is meant by hard state and soft state.

Zzh4> Hard state and soft state are generally well-known, and I do have the following:

   o  Periodical protocol state refreshes due to soft state nature.

There maybe reason that operators may desire to keep the soft state if they don’t have much native or labeled state.  Or for telemetry or tracking purposes desire to maintain tree state to see how many trees are active within the network.  For scalability in cases of where soft state management is an issue now they have an option.

Zzh4> If they don’t have concerns that are addressed by this solution they certainly don’t have to use this. This is just an option.

ASM was built with LHR network based source discovery with MSDP and to that end it did add complexity but did allow a lot of flexibility that the MRIB contained all available groups so any receiver could join and group and any source could start streaming if they so desired.  Controls were built into ASM for that reason to limit what groups could be serviced  by an RP via ACL and what sources could stream with PIM accept register.  Controls were also put in place with MSDP SA propagation with SA filtering.  So the added flexibility of network based discovery was nice with ASM however with a major trade off of complexity as well as now added controls as to what valid sources can steam and what receivers can join what what steam.

Zzh4> ASM does not require MSDP. The real problem of ASM is with the complexity of source discovery that involves RP, register and RPT to SPT switchover). The solution in this draft addresses the complexity.

SSM was designed w/o network based discovery to eliminate the complexity of all the knobs to provide those controls that were built into ASM for the gain of simplicity : thus application based network discovery.  With SSM now all the controls are with the application /  server layer and removed from the network.  With application based source discovery at the application layer a channel list can now be provided which was done previously by legacy multicast apps such as SDR which detected the active groups on the network.

I think it maybe worthwhile mentioning reasons why SSM was built without network based discovery since now this draft will be adding the capability to SSM for network based source discovery.

Zzh4> That is outside the scope of this document. It’s better to be focused.

Regarding the multicast NLRI I was thinking how that would work and reason why the group is not needed is that the group is known with ASM model and if you have ASM and SSM overlay the  group is known by the app layer and so the network just needs the source to be learned for the LHR S,G join. Maybe worth mentioning in the draft.

Zzh4> The NLRIs do have (*,g) or (s,g) information. The LHR does need to know which group it needs to join, and that is a given.

In the introduction I would remove that soft state and tree building protocols as a reason why data centers avoid enabling multicast on the network.  There maybe some isolated corner cases however predominantly PIM soft state ASM or SSM has never been an issue.  To that end most data centers server deployments rely on multicast for clustering and data replication.  Also server based applications that can utilize multicast save on high bandwidth server to server east to west intra data center flows.  I do think BGP multicast would be an improvement and would add stability for data centers requiring multicast.

Zzh4> It is true some DC operators don’t like multicast trees. It’s true some others don’t mind having them. It’s ok to mention that this solution could suit for whoever needs multicast yet don’t want to run PIM.

In the draft it mentions that earlier versions of this draft user C-Multicast for signaling which was change to S-PMSI leaf Type 4 routes so we can set up the tree from FEC root instead of leaves.  This is similar to P2MP TE P-Tunnel where the root advertises BGP route type 3 with “leaf info required” bit set ; when the receiver PE gets the route it responds with type 4 leaf-ad.  Is that correct?

Zzh4> S-PMSI routes are used for two purposes in this document – see 2.2.5 and 2.2.6.

For labeled use case can this be used for all P-tunnel types MP2MP P2MP mLDP, P2MP TE.  Would PIM Rosen GRE still be valid P tunnel supported.  Maybe good to mention all the P tunnels supported for labeled BGP multicast.

Zzh4> This is about establishing native/labeled multicast trees. The resulting trees can be used for MVPN (BGP-MVPN or Rosen MVPN) as P-tunnels, but in the context of this document,  you ca just forget about P tunnels.

As far as the MVPN procedures instantiation of S-PMSI trees is that being completed reused from RFC 6513 6514  - all the same route types supporting ASM and SSM types 3-7.  Only type 1 and 2 for default MDT instantiation of I-PMSI trees is not supported.

Zzh4> Other than that some NLRI types are similar to MVPN, you can ignore its relevance with MVPN.
Zzh4> Thanks!
Zzh4> Jeffrey

Correct?

Kind regards,

Gyan

   [RFC7938<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7938__;!!NEt6yMaO-gk!X9DfJ6RoZtXubIffaIRRYd0TgIz3lgYayTfkKv2a7LIImWQqa9eDPnSJyZ1k8qhB$>].  In such a deployment, it would be desirable to support

Zzh3> Thanks!
Zzh3> Jeffrey