All things related to multicast

[David Farmer <>]

Based on Lenny's feedback let me clarify and modify the options a bit;

1. Native SSM within our community (to regionals and campuses), with native SSM support on the Internet2 backbone and peering with International R&E, and maybe larger Internet as well.

2A. AMT SSM within our community (to regionals and campuses), with no support for native SSM multicast on the Internet2 backbone, but coordination of the effort. (could technically be equivalent to #4 anyway)

2B. AMT SSM within our community (to regionals and campuses), with native SSM support on the Internet2 backbone and peering with International R&E, and maybe larger Internet as well.

3. Combination of native SSM & AMT SSM within our community (to regionals and campuses), with native SSM support on the Internet2 backbone and peering with International R&E, and maybe larger Internet as well.

4. Completely Deprecate Interdomain Multicast Coordination within our community (could cause the collapse of any Multicast efforts globally)

Thanks

On Fri, Aug 28, 2020 at 10:19 AM Leonard Giuliano <> wrote:

To answer the original question about the need for multicast SAFI, yes,
SSM uses it just as ASM does.  Specifically, it's used to support
incongruent topologies between unicast and multicast.  In the case of ASM,
MBGP populates the RPF table used by MSDP peer-rpf and PIM for RPF towards
source and RP; in SSM, it's used by PIM for RPF towards source.  So if you
needed MBGP for ASM, you most likely still need it for SSM.

RFC8815 is about 20 years overdue, but better late than never.  An
SSM-only deployment eliminates ~95% the complexity, risk and headaches of
mcast.  PIM-SSM becomes roughly as simple as LDP, which is a protocol no
one would complain is too complex.  Most of the complaints about mcast go
away in an SSM-only world.

Right now, #1 is being used today- please take a look at:
https://multicastmenu.herokuapp.com/

AMT requires native mcast ~somewhere~.  Right now that somwehere is
primarily I2.  Eliminate that, and AMT provides little value, so #2 and #3
would effectively be the same as #4.

Lower usage seems an odd reason to eliminate a technology from an R&E
network with a mission of incubating technologies for use on the broader
Internet.  Would be like deprecating IPv6 ten years ago (or, arguably,
now) bc it wasn't being used enough.  Also, timing is odd as the biggest
reasons for lower usage (complexity and "all or nothing" problem) have
effectively been eliminated with RFC8815 + AMT.  Finally, recent events
over the last few months have demonstrated the need for networking
solutions that enable people to gather virtually (distance learning,
worship services, movie watch parties, drinks with friends, WG meetings,
etc).  Live streaming, which was the fastest growing segment of online
video the past few years, has increased significantly since the lockdown. 
The need for networking technologies that deliver live streaming more
scalably is only increasing.

-Lenny

On Fri, 28 Aug 2020, David Farmer wrote:

|
| [External Email. Be cautious of content]
|
| I'd like to suggest we create an NTAC work item on multicast, that being what is our current community recommendations for interdomain multicast.
| I see 4 possibilities;
|
| 1. Native SSM, with support on the Internet2 backbone as well.
| 2. AMT SSM, with no support for native SSM multicast on the Internet2 backbone, but coordination of the effort.
| 3. Some Combination of 1 & 2, we will need to define what this means for the Internet2 backbone.
| 4. Completely Deprecate Interdomain Multicast Coordination within our community
|
| Note #4 still allows individual entities to do AMT if they wish, there is just no community coordination of the effort or explicit support by the Interent2 or the backbone.
|
| Honestly, I see us heading toward #4, and if that is where we want to go as a community, I'm ok with that. However, I would rather we decide that intentionally, than get there by attrition and apathy.
|
| What do others think?
|
| Thanks
|  
|
| On Fri, Aug 28, 2020 at 8:44 AM Michael H Lambert <> wrote:
|       A point which has never been completely clear to me (since I admit to
|       having thought about multicast as little as possible the past decade) is
|       whether the multicast SAFI is still needed when doing SSM.  RFC 8815
|       doesn't mention this, but RFC 8313 (BCP for SSM) suggests it may still
|       be needed.  I had thought it was just used for ASM RPF checking, but I
|       could be mistaken.
|
|       Michael
|
|       Bill Owens wrote on 2020-08-28 06:15:
|       > That's because you're doing a (*,G) join to the dirges stream.
|       >
|       > (In another age I would have set up a loop of dirges on a utility machine somewhere, but I've already ripped most of the multicast config out of our network. All inter-domain multicast is deprecated.)
|       >
|       > Bill.
|
|
|
| --
| ===============================================
| David Farmer              
| Networking & Telecommunication Services
| Office of Information Technology
| University of Minnesota  
| 2218 University Ave SE        Phone: 612-626-0815
| Minneapolis, MN 55414-3029   Cell: 612-812-9952
| ===============================================
|
|

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================