Re: [MBONED] deprecating MSDP

Hi,

Yes, very good questions. And I think at the moment we have more questions than answers.

I’ll work with Lenny and Mikael to push a -01 update to the draft in the next week or two, and we’ll try to capture all the issues in there, without advocating specific answers.  That should help focus discussion.

As implied by Dale and Hitoshi, we’re essentially pushing the source discovery problem from the network to the applications.  It *may* be that one part of the solution is something that can do the mapping, as Hitoshi suggests.  That will be an issue we capture in the draft.

I think we are in a good place with MLDv2 and IGMPv3. The RFC6434 update will be requiring all nodes to support MLDv2; the current version does not.

There are other issues that have arisen from discussion started by Rob on our Janet multicast list, e.g. whether the ISP would then filter any GLOP or IPv4 Unicast-based prefixes, as we should all be using 232.0.0.0/8.

We have a Janet IPv6 multicast beacon running Embedded-RP.  While Embedded-RP is not as complex to support as IPv4 ASM + MSDP, to be even handed we should advocate IPv6 SSM.

Tim 

> On 26 Jul 2017, at 17:43, Leonard Giuliano <lenny@juniper.net> wrote:
> 
> 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
> | MBONED@ietf.org
> | https://www.ietf.org/mailman/listinfo/mboned
> | 
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
> 