Subject: [MBONED] deprecating MSDP

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 25 Jul 2017 17:13:30 -0500

As was noted in the minutes, there is perhaps a significant set of the
multicast community (including ourselves) seriously considering 
turning off inter-domain MSDP for good.

Related, I am curious what are the barriers to moving MSDP to historic 
status?  In RFC4611, that document differentiates intra-domain vs 
inter-domain MSDP.  For that matter, it does a pretty good job at
explaining the state of MSDP, but doesn't necessarily reflect what to 
do in deployments today.  

That seems to me to be different than where draft-acg-mboned-multicast-models
is headed?  

draft-ietf-mboned-interdomainpeering-bcp clearly is not advocating for
more inter-domain MSDP.

Dale

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 26 Jul 2017 09:43:37 -0700

Dale, 

Great questions and thanks for bringing up, as we'd love feedback from the 
I2 community- it's probably the largest user of interdomain MSDP and 
the centerpiece of this conversation.

draft-ietf-mboned-interdomainpeering-bcp is scoped to just focus on SSM.  
The plan is for draft-acg-mboned-multicast-models to pick up from there 
and make the strong recommendation to use SSM, not ASM, for interdomain 
mcast deployment.  I am not sure about moving MSDP to historic and what 
that would practically mean, but in IMO, MSDP is somewhat of a scapegoat 
here.  The real culprit is ASM (or rather, network-based source 
discovery); MSDP is merely driving the getaway vehicle, albeit with a 
reckless and dangerous driving style.  Eliminate network-based source 
discovery for interdomain mcast and the vast majority of the complexity 
and problems of mcast go away (RPs, PIM registers, RPTs, SPT switchover, 
MSDP, data-driven state creation, etc).

We are scoping this to *interdomain*, as it has been mentioned that within 
a domain there might be reasonable uses for ASM.  And for that matter, 
what you do in your own house is your business, but once you leave your 
home and interact with your neighbors and share the roads with other 
drivers, more stringent rules and guidelines are appropriate for the sake 
of safety and order.  So we are not saying anything about MSDP for 
*intradomain* use (for now).  Aside: there is of course RFC4610, but 
Anycast PIM is pretty much identical to internal MSDP- same behavior by a 
different name.

So recommending SSM (and not ASM) for interdomain has overwhelming 
support, and is basically a no-brainer from a network perspective.  But 
the big open question is if it's feasible/meaningful given the state of 
apps today? That is, for those users of interdomain mcast on I2, are the 
apps they use SSM aware?  Is there a good way to find this out from the I2 
community?

-Lenny

On Tue, 25 Jul 2017, Dale W. Carder wrote:

| 
| As was noted in the minutes, there is perhaps a significant set of the
| multicast community (including ourselves) seriously considering 
| turning off inter-domain MSDP for good.
| 
| Related, I am curious what are the barriers to moving MSDP to historic 
| status?  In RFC4611, that document differentiates intra-domain vs 
| inter-domain MSDP.  For that matter, it does a pretty good job at
| explaining the state of MSDP, but doesn't necessarily reflect what to 
| do in deployments today.  
| 
| That seems to me to be different than where draft-acg-mboned-multicast-models
| is headed?  
| 
| draft-ietf-mboned-interdomainpeering-bcp clearly is not advocating for
| more inter-domain MSDP.
| 
| Dale
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/mboned
|

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 27 Jul 2017 14:55:35 +0900

Hi,

> apps they use SSM aware?  Is there a good way to find this out from the I2 

Basic question.
Why we should not have a function/mechanism to translate (*,G) join/leave to (S,G) join/leave?
All (*,G) join/leave requests with global scope multicast address should be translated to appropriate (S,G) join/leave requests based on “something”.
This “something” may be a multicast database, a directory system, or some network protocol. If no “S” information on this “something”, routers receiving join/leave just discards the request.

In fact, one big issue would be the deployment of SSM-aware applications. Recently, IGMPv3/MLDv2 are implemented on major OSes. (It took long years!) How about iOS and Android OS? (Maybe not?)
Now’s the time to consider SSM-aware applications? (Wait for long years again?)

Long years ago, I tackled the issue and published a paper, whose title is “Multicast routers cooperating with channel announcement system”.
(http://ieeexplore.ieee.org/document/1266120/)
It is an old paper. And the work was in progress at that moment but I stopped the work as my task was done; however this idea may be still interesting. It introduces various benefits, not only (*,G) to (S,G) translation.

I’m interested in hearing thoughts about (*,G) to (S,G) translation.
(Sorry for changing the discussion about “deprecating MDSP”.)

Regards,

Hitoshi

> 2017/07/27 1:43, Leonard Giuliano <[email-masked]> wrote:
> 
> Dale, 
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Jul 2017 10:50:39 -0700

> Why we should not have a function/mechanism to translate (*,G) join/leave to (S,G) join/leave?

A draft that explains how to do this is way over due.

> This “something” may be a multicast database, a directory system, or some network protocol. If no “S” information on this “something”, routers receiving join/leave just discards the request.

We support this in LISP FYI. The mapping database can hold (S,G) entries. It can hold (*,G) but we prefer to to the (*,G) translation to (S,G) and just store (S,G) entries in the LISP mapping system.

https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast

Dino

---

From: Rob Evans <[email-masked]>
Date: Fri, 28 Jul 2017 13:24:08 +0100

This is interesting, because as another R&E network (Janet), we have quite
a few inter-domain MSDP peerings and indeed had a report from a
neighbouring R&E network about one being down just today.  However, I don't
know how much ASM we have floating around the network.  I'll have to have a
bit of a poke around.

Cheers,
Rob

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 29 Jul 2017 01:19:50 +0900

Hi Dino,

> A draft that explains how to do this is way over due.

I can expect. My paper;
“Multicast routers cooperating with channel announcement system”.
(http://ieeexplore.ieee.org/document/1266120/)
was also published on 2004.

But if it’s beneficial, it’s not bad to think it again.

> https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast

Great.
BTW, how does the mapping system collect (S,G) information in a scalable manner with no latency?

Regards,

Hitoshi

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Jul 2017 10:15:48 -0700

> BTW, how does the mapping system collect (S,G) information in a scalable manner with no latency?

Each ETR that receives IGMP reports Map-Register the (S,G) with a pair of map-servers. The Map-Servers merge the Map-Register from each ETR to build a replication-list. Then when an ITR gets a (S,G) packet, it looks it up in the maping system and replicates to each ETR. The replication list can also have one entry in it where an ITR encaps to a single RTR and then the RTR replicates to the ETRs.

See slide enclosed for ITR replication.

Dino