All things related to multicast

[Leonard Giuliano <>]

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               Email:
| 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
| ===============================================
| 
|