All things related to multicast

[Dan Pritts <>]

I should add that I don't intend to argue whether R&E networks should continue to support multicast; just to specifically address Lenny's question of why v6 has gone mainstream while multicast hasn't. 

danno

August 18, 2016 at 9:57 AM

I think the fundamental reasons that IPv6 turned the corner are that

a) the technology seemed to fundamentally work, based on limited deployments.

b) big players saw an actual business need (or, at least, business case justification), and pushed to make it happen. 

and maybe
c) US Government made it a mandate, which helped with (a).  I suppose this is just a special case of (b). 

Multicast hasn't yet met (a) (it can be made to work, of course, but it's not easy and is fragile), and definitely hasn't met (b) or (c). 

Haven't we heard that comcast moved to ipv6 at least partly because RFC1918 space wasn't big enough for managing their huge network?

Many small players, and some big players (amazon) haven't seen the business NEED and have been slow to deploy. 

August 17, 2016 at 3:13 PM

FWIW, at the last MBONED mtg, a draft was presented to explicitly
recommend alot of what is suggested below. Specifically, that SSM should
be the only service model for interdomain deployments. Would love
comments and feedback from folks here on this draft (send to
):

https://www.ietf.org/id/draft-acg-mboned-multicast-models-00.txt

Personally, I would go a few steps further and would love to see
network-based source discovery completely deprecated (inter- and
intradomain). We don't expect routers to track all the unicast sources on
the Internet- we let Google do that- so why do it for mcast? The
application layer is where source discovery belongs- it is where you can
get the most scale, robustness, flexibility, creativity and room for
innovation. Multi-source apps like beacon would still work if you let the
app layer learn of the sources, and you can radically simplify the network
by just doing SSM (no shared trees, no RPs, no MSDP, no register
encap/decap, no tree switchover, no data-driven state creation, etc).

The history of networking suggests a tendency towards connecting more
things over time. Perhaps multicast will be the exception- thus far, it
has mostly seemed to go that way. But I would point out that it wasn't
too long ago that IPv6 faced a similiar ennui and most evidence at the
time pointed to IPv6 never taking off. However, IPv6 seems to have turned
a corner in recent years and appears to be making real strides in
deployment. For those out there who are still interested in seeing
Internet Mcast become a reality, might be worth looking at what got IPv6
over the hump. Maybe it was the fear of impending doom from those ominous
Address Exhaustion countdowns, maybe it was World IPv6 Day, maybe it was
just a few large content entities throwing their weight behind v6,
whatever it was (and I'm curious myself), perhaps there are some lessons
to be learned and applied in the case of Internet Mcast. After all, every
argument (pro and con) one could make about IPv6 is equally applicable, if
not moreso, to it's technological cousin, Internet Mcast.

-Lenny

On Wed, 10 Aug 2016, Alan Whinery wrote:

|
| And also, ultimately, this is a matter for NTAC to discuss.
|
| (exlusions of other recipients in previous unintentional. )
|
|
| On 8/10/2016 9:27 AM, Alan Whinery wrote:
| > Is there a current chairperson-of-record for the Multicast Group?
| >
| > Shall we put a Weekend Update: Point/Counterpoint on the Tech Exchange
| > NTAC agenda?
| >
| > I honestly don't know if there is a counterpoint. We have reached a
| > soft consensus "multicast is dead" in the IPv6 Working Group multiple
| > times.
| >
| > I just think it's worth a formal discussion, not because I disagree
| > with John or David, but because sometimes bathwater needs to be
| > checked for babies.
| >
| > On 8/10/2016 9:13 AM, David Farmer wrote:
| >> We are at the beginning of a major equipment replacement/upgrade
| >> cycle for campus. As part of that I have been thinking about what
| >> the appropriate support of interdomain multicast should be. While I
| >> haven't come to a final conclusions yet, here is my current thinking.
| >>
| >> 1. Primary goal of deprecating MSDP, and therefore interdomain IPv4
| >> ASM multicast. MSDP is fragile and honestly it's a hack.
| >> 2. Keep IPv4 ASM multicast locally, on campus, maybe between campuses
| >> in the University system, through use of a common RP, no MSDP.
| >> 3. Keep IPv4 SSM interdomain multicast
| >> 4. Focus efforts on supporting IPv6 interdomain multicast, SSM and
| >> embedded-RP
| >> 5. Keep IPv4 and IPv6 BGP multicast NLRIs
| >> 6. Primarily PIM sparse mode, maybe using PIM-bidir for better scaling
| >>
| >> What do others think?
| >>
| >> Thanks
| >>
| >> On Wed, Aug 10, 2016 at 11:00 AM, Michael H Lambert <
| >> > wrote:
| >>
| >> The following was sent by John Kristoff (cc'ed) to the Multicast
| >> WG mailing list (yes, the list still exists):
| >>
| >> > Begin forwarded message:
| >> >
| >> > From: John Kristoff < >
| >> > Subject: AS 20130 has turned off interdomain IP multicast
| >> > Date: 9 August 2016 at 18:09:37 EDT
| >> > To: "
| >> " <
| >> >
| >> > Reply-To:
| >>
| >> >
| >> >> show msdp
| >> > MSDP instance is not running
| >> >
| >> >> show route table ?
| >> > Possible completions:
| >> > <table> Name of routing table
| >> > inet.0
| >> > inet.1
| >> > inet6.0
| >> > inet6.1
| >> >>
| >> >
| >> > It was a fun ride for a time, but it now joins the dustbin of dead
| >> > technologies in the back of my brain. Token Ring, ISDN,
| >> NetWare, ...,
| >> > welcome you to the club, may you rest in peace.
| >> >
| >> > John
| >>
| >> Does anyone else think it might be time to reflect on the future
| >> of interdomain multicast in the backbone?
| >>
| >> Michael
| >>
| >>
| >>
| >>
| >> --
| >> ===============================================
| >> 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
| >> ===============================================
| >
| >
|
|

August 10, 2016 at 3:30 PM

And also, ultimately, this is a matter for NTAC to discuss.

(exlusions of other recipients in previous unintentional. )


On 8/10/2016 9:27 AM, Alan Whinery wrote:

August 10, 2016 at 3:13 PM

We are at the beginning of a major equipment replacement/upgrade cycle for campus.  As part of that I have been thinking about what the appropriate support of interdomain multicast should be.  While I haven't come to a final conclusions yet, here is my current thinking.

1. Primary goal of deprecating MSDP, and therefore interdomain IPv4 ASM multicast. MSDP is fragile and honestly it's a hack.

2. Keep IPv4 ASM multicast locally, on campus, maybe between campuses in the University system, through use of a common RP, no MSDP.  

3. Keep IPv4 SSM interdomain multicast 

4. Focus efforts on supporting IPv6 interdomain multicast, SSM and embedded-RP

5. Keep IPv4 and IPv6 BGP multicast NLRIs

6. Primarily PIM sparse mode, maybe using PIM-bidir for better scaling

What do others think?

Thanks

--

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

August 9, 2016 at 6:09 PM

show msdp           

MSDP instance is not running

show route table ?

Possible completions:
  <table>              Name of routing table
  inet.0               
  inet.1               
  inet6.0              
  inet6.1

It was a fun ride for a time, but it now joins the dustbin of dead
technologies in the back of my brain.  Token Ring, ISDN, NetWare, ...,
welcome you to the club, may you rest in peace.

John

--
Dan Pritts

ICPSR Computing & Network Services

University of Michigan