Re: [MBONED] deprecating MSDP

[Leonard Giuliano <[e-mail]>]

IMO, closing the gap between RFC4610 and MSDP would be a step in the wrong 
direction.  Reinventing MSDP and calling it another name will solve 
nothing.  "A source discovery protocol by any other name would smell as 
sweet..."  If someone really wants to run Anycast RP in v6 within his 
domain, RFC4610 should be good enough.

Again, the problem isn't MSDP, the problem is ASM.  Tweaking RFC4610 to 
match the microscopic (and generally irrelevant) benefits MSDP might have 
will just create yet another overly complex mcast protocol to address the 
corner cases of a handful of ill-conceived network deployments.  And have 
the same result- no one deploys it bc of all this unnecessary complexity.

If the goal is to change course and get folks to deploy mcast, we should 
make things unambiguously simple- use SSM in the network layer and let the 
some other layer handle source discovery.


On Mon, 4 Sep 2017, Toerless Eckert wrote:

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