Re: [MBONED] deprecating MSDP

[Toerless Eckert <[e-mail]>]

On Tue, Sep 05, 2017 at 02:20:50PM -0700, Leonard Giuliano wrote:
> 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.

My argument is that RFC4610 alone is not good enough for a business
criticial deployment of ASM because it misses all the necessary specs
for reliability , hardening and troubleshooting.

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

Nothing what i proposed is IMHO specific to RFC4610 or MSDP. It's instead
what you'd need to have for any network layer protocol of similar
complexity to make it reliable, hardened and troubleshootable. Most
of these operational aspects have in the part left to vendors proprietary
approaches and IMHO thats been one of the biggest issues of success
of more complex solutions in networks.

Wrt to ASM being the problem: Imagine we only do SSM in the network,
and a distributed application layer solution would do source discovery.
Guess how that would be built. Definitely a lot easier troubleshotable
than RFC4610. Much more like what i am suggesting. Definitely on top of
TCP or better and not UDP. 

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

Sure. ALl i am saying is that ASM without MSDP and with just RFC4610
is less operationally complete. I am not arguing right now how important
it would be to fix that, i would just resist documents stating that
ASM intradomain with just RFC4610 is in good shape.

Cheers
    Toerless

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

-- 
---
[e-mail]