All things related to multicast

[Bruce Curtis <>]

> On Aug 10, 2016, at 4:13 PM, David Farmer 
> <>
>  wrote:
> 
> 
> 
> On Wed, Aug 10, 2016 at 3:59 PM, Zenon Mousmoulas 
> <>
>  wrote:
> 10 Αυγ 2016, 17:50, ο/η "John Kristoff" 
> <>
>  έγραψε:
> 
>> On Wed, 10 Aug 2016 13:36:01 +0000
>> Michael Hare 
>> <>
>>  wrote:
>> 
>>> Out of curiosity, did you consider dumping MSDP but keeping SSM?
>> 
>> No, not even for a second.
> 
> What's your problem with MSDP? I mean, yes, I know the problems of MSDP, 
> but in our experience there are more often issues with some switch silently 
> dropping multicast packets due to some esoteric bug/limitation, rather than 
> with MSDP. At the current, limited scale of inter-domain multicast, what 
> operational issues have you seen with MSDP in the last few years?
> 
> Btw, maybe you had heard of the Eumetcast project coordinated by Geant; it 
> had to do with distributing meteo data over ipv4 SSM (rather than, say, 
> satellite) but also an ASM-dependent beacon was established in that context:
> 
> http://prod-eumetsat02.geant.net/eumet?what=asm
> In complicated interdomain topologies it can be troublesome getting the 
> MSDP and the BGP routing topology to be congruent, especially when there 
> are multiple interdomain paths to consider.  It's fragile and needs more 
> care and feeding than it's worth.

  The folklore is that MSDP was a quick (relatively) and dirty temporary 
kludge until something better and more scalable would become available.

  Perhaps the initial “something better” was BGMP.

"But MSDP is a temporary hack to hold the Any Source Multicast backbone 
together long enough for Border Gateway Multicast Protocol (BGMP) to be 
developed, debugged, and deployed. Maybe--some network developers think that 
BGMP is too complex to be implemented."

http://gnosis.cx/publish/programming/multicast_2.html

https://en.wikipedia.org/wiki/Border_Gateway_Multicast_Protocol

  And then later the “something better” was SSM with the hope that the 
success of SSM would lead to the natural death of MSDP.

  One of the reasons to keep MSDP on life support was that Apple Macintoshes 
did not support IGMPv3.  But Macintoshes have supported IGMPv3 for a while 
(Since Lion 10.7 ?)

  

  I think one of the main problems with MSDP is that the rules to prevent 
loops end up being very complicated and in real world topologies with more 
than one MSDP peering become very time consuming to debug.

  Dave Meyer has a nice graph about complexity.  See slide 15 on the 
presentation below.

https://www.nanog.org/sites/default/files/monday_keynote_meyer_macrotrends_1.pdf

  Dave Farmer, Colin Murphy and I had a conversation about MSDP and one way 
to summarize it is to say that a gigaPOP with multiple mBGP peerings can move 
MSDP from the far right side of the graph (very fragile) back towards the 
left (less fragile) a little by not MSDP peering with every mBGP peer but 
only with one major backbone like Internet2 and gigaPOP customers.

  Minimizing the fragility still does not get MSDP over to the robust side of 
the graph though and I agree that long term MSDP must die.


  However on the hope springs eternal side maybe we should consider there is 
work being done on BIER and maybe it would be nice to leave MSDP and ASM IPv4 
multicast working until BIER is a little further along.

https://www.ietf.org/mailman/listinfo/bier


  Alan mentioned babies and bathwater and on that side of things the dbeacon 
is one of the primary tools for debugging both ASM and SSM multicast.  If we 
kill MSDP then the dbeacon becomes much less functional since there is no 
easy way to discover SSM sources running the dbeacon.  In the IPv6 world 
there is the same problem, embedded RP is used for IPv6 dbeacons.

  Of course the dbeacon could be re-written to use some other method for 
source discovery but it would be nice to not kill MSDP off until the new and 
improved dbeacon is available.

  Another alternative would be to configure your routers with static mappings 
of a group used for a dbeacon to an RP at the site hosting the dbeacon web 
page.

  But do we really want to make debugging SSM more difficult by making 
setting up a dbeacon more difficult?



  My MSDP SA Cache has 1484 entries.  But those entries are from 151 RPs.  
The Internet2 web site lists 310 members in the Higher Education category.  
(Not all of the RPs are on Internet2 of course, some of them are connected to 
other networks like GEANT etc).

  Does anyone else think that it is humorous that the Dave Meyer who wrote 
the presentation on complexity is the same Dave Meyer that is the co-author 
of the MSDP RFC and was chair of the IETF MSDP working group?

https://tools.ietf.org/html/rfc3618

https://tools.ietf.org/html/rfc4611

http://www.1-4-5.net/~dmm/vita.html

---
Bruce Curtis                         

Certified NetAnalyst II                701-231-8527
North Dakota State University