Subject: Re: mboned: PIM-DM and reliance on data plane etc.

From: John Zwiebel <[email-masked]>
Date: Mon, 26 Jun 2006 13:54:32 -0700

On Jun 26, 2006, at 12:49 PM, Jeremy Hall wrote:

> but don't forget we had the wide-spread deployment of mrouted and  
> dense
> mode pim, then somewhere in the middle of the backbone we would have
> some cisco / jnpr infrastructure.  Perhaps now things have changed and
> dependence on dense-mode protocols has slackened.
>
> _J

I wouldn't have wanted anyone to think differently.  If I wasn't
clear, thanks for setting it straight.

Now though, the question I'm asking is, "Since multicast deployment
has been pretty limited (meaning I find it difficult to get from
anywhere to anywhere with multicast, not that there aren't certain
areas and enterprises where multicast is widely deployed) should we
think about how to move beyond PIM-SM -- which requires switching
between shared-trees and shortest path trees -- to a simpler choice
of protocols that do not require so much interaction with the data  
plane?"
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jun 2006 12:00:53 +0300 (EEST)

This is no longer related to the draft, but might be a useful point..

On Mon, 26 Jun 2006, John Zwiebel wrote:
> of protocols that do not require so much interaction with the data plane?"

I think these are really two separate questions:

  - would a different ("simpler") choice of protocols help (or hinder) 
multicast deployment?

  - is 'so much interaction with the data plane' the reason why current 
multicast protocols are not widely deployed?

Personally, I'd agree that the protocols should be easier to 
understand (it takes quite a bit to understand all the issues relating 
to register/register-stop, SPT switchovers, etc.etc. so how could an 
enterprise or a random ISP deploy and troubleshoot it), but I'm not 
sure if the data plane interaction as such was a major reason for 
these issues.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Zwiebel <[email-masked]>
Date: Fri, 30 Jun 2006 06:47:09 -0700

On Jun 30, 2006, at 2:00 AM, Pekka Savola wrote:

>  - would a different ("simpler") choice of protocols help (or  
> hinder) multicast deployment?

Interdomain multicast, our vision of anyone, anywhere being able to  
multicast to anyone else
anywhere else, would be greatly helped.  It would take the source  
discovery out of the network
removing PIM registration and Rendezvous Points.  Eliminating the  
need for the RPT/SPT switch
vastly improving the fault-finding capabilities.

But within an enterprise or as mcast is being deployed now by the  
cable companies, I doubt it
matters.  What they have is "good enough".  They had a need,  
determined the pain wasn't too
great and went for it.

Anything that needs MSDP isn't going to go very far.  Now, that's a  
protocol that
hurts ones understanding of the universe.  It seems like it should be  
so simple, but
the BGP-RPF rules are just too difficult to comprehend easily.   
Perhaps because it
requires BGP?

>  - is 'so much interaction with the data plane' the reason why  
> current multicast protocols are not widely deployed?

Again, depends on your environment.  In the interdomain space and  
last mile, which is where I think we
are lamenting the lack of multicast (depends on whether or not you  
took the blue/red pill)
I think this is maybe a perception problem because there are so many  
areas that potential
failures can happen without a ready means of knowing the failure has  
happened or being
able to fix it.

ie, maybe its just that it "sounds scary" that interdomain multicast  
is being avoided.
And the scariest are the assert situations followed by the need for  
RP deployment to
enable source discovery.

Asserts get more complicated when there is a both shared-tree and a  
source-tree do deal with.

Source discovery via PIM registers is just a pain to have to manage.   
If I were
working at an ISP, I'd ask why the DNS guys couldn't take care of it  
(whine, whine, whine).
Both of these are 'data-plane' interactions.

> understand (it takes quite a bit to understand all the issues  
> relating to register/register-stop, SPT switchovers, etc.etc. so  
> how could an enterprise or a random ISP deploy and troubleshoot  
> it), but I'm not sure if the data plane interaction as such was a  
> major reason for these issues.