Re: [MBONED] deprecating MSDP

[Toerless Eckert <[e-mail]>]

Depending to some degree to the vendor implementation,
I was suggesting to use MSDP for anycast-RP over RFC4610 because it
had evolved a lot earlier and has a lot more bells and whistles that are
IMHO highly relevant for business criticial anycast PIM-SM deployments.

Alas of course, MSDP is only IPv4, and we should have something equally
good for IPv6 as MSDP has been for IPv4 - for anycast-RP. 

So, IMHO, we should close the gaps of RFC4610 over MSDP: Give
it the option to use TCP (arguably in line with PORT), have a
config/ops model equivalent to the MSDP MIB (subest required for
anycast-RP), and IMHO introduce the equivalent to the MSDP cache
for troubleshooting and per-neighbor state limiters and total state
limiters.

IMHO thats whats needed to deprecate MSDP completely. Shorter term
we can of course have some deployment guide that calls MSDP deprecated,
but not change the doc status to historic/deprecated.

Toerless

On Wed, Jul 26, 2017 at 09:43:37AM -0700, Leonard Giuliano 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
> | [e-mail]
> | https://www.ietf.org/mailman/listinfo/mboned
> | 
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[e-mail]